《微服务设计》第 12 章 　总结

第 12 章 　总结

12.1 　微服务的原则

• 但微服务的一些关键原则，这些原则将帮助我们，创建出一系列可以很好地进行协同工作的自治的小服务
• 你可以选择全部采用这些原则，或者定制采用一些在自己的组织中有意义的部分。但请注意，组合使用这些原则的价值：整体使用的价值要大于部分使用之和。所以，如果决定要舍弃其中一个原则，请确保你明白其带来的损失

12. 1. 1 　围绕业务概念建模

• 经验表明，围绕业务的限界上下文定义的接口，比围绕技术概念定义的接口更加稳定

12. 1. 2 　接受自动化文化

• 微服务引入了很多复杂性，其中的关键部分是，我们不得不管理大量的服务。解决这个问题的一个关键方法是，拥抱自动化文化。前期花费一定的成本，构建支持微服务的工具是很有意义的

12. 1. 3 　隐藏内部实现细节

• 服务还应该隐藏它们的数据库，以避免陷入数据库耦合，这在传统的面向服务的架构中也是最常见的一种耦合类型。使用数据泵（ data pump）或事件数据泵（ event data pump），将跨多个服务的数据整合到一起，以实现报表的功能
• 在可能的情况下，尽量选择与技术无关的 API，这能让你自由地选择使用不同的技术栈。请考虑使用 REST，它将内部和外部的实现细节分离方式规范化，即使是使用 RPC，你仍然可以采用这些想法

12. 1. 4 　让一切都去中心化

• 确保团队保持对服务的所有权是重要的一步，理想情况下，甚至可以让团队自己决定什么时候让那些更改上线。使用内部开源模式，确保人们可以更改其他团队拥有的服务，不过请注意，实现这种模式需要很多的工作量。让团队与组织保持一致，从而使康威定律起作用，并帮助正在构建面向业务服务的团队，让他们成为其构建的业务领域的专家
• 像企业服务总线或服务编配系统这样的方案，会导致业务逻辑的中心化和哑服务，应该避免使用它们。使用协同来代替编排或哑中间件，使用智能端点（ smart endpoint）确保相关的逻辑和数据，在服务限界内能保持服务的内聚性

12. 1. 5 　可独立部署

• 请考虑使用蓝 /绿部署或金丝雀部署技术，区分部署和发布，降低发布出错的风险。使用消费者驱动的契约测试，在破坏性的更改发生前捕获它们

12. 1. 6 　隔离失败

• 如果我们心中持有反脆弱的信条，预期在任何地方都会发生故障，这说明我们正走在正确的路上。请确保正确设置你的超时，了解何时及如何使用舱壁和断路器，来限制故障组件的连带影响。如果系统只有一部分行为不正常，要了解其对用户的影响。知道网络分区可能意味着什么，以及在特定情况下牺牲可用性或一致性是否是正确的决定

12. 1. 7 　高度可观察

• 通过注入合成事务到你的系统，模拟真实用户的行为，从而使用语义监控来查看系统是否运行正常。聚合你的日志和数据，这样当你遇到问题时，就可以深入分析原因。而当需要重现令人讨厌的问题，或仅仅查看你的系统在生产环境是如何交互时，关联标识可以帮助你跟踪系统间的调用

12. 2 　什么时候你不应该使用微服务

• 第一条建议是，你越不了解一个领域，为服务找到合适的限界上下文就越难
• 从头开发也很具有挑战性。不仅仅因为其领域可能是新的，还因为对已有东西进行分类，要比对不存在的东西进行分类要容易得多！因此，

12. 3 　临别赠言

• 微服务架构会给你带来更多的选择，也需要你做更多的决策。相比简单的单块系统，在微服务的世界里，做决策是一个更为常见的活动。我可以保证，你总会在一些决策上出错。如果做错了，只会影响系统的一小部分。学会拥抱演进式架构的概念，在这种概念下，系统会在你学到一些新东西之后扩展和变化