《微服务设计》阅读总结

《微服务设计》由 ThoughtWorks 的技术专家 Sam Newman 编写，整书 200 多页，从 “是什么”，“为什么”，“怎么样”阐述了如何正确的在业务中落地微服务。虽然微服务是如今很火的一个概念，但是并不是所有场景都适合落地微服务。书中是这样定义微服务的——微服务就是一些协同的小而自治的服务，所谓的小而自治就是指当修改一个服务并对其进行部署的时候不会影响其他的服务。使用微服务的架构构建产品由很多好处如：服务间技术的异构性、服务之间的弹性、能对单个服务进行扩展、简化部署及快速回滚、让服务和组织架构相匹配。但这些好处并不是一蹴而就的，而是需要将微服务所需的基础设施搭建好后才能享受到使用微服务的这些好处。

微服务不是所有情况都适用，当你接手一个全新的项目而你对这个项目所涉及到的业务领域不熟悉，不能快速正确的划分服务领域界限的时候就不适合套用微服务的开发框架。这时候应该将整个项目开发完成再在维护过程中熟悉各个领域的分界，进行上下文的分割，到了需要用上微服务的弹性优势的时候再进行划分。

为了将整个业务线往微服务调整需要由上而下的调整，这是就需要一个演进式架构师。如果将软件系统的构建比作建筑，那么演进式架构师所担任的角色就是城市的规划者，不需要对软件开发的各个方面进行控制，但必须要保证开发人员能够在其搭建的框架上舒适地进行开发——这也是演进式架构师的一个重要职责。演进式架构师在团队建设中需要发挥其重要的作用，首先需要制定一个系统级的让团队成员信服的技术愿景，然后根据这个技术愿景制定出相应的技术原则，然后通过团队沟通不断地将工作流程和工作成果往这个技术原则上靠。演进式架构师理解成功要靠不断的取舍，不可能一套方法永远适用。

当有了落地微服务的决心和有了团队的演进式架构师，就开始对原有的服务进行改进和构建使用于微服务架构的基础设施。设计微服务、构建微服务基础设施，这两个主题是整本书的重要部分。

微服务设计原则

其中“高度可观察”、“自动化的文化”、“独立部署”这几个原则将在下面的微服务基础设施中详细介绍。

围绕业务概念建模原则就是说划分服务时应该以业务为标准，而不是以技术概念为标准。当服务以业务划分的时候，组织上的划分也应该以业务为标准。按照康威定律——任何组织在设计一套系统时，所交付的设计方案在结构上都与该组织的沟通结构保持一致，也就是说人员的配置不以所处的岗位来集中办公，而是以功能小组的形式集中办公。这也有一个问题就是，公司职工的岗位保持恒定的情况下，当一个服务完成迭代进入维护状态，原小组可能会重新打散编排，这时候原服务应该怎么进行维护。这就牵涉到另外一个概念称为内部开源。原小组解散前可以将服务代码进行内部开源，推选几个核心成员作为开源项目的维护人，以维护开源项目的方式继续维护原有的服务，这样能避免人员流动带来的维护困难。

隐藏内部实现细节原则很好理解，从编程的角度来，单个部件要求高内聚，部件之间低耦合是最好的情况。既然使用了微服务架构，那么单个服务高内聚，服务之间低耦合也就是基本的要求。当拆解单块应用时，最大的耦合就是原有的数据库，如使用外键关系来控制一致性。

一切去中心化原则，这里的去中心化指的是技术选型的去中心化和团队的去中心化。团队去中心化就是给予业务团队足够的决策和控制权，让其能够获取到更多的资源简化开发和测试的流程。技术选型的去中心化就是服务间调用使用协同的方式而不是使用编排的方式。所谓编排的方式就是一个事务造成的上游调用，由一个组件依次执行。例如，一个订单系统，当发生一起订单的时候会依次调用订单系统的增加订单、仓库系统的库存查询、库存系统的库存减量、通知系统发送通知等，由于是依次执行的，发起调用的组件就成了这次调用的中心，编排接下来调用的顺序。而协同的方式则是通过异步事件来完成。还是一个订单系统，当发生一起订单的时候，当前组件会生成一个事件，订单系统、仓库系统、通知系统等都会订阅这个事件，然后收到这个事件后触发增加订单、库存查询、库存见谅、发送通知等操作。

隔离失败原则，当微服务达到一定规模后，故障就难以避免，如何处理故障就成了微服务架构中重要的一环。有一些组织会使用流程和控制来试图组织故障的发生，但更好的方法时假设一切都会失败，然后从不同的角度去思考如何解决问题。在分布式系统中处理延迟比处理失败困难的多，当一个下游服务向上游服务发送请求时，由于某种原因上游服务已经失败，但 http 连接的设置问题导致下游服务一直在等待，这时会导致调用该下游服务的服务也处于等待。为了处理这个问题，在处理服务间请求的时候应该正确地设置超时，然后实现一个断路器，第一时间避免给一个不健康的服务发送调用。所谓的断路器，会记录请求成功与否，当积累到一定数量的失败后会打开断路器，当请求处于断路状态，就会快速的失败，等待一定时间后再重试请求，如果得到了正常的响应就会重置断路器。

