12.1 微服务的原则
微服务中有有一些关键原则，你可以选择全部采用这些原则，或者定制采用一些再自己的组织中有意义的部分。组合使用这些原则的价值：整体使用的价值要大于部分使用之和。所以，如果决定要舍弃其中一个原则，请确保你明白其带来的损失。
12.1.1 围绕业务概念建模
围绕业务的限界上下文定义的接口，比围绕技术概念定义的接口更加稳定。针对系统如何工作这个领域进行建模，不仅可以帮助我们形成更稳定的接口，也能确保我们能够更好地反映业务流程的变化。
12.1.2 接受自动文化
微服务引入了很多复杂性，关键部分是：不得不管理大量的服务。解决这个问题的关键方法是：拥抱自动化文化。
自动化测试必不可少，相比单块系统，确保我们大量的服务能够正常工作是一个更复杂的过程，这也是采用“持续交付”对每次提交后的产品质量进行快速反馈的一个关键部分。
12.1.3 隐藏内部实现细节
为了使一个服务独立于其他服务，最大化独自演化的能力，隐藏实现细节至关重要。服务还应该隐藏它们的数据库，以避免陷入数据库耦合（报表属于特例）
在可能的情况下，尽量选择与技术无关的API，这能让你自由地选择使用不同的技术栈。
12.1.4 让一起都去中心化
为了最大化微服务能带来的自治性，给拥有服务的团队委派决策和控制权，只要有可能，就尝试使用资源自助服务，允许人们按需部署软件，使开发和测试尽可能简单，并且避免让独立的团队来做这些事。
确保团队保持对服务的所有权是重要的一步，甚至可以让团队自己决定什么时候让哪些更改上线。
使用内部开源模式，确保人们可以更改其他团队拥有的服务。
让团队与组织保持一致，从而使康威定律起作用。
尝试使用共同治理模型，使团队的每个成员共同对系统技术远景的演化负责。
12.1.5 可独立部署
应当努力始终确保微服务可以独立部署。当使用居于RPC的集成时，避免使用像Java RMI提供的那种使用生成的桩代码，紧密绑定客户端/服务端的技术。
考虑使用蓝/绿部署或金丝雀部署技术，区分部署和发布，降低发布出错的分线。
使用消费者驱动的契约测试，在破坏性的更改发生前捕获它们。
你更改你负责的服务，然后把它部署到生产环境，无需联动地部署其他任何服务，这应该使常态而不是例外。你的消费者应该自己决定何时更新，你需要适应它们。
12.1.6 隔离失败
我们心中持有反脆弱的心跳，预期在任何地方都会发生故障，这说明我们正走在正确的路上。
确保正确设置了超时，了解何时以及如何使用舱壁和断路器，来限制故障组件的连带影响。
明确在特定情况下，牺牲可用性或一致性是否使正确的决定
12.1.7 高度可观察
我们需要从整体上看待正在发生的事情。通过注入合成事务到你的系统，模拟真是用户的行为，从而使用语义监控来查看系统是否运行正常。聚合你的日志和数据，这样，当你遇到问题时，就可以深入分析原因。关联标识可以帮助你跟踪系统间的调用。
12.2 什么时候你不应该使用微服务
当你越不了解一个领域，为服务找到何时的限界上下文就越难。服务的界限划分错误，可能会导致不得不频繁地更改服务间的协作，而这种更改成本很高。
越不了解一个领域，越应该从单块系统开始，在熟悉和渐进之后，再进行拆分。
花费一定的时间来构建工具和时间，帮助管理微服务，无数的开发者经验验证了这些工作的重要性。
12.3 临别赠言
微服务架构会给你带来更多的选择，也需要你做更多的决策。尽量缩小每个决策的影响范围，这样依赖，如果做错了，只会影响系统的一小部分。不要去想大爆炸式的重写，取而代之的使时间的推移。逐步对系统进行一系列的更改，这样做可以保持系统的灵活性。
使用微服务，要习惯持续地改变和演进系统，变化无法避免，所以，拥抱它吧。
