《微服务设计》1~3章笔记
《微服务设计》
目录
- 微服务
- 演化式架构师 **
- 如何建模服务 **
- 集成
- 分解单块系统
- 部署
- 测试(消费者驱动)
- 监控 **
- 安全
- 康威定律和系统设计
- 规模化微服务
- 总结
第一章 微服务
发展
- 领域驱动设计
- 持续交付
- 按需虚拟化
- 基础设施自动化
- 小型自治团队
- 大型集群系统
- ** 微服务**
什么是微服务？
一些协同工作的小而自治的服务
特点
- 很小专一，
- 做好一件事
好处
- 技术异构（新语言，新数据库，或中间件快速引入）
- 弹性（处理不可用+服务降级问题）
- 扩展（部署机器性能一般）
- 简化部署（对特定代码部署，快速回滚）
- 与组织结构结构相匹配（小团队的生产力）
- 可组合性（web端，原生移动端，移动端web,平板，可穿戴设备）
- 可替代性的优化（足够小简单，新语言新思路重写精力低）
思考：
- 模块耦合+业务边界的问题。
- 服务越小，独立性就很强，但是管理起来就越来越复杂了。
- 服务应该暴露什么，隐藏什么。
SOA
- 在业界知识普及，使用规范还有模糊的地方。
- 实际开发也遇到了各种各样的问题了。
分解技术
- 共享库（技术单一，耦合）
- 模块（不断耦合，然后就失去本身的意义）
第二章 演化式架构师
不准确的比较
- 计算机才出来70年而已
- 不要和其他行业过分比较
架构师的演化视角
- 逐步演化系统(需求变更+我们知识提升)
- 一旦我们学到了更多知识，应该很容易引入到现有系统。
- 类比城市规划师，而不是建筑师。（思考：人与设施）
- 城市不断在变化，需要预见一些东西。
- 设计对于施工人员，合理的，适合工作的。
一个原则性的方法（如何做取舍）
- 战略目标（公司层面）
- 原则（确定下来）
- 实践（是否可实施，与原则相结合）
做一些工具，来保证我们所做的事情的正确性。
要求的标准（标准化）
- 监控（清楚知道跨服务的健康状态）
- 接口
- 架构安全性
- 一个服务会影响整个系统？
- 错误处理
代码治理
- 奏效的方法： 范例+服务代码模板
-【使用技术，实现可能不一样】
- 不是中心化职责，团队也需要负责更新。 - 需要一些特性：
- 健康检查
- HTTP服务
- 指标数据接口（发送到统一中心）
- 响应时间+错误率
- 容错性
==》实例：
- Netfix更关心的是，开发这些库时可能会引入的错误。
使用了挎斗服务，挎斗服务会和JVM进行本地通信。 - 曾经有一个团队的士气和生产力被强制使用的框架给毁掉。
- 重用代码危险！服务之间的耦合。
2.7 技术债务
- 团队有自己的技术愿景，一旦偏离了可能获取短期的利益，但长远来看是有代价的。
- 有时候系统目标发生了变化，并现有不符也会产生技术债。
2.8 例外管理
思考
如果偏离原则和指导？
原则+实践：
- 偶尔一次破例，记录下来。
- 出现多了，就要调整原则，并把我们的理解记录下来。
情况：
- 高度自治团队【原则轻量，很少】
- 组织结构化较强的，开发人员拥有较小的自由。【此时例外管理就很重要了】
- 提倡由微服务团队解决问题，自由度更高。
2.9 集中治理和领导
架构师：技术治理。
- 指导开发原则。
- 原则与组织战略相符。
- 不会给开发人员带领痛苦。
- 开发理解了，还能让其他人去理解。
- 参与编码
作者推荐：
- 由架构师领导小组，但每个交付的团队都要有人参与。明确职责，全员参与治理。
- 有大家的分担，也有了高层指导。
- 挑战，架构师与团队的意见不一致。
- 关键：有时候按照你一个不同意的决定走下去，反而是正确的，
知道什么时候可以这么做，什么时候不能也是很困难的。【】
2.10 建设团队
重要的事情：
- 帮助你的队友成长，帮助他们理解这个愿景。
- 并保证他们可以积极参与到这个过程中。
- 微服务给人们带来多个自治代码库，独立生命周期。【足够的锻炼后，就可以给予更多的责任】
小结：
架构师职责：
- 愿景
- 同理心
- 合作
- 适应性
- 自治性
- 治理
在微服务中，架构师需要做的决定很多。
第三章 如何建模服务
当别人问异教徒世界是由什么支撑时，他说：“是一只乌龟。”
别人再问他那乌龟又是由什么支撑呢？
他回答：“另一只乌龟。”
3.2 什么样的服务是好服务
松耦合高内聚。
- 松耦合：独立修改单独部署
- 高内聚：相关的行为聚集在一起，把不相关的行为放在别处。
3.3 限界上下文
阅读：《领域驱动模型》
上下文
定义：一个由显式边界限定的特定职责。
具体描述：
- 一部分不需要和外部通信
- 一部分则需要
每个上下文都有明确的接口，决定暴露给哪些模型+其他上下文
比喻：
细胞之所以存在，是因为细胞膜定义了什么在细胞内，什么在细胞之外，并
确定了什么物质可以通过细胞膜。
共享的隐藏模型
例子
- 财务部和仓库是独立的限定上下文，也存在共享模型。
- 但共享项不能盲目暴露库存的所有内容。
- 同一个名字在不同的上下文有着完全不同的含义。
- 比如：退货。
- 在客户的上下文中，退货以为着打印运送标签、寄送包裹，等待退款。
在仓库的上下文中，退货表示的是一个即将到来的包裹，然后重新入库。 - 【这跟我们执行的任务有关】
模块和服务
- 识别出领域内的一些边界(识别错误，后面修改会付出很大代价)
- 如果服务边界和领域边界上下文能保持一致【微服务就能很好表现】
过早划分
例子：SnapCI 团队刚开始很有信心，快速识别边界，直接使用微服务构建系统。
几个月后发现与之前所想的不同，划分服务有问题。
==》导致了很多跨服务调用的修改（惨痛的代价）
解决：开始合并微服务。
一年后才识别出非常稳定的边界，划分成功。
逐步划分上下文
对于嵌套的上下文
- 使这些上下文不直接对外可见。对于外界来说，它们用的还是仓库的功能，但发出请求其实被透明地映射到了两个或者更多的服务上。
- 如果维护订单和库存管理的是由不同的团队维护。
- 大概会希望这些服务都是顶层微服务
关于业务概念的沟通
- 如果系统被分解成限界上下文来表示领域的话，对于单独功能修改，局限单独的微服务边界上。
- 使用领域建模
技术边界
不应该单纯按照业务垂直切分，而是考虑内部api水平划分。
推荐书籍：《领域驱动设计》,《实现领域驱动设计》