微服务基础设施

微服务的基础设施就是微服务设计原则中的“自动化的文化”、“独立部署”、“高度可观察”的实现，微服务的基础设施主要包括微服务部署，测试，线上监控时用到的一系列设施。在我接触的一些开发人员并不关注部署、测试和线上监控感觉这是运维和 QA 的责任，实际上并不是这样的，部署、测试和监控是微服务实践中极为重要的部分。

先说部署，微服务的部署中会使用持续集成的技术，持续集成能保证新提交的代码和已有代码进行集成。持续集成推荐每天都签入代码到主线，避免修改堆积导致后来的的集成变得困难；还推荐维持一组测试来验证修改，包括验证语法，检测修改是否破坏了系统的原有行为；最后使用持续集成的模式的话需要把修复 CI 错误当作第一优先级处理。以上面的原则为基础打造的一套部署流程就是我们所说的构建流水线。当一个修改经过一个构建流水线会得到一个构建产物，这个构建产物可以是 Ruby 的 Gem，Java 的 Jar， .net 的 dll 等，构建产物将直接部署到生产环境中运行。

应用的部署会涉及到服务器的配置与修改，一个良好的实践事应该禁止对任何的生产服务器进行手动的配置和修改，那么问题来了怎么修改生产服务器呢？生产服务器可以看作是由一个特定的构建流水线构建出来的产物，构建的结果就是一个系统镜像，当使用这个系统镜像创建一个服务器时，修改就生效了。但使用这种方法应该注意磁盘数据的保存，使用云服务厂商提供的云磁盘的时候可以将业务和数据分别存放在两个不同的虚拟磁盘，构建只影响业务磁盘，数据磁盘在构建完成后挂载。构建系统环境和构建服务可以通过触发器机制来实现自动化。

接着说的是测试，上面说部署流水线的时候说到使用一组测试来验证修改后的服务是否按照预期工作。在“测试金字塔”模型中把自动化测试分为单元测试、服务测试和用户界面测试。单元测试就是在不启动服务的情况下测试一个方法或者类是否如预期运行，单元测试是面向技术而不是面向业务的，能够在小范围内快速的检查修改是否导致程序不正确，让开发者能够放心的修改代码。服务测试就是面向单个服务的，通过启动服务后测试整个服务是否正确运行，运行结果是否符合预期。到了用户测试就是覆盖整个业务的测试，到了这一步已经是面向业务的测试，用于验证业务是否按照产品设计的方式运行。书中专门讨论了端到端测试（也就是用户测试）在微服务场景下落地的问题。由于端到端测试涉及的是多个服务之间的调用，会出现一些环境波动，导致端到端测试有时不能通过，有时能通过，这就叫做端到端测试的脆弱性。脆弱的测试可能不是业务的编写和部署问题，当出现脆弱的测试时，应该第一时间修复这个测试，如果不能修复应该将其从测试套件中移除，在不受打扰的情况下进行修复。如果不管脆弱的测试，开发人员将会对测试套件失去耐心。

最后的基础设施是监控，在服务部署运行的时候通过监控及时发现错误的地方，然后手动或者自动干预，防止一处错误造成雪崩。传统的监控包括对服务器指标的监控和服务的监控，服务器指标的监控就是如 CPU 使用率、内存使用率、网卡收发包等和服务器有关的指标，服务指标的监控就是监控如响应的延时、缓存的命中率等和业务服务质量有关的指标。单条监控数据是没有意义的，当收集足够多的数据然后将其聚合显示出来，再加以分析，才能得出实时得出的监控数值是否符合统计规律。在服务指标监控方面还可以用到语义监控。语义监控在处理服务间交互复杂时能够更加准确的反应系统是否正确工作。在实现语义监控的时候可以手动创建一个模拟操作来验证系统是否正确运行，这个过程就像端到端测试一样，只不过时线上的端到端测试。

微服务架构下监控还有了新的挑战，就是服务之间的交互错综复杂，这时监控需要监控到整个调用链的健康情况，也需要了解整个调用链的调用情况，这就引入了关联标志监控。关联标志监控就是在触发第一个调用的时候生成一个 GUID，然后将其传递给后续调用，通过这个 GUID 关联标志就能推断出整个调用链的情况。书中给的建议事尽早的实现关联标志监控，因为没有这个工作你将不知道一条调用链的上下游关系，当调用失败时也无从考究哪一步调用发生了错误。