《微服务设计》读书笔记

导读：《微服务设计》是一本非常出彩的技术书籍，从可读性、实战技术干货方面都非常优秀，甚至让我想起了曾经读《深入理解计算机系统》《UNIX编程艺术》这类经典好书时的感觉。以下是我做的一些概括性的读书笔记，非常希望大家能阅读全书，挖掘更多知识。

---

一、什么是微服务：就是一些协同工作的小而自治的服务。

• 很小，专注于做好一件事：根据业务的边界来确定服务的边界。
• 自治性：一个微服务就是一个独立的实体。服务之间均通过网络调用进行通信，从而加强了服务之间的隔离性，避免紧耦合。这些服务应该可以彼此独立进行修改，并且某一个服务的部署不应该引起该服务消费方的变动。 

  二、微服务的主要好处

• 技术异构性：可以采用不同的技术栈、语言、数据库或者框架。
• 弹性：弹性工程学的一个关键概念是舱壁。如果系统中的一个组件不可用了，但并没有导致级联故障，那么系统的其他部分还可以正常运行。
• 扩展：使用较小的多个服务，则可以只对需要扩展的服务进行扩展，这样就可以把那些不需要扩展的服务运行在更小的、性能稍差的硬件上。
• 简化部署：在微服务架构中，各个服务的部署是独立的，这样就可以更快地对特定部分的代码进行部署。
• 与组织结构相匹配：微服务架构可以很好地将架构与组织结构相匹配，避免出现过大的代码库，从而获得理想的团队大小及生产力。
• 可组合性：可以根据不同的目的组合不同粒度的服务为客户提供功能。

  三、微服务的原则

• 围绕业务概念建模
  经验表明，围绕业务的界限上下文定义的接口，比围绕技术概念定义的接口更加稳定。针对系统如何工作这个领域进行建模，不仅可以帮助我们形成更稳定的接口，也能确保我们能够更好地反映业务流程的变化。使用界限上下文来定义可能的领域边界。
• 接受自动化文化
  微服务引入了很多复杂性，其汇总的关键部分是，我们不得不管理大量的服务。解决这个问题的一个关键方法是，拥抱自动化文化。前期花费一定的成本，构建支持微服务的工具是很有意义的。自动化测试必不可少，因为相比单块系统，确保我们大量的服务能正常工作是一个更复杂的过程。调用一个统一的命令行，以相同的方式把系统部署到各个环境是一个很有用的实践，这也是采用持续交付对每次提交后的产品质量进行快速反馈的一个关键部分。
  考虑使用环境定义来帮助你明确不同环境间的差异，但同时保持使用统一的方式进行部署的能力。考虑创建自定义镜像来加快部署，并且创建全自动化不可变服务器，这会更容易定位系统本身的问题。
• 隐藏内部实现细节
  为了使一个服务独立于其他服务，最大化独自演化的能力，隐藏实现细节至关重要。限界上下文建模在这方面可以提供帮助，因为它可以帮助我们关注哪些模型应该共享，哪些应该隐藏。服务还应该隐藏它们的数据库，以免陷入数据库耦合，这在传统的面向服务的架构中也是最常见的一种耦合类型。使用数据泵或事件数据泵，将跨多个服务的数据整合到一起， 以实现报表的功能。 
  在可能的情况下，尽量选择与技术无关的API。这能让你自由地选择使用不同的技术栈。请考虑使用REST，它将内部和外部的实现细节分离方式规范化，即使是使用RPC，你仍然可以采用这些想法。
• 让一切都去中心化
  为了最大化微服务能带来的自治性，我们需要持续寻找机会，给拥有服务的团队委派决策和控制权。在这个过程初期，只要有可能，就尝试使用资源自助服务，允许人们按需部署软件，使开发和测试尽可能简单，并且避免让独立的团队来做这些事。 
  在这个过程中，确保团队保持对服务的所有权是重要的一步，理想情况下，甚至可以让团队自己决定什么时候让那些更改上线。使用内部开源模式，确保人们可以更改其他团队拥有的服务，不过请注意，实现这种模式需要很多的工作量。让团队与组织保持一致，从而使康威定律起作用，并帮助正在构建面向业务服务的团队，让他们成为其构建的业务领域的专家。一些全局的引导是必要的，尝试使用共同治理模型，使团队的每个成员共同对系统技术愿景的演化负责。
  像企业服务总线或服务编配系统这样的方案，会导致业务逻辑的中心化和哑服务，应该避免使用它们。使用协同来代替编排或哑中间件，使用智能端点确保相关的逻辑和数据，在服务限界内能保持服务的内聚性。
