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

《微服务设计》

目录

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

第一章 微服务

发展

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

什么是微服务？

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

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

好处

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

思考：

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

SOA

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

分解技术

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

第二章 演化式架构师

不准确的比较

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

架构师的演化视角

  1. 逐步演化系统(需求变更+我们知识提升)
  • 一旦我们学到了更多知识，应该很容易引入到现有系统。
  1. 类比城市规划师，而不是建筑师。（思考：人与设施）
  • 城市不断在变化，需要预见一些东西。
  • 设计对于施工人员，合理的，适合工作的。

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

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

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

要求的标准（标准化）

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

代码治理

  • 奏效的方法： 范例+服务代码模板
    -【使用技术，实现可能不一样】
    - 不是中心化职责，团队也需要负责更新。
  • 需要一些特性：
    • 健康检查
    • 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水平划分。

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

posted on 2017-11-12 22:17  魔术师Carvendy  阅读(181)  评论(0)    收藏  举报