《微服务设计》1~3章笔记

《微服务设计》

目录

1. 微服务
2. 演化式架构师 **
3. 如何建模服务 **
4. 集成
5. 分解单块系统
6. 部署
7. 测试(消费者驱动)
8. 监控 **
9. 安全
10. 康威定律和系统设计
11. 规模化微服务
12. 总结

---

第一章 微服务

发展

• 领域驱动设计
• 持续交付
• 按需虚拟化
• 基础设施自动化
• 小型自治团队
• 大型集群系统
• ** 微服务**

什么是微服务？

一些协同工作的小而自治的服务
特点

• 很小专一，
• 做好一件事

好处

• 技术异构（新语言，新数据库，或中间件快速引入）
• 弹性（处理不可用+服务降级问题）
• 扩展（部署机器性能一般）
• 简化部署（对特定代码部署，快速回滚）
• 与组织结构结构相匹配（小团队的生产力）
• 可组合性（web端，原生移动端，移动端web,平板，可穿戴设备）
• 可替代性的优化（足够小简单，新语言新思路重写精力低）

思考：

• 模块耦合+业务边界的问题。
• 服务越小，独立性就很强，但是管理起来就越来越复杂了。
• 服务应该暴露什么，隐藏什么。

SOA

• 在业界知识普及，使用规范还有模糊的地方。
• 实际开发也遇到了各种各样的问题了。

分解技术

• 共享库（技术单一，耦合）
• 模块（不断耦合，然后就失去本身的意义）

---

第二章 演化式架构师

不准确的比较

• 计算机才出来70年而已
• 不要和其他行业过分比较

架构师的演化视角

1. 逐步演化系统(需求变更+我们知识提升)

• 一旦我们学到了更多知识，应该很容易引入到现有系统。

2. 类比城市规划师，而不是建筑师。（思考：人与设施）

• 城市不断在变化，需要预见一些东西。
• 设计对于施工人员，合理的，适合工作的。

一个原则性的方法（如何做取舍）

• 战略目标（公司层面）
• 原则（确定下来）
• 实践（是否可实施，与原则相结合）

做一些工具，来保证我们所做的事情的正确性。

要求的标准（标准化）

• 监控（清楚知道跨服务的健康状态）
• 接口
• 架构安全性
  • 一个服务会影响整个系统？
  • 错误处理

代码治理

• 奏效的方法： 范例+服务代码模板
  -【使用技术，实现可能不一样】
  - 不是中心化职责，团队也需要负责更新。
• 需要一些特性：
  • 健康检查
  • HTTP服务
  • 指标数据接口（发送到统一中心）
  • 响应时间+错误率
  • 容错性

==》实例：

1. Netfix更关心的是，开发这些库时可能会引入的错误。
   使用了挎斗服务，挎斗服务会和JVM进行本地通信。
2. 曾经有一个团队的士气和生产力被强制使用的框架给毁掉。
3. 重用代码危险！服务之间的耦合。

2.7 技术债务

1. 团队有自己的技术愿景，一旦偏离了可能获取短期的利益，但长远来看是有代价的。
2. 有时候系统目标发生了变化，并现有不符也会产生技术债。

2.8 例外管理

思考

如果偏离原则和指导？

原则+实践：

• 偶尔一次破例，记录下来。
• 出现多了，就要调整原则，并把我们的理解记录下来。

情况：

1. 高度自治团队【原则轻量，很少】
2. 组织结构化较强的，开发人员拥有较小的自由。【此时例外管理就很重要了】
3. 提倡由微服务团队解决问题，自由度更高。

2.9 集中治理和领导

架构师：技术治理。

1. 指导开发原则。
2. 原则与组织战略相符。
3. 不会给开发人员带领痛苦。
4. 开发理解了，还能让其他人去理解。
5. 参与编码

作者推荐：

• 由架构师领导小组，但每个交付的团队都要有人参与。明确职责，全员参与治理。
• 有大家的分担，也有了高层指导。
• 挑战，架构师与团队的意见不一致。
• 关键：有时候按照你一个不同意的决定走下去，反而是正确的，
  知道什么时候可以这么做，什么时候不能也是很困难的。【】

2.10 建设团队

重要的事情：

• 帮助你的队友成长，帮助他们理解这个愿景。
• 并保证他们可以积极参与到这个过程中。
• 微服务给人们带来多个自治代码库，独立生命周期。【足够的锻炼后，就可以给予更多的责任】

小结：

架构师职责：

• 愿景
• 同理心
• 合作
• 适应性
• 自治性
• 治理

在微服务中，架构师需要做的决定很多。

---

第三章 如何建模服务

当别人问异教徒世界是由什么支撑时，他说：“是一只乌龟。”
别人再问他那乌龟又是由什么支撑呢？
他回答：“另一只乌龟。”

3.2 什么样的服务是好服务

松耦合高内聚。

• 松耦合：独立修改单独部署
• 高内聚：相关的行为聚集在一起，把不相关的行为放在别处。

3.3 限界上下文

阅读：《领域驱动模型》

上下文

定义：一个由显式边界限定的特定职责。
具体描述：

• 一部分不需要和外部通信
• 一部分则需要
  每个上下文都有明确的接口，决定暴露给哪些模型+其他上下文

比喻：

细胞之所以存在，是因为细胞膜定义了什么在细胞内，什么在细胞之外，并
确定了什么物质可以通过细胞膜。

共享的隐藏模型

例子

1. 财务部和仓库是独立的限定上下文，也存在共享模型。
   • 但共享项不能盲目暴露库存的所有内容。
2. 同一个名字在不同的上下文有着完全不同的含义。

• 比如：退货。
• 在客户的上下文中，退货以为着打印运送标签、寄送包裹，等待退款。
  在仓库的上下文中，退货表示的是一个即将到来的包裹，然后重新入库。
• 【这跟我们执行的任务有关】

模块和服务

• 识别出领域内的一些边界(识别错误，后面修改会付出很大代价)
• 如果服务边界和领域边界上下文能保持一致【微服务就能很好表现】

过早划分

例子：SnapCI 团队刚开始很有信心，快速识别边界，直接使用微服务构建系统。

几个月后发现与之前所想的不同，划分服务有问题。
==》导致了很多跨服务调用的修改（惨痛的代价）
解决：开始合并微服务。
一年后才识别出非常稳定的边界，划分成功。

逐步划分上下文

对于嵌套的上下文

• 使这些上下文不直接对外可见。对于外界来说，它们用的还是仓库的功能，但发出请求其实被透明地映射到了两个或者更多的服务上。
• 如果维护订单和库存管理的是由不同的团队维护。
• 大概会希望这些服务都是顶层微服务

关于业务概念的沟通

• 如果系统被分解成限界上下文来表示领域的话，对于单独功能修改，局限单独的微服务边界上。
• 使用领域建模

技术边界

不应该单纯按照业务垂直切分，而是考虑内部api水平划分。

推荐书籍：《领域驱动设计》,《实现领域驱动设计》