• 可独立部署
  我们应该始终努力确保为服务可以独立部署。甚至当需要做不兼容更改时，我们也应该同时提供新旧两个版本，允许消费者慢慢迁移到新版本。这能够帮助我们加快新功能的发布速度。拥有这些微服务的团队，也能越来越具有自治性，因为他们不需要在部署过程中不断的做编配。 当使用基于RPC的集成时，避免使用像Java RMI提供的那种使用生成的桩代码，紧密绑定客户端/服务器的技术。
  通过采用单服务单主机模式，可以减少部署一个服务引发的副作用，比如影响另一个完全不相干的服务。请考虑使用蓝/绿部署或金丝雀部署技术，区分部署和发布，降低发布出错的风险。使用消费者驱动的契约测试，在破坏性的更改发生前捕捉它们。
  请记住，你可以更改单个服务，然后把它部署到生产环境，无需联动地部署其他任何服务，这应该是常态，而不是例外。你的消费者应该自己决定何时更新，你需要适应他们。
• 隔离失败
  微服务架构能比单块架构更具弹性，前提是我们了解系统的故障模式，并做出相应的计划。如果我们不考虑调用下游可能会失败的事实，系统会遭受灾难性的级联故障，系统也会比以前更脆弱。
  当使用网络调用时，不要像使用本地调用那样处理远程调用，因为这样会隐藏不同的故障模式。所以确保使用的客户端库，没有对远程调用进行过度的抽象。
  如果我们的心中有反脆弱的信条，预期在任何地方都会发生故障，这说明我们正走在正确的路上。请确保正确设置你的超时，了解何时及如何使用舱壁和断路器，来限制故障组件的连带影响。如果系统只有一部分行为不正常，要了解其对用户的影响。知道网络分区可能意味着什么，以及在特定情况下牺牲可用性或一致性是否是正确的决定。
• 高度可观察
  我们不能依靠观察单一服务实例，或一台服务器的行为，来看系统是否运行正常。相反，我们需要从整体上看待正在发生的事情。通过注入合成事务到你的系统，模拟真实用户的行为，从而使用语义监控来查看系统是否运行正常。聚合你的日志和数据，这样当你遇到问题时，就可以深入分析原因。而当需要重现令人讨厌的问题，或仅仅查看你的系统在生产环境是如何交互时，关联标识可以帮助你跟踪系统间的调用。

  四、对于微服务的建议

• 考虑首先先构建单块系统，当稳定后再进行拆分
  你越不了解一个领域，为服务找到合适的限界上下文就越难。服务的界限划分错误，可能导致不得不频繁地更改服务间的协作，而这种更改成本很高。所以，如果你不了解一个单块系统领域的话，在划分服务之前，第一件事是花一些时间了解系统是做什么的，然后尝试识别出清晰的模块边界。另外，对已有的东西进行分类，要比对不存在的东西进行分类要容易得多。
• 演进式架构理念
  微服务架构会给你带来更多的选择，也需要你做更多的决策。相比简单的单块系统，在微服务的世界中，做决策是一个更为常见的活动。你一定会在一些决策上出错，所以尽量缩小每个决策的影响范围。即使错了，也只会影响系统的一小部分。学会拥抱演进式架构的概念，在这种概念下，系统会在你学到一些新东西之后扩展和变化。不要去想大爆炸式的重写，取而代之的是随着时间的推移，逐步对系统进行一系列更改，这样做可以保持系统的灵活性。
• 同样很重要的一点：微服务不是银弹。

  五、对于架构师的看法

• 演化式架构师：就如同城市规划师（优化城市布局，使其易于现有居民生活，同时也考虑一些未来的因素），应该设计出一个合理的框架，在这个框架下可以慢慢演化出正确的系统；要专注在大方向上，只在很有限的情况下参与到非常具体的实现中来。他们需要保证系统不但能够满足当前的需求，还能够应对将来的变化。而且他们还应该保证在这个系统上工作的开发人员要和使用这个系统的用户一样开心。
• 一个演化式架构师应该承担的职责：
  • 愿景：确保在系统级有一个经过充分沟通的技术愿景，这个愿景应该可以帮助你满足客户和组织的需求。
  • 同理心：理解你所做的决定对客户和同事带来的影响。
  • 合作：和尽量多的同事进行沟通，从而更好地对愿景进行定义、修订及执行。
  • 适应性：确保你的客户和组织需要的时候调整技术愿景。
  • 自治性：在标准化和团队自治之间寻找一个正确的平衡点。
  • 治理：确保系统按照技术愿景的要求实现。