《微服务设计》Sam Newman_2016

---

大部分内容比较老，看了部分章节

2 架构师

---

• 专注在大方向，保证系统不但能够满足当前的需求，还能够应对将来的变化，并且保证在这个系统上工作的开发人员要和使用这个系统的用户一样开心
• 从更高的层次出发理解如何做权衡，理解技术债务的层次及其对系统的影响非常重要。对于某些组织来说，架构师应该能够提供一些温和的指导，然后让团队自行决定如何偿还这些技术债务。而其他的组织就需要更加结构化的方式，比如维护一个债务列表，并且定期回顾
• 代码治理，可以引进少量的标准，代码模板/公共库。要警惕，团队的士气和生产力有可能会被强制使用的框架给毁掉。一定要确保能够简化开发人员的工作，而不是使其复杂化
• 架构师的一个职责是确保团队有一个共同的技术愿景，那么治理就是要确保我们构建的系统符合这个愿景，而且在需要的时候还应对愿景进行演化
• 治理是一个小组活动，由架构师领导这个小组，但是每个交付团队都有人参加。架构师负责确保该组织的正常运作，整个小组都要对治理负责

3 服务建模

---

• 好服务的标准：松耦合，低内聚。修改一个服务不影响另外一个服务，可以独立修改部署
• 限界上下文：一个由显式边界限定的特定职责
• 过早将一个系统划分成为微服务的代价非常高，尤其是在面对新领域时。很多时候，将一个已有的代码库划分成微服务，要比从头开始构建微服务简单得多
• 当你在思考组织内的限界上下文时，不应该从共享数据的角度来考虑，而应该从这些上下文能够提供的功能来考虑

4 集成

---

• 同步：请求/响应；异步：基于事件
• 编排与协同。编排的缺点是中心控制点承担了太多职责，会成为网状结构的中心枢纽及很多逻辑的起点，与其打交道的那些服务通常都会沦为贫血的、基于CRUD的服务，大多数重量级的编排方案都非常不稳定且修改代价很大；协同基于事件，可以降低系统的耦合度，并且能更加灵活地对现有系统进行修改，但需要额外的工作来对业务流程做跨服务的监控
• 基于事件的异步协作方式：消息队列，生产者和消费者
• 异步架构的复杂性，异常情况处理复杂度增加，问题排查难度增加，对于习惯了进程间同步调用的程序员来说，使用异步模式也需要思维上的转换。需要确保各个流程有很好的监控机制，并考虑使用关联ID，这种机制可以帮助你对跨进程的请求进行追踪
• 微服务世界中的DRY（Don’t Repeat Yourself）和代码重用的危险，在微服务内部不要违反DRY，但在跨服务的情况下可以适当违反DRY。服务之间引入大量的耦合会比重复代码带来更糟糕的问题
• 使用语义化的版本管理：MAJOR.MINOR.PATCH，其中MAJOR的改变意味着其中包含向后不兼容的修改；MINOR的改变意味着有新功能的增加，但应该是向后兼容的；最后，PATCH的改变代表对已有功能的缺陷修复。不同版本的接口共存
• 与第三方软件集成：尽量把集成和定制化的工作放在自己能够控制的部分