服务划分的策略。
    （1）按照业务能力和限界上下文（bounded context）划分——服务将对应于粒度相对粗一些但又紧密团结成一个整体的业务功能领域。
    （2）按用例划分——这种服务应该是一个“动词”型，它反映了系统中将发生的动作。
    （3）按易变性划分——服务会将那些未来可能发生变化的领域封装在内部。

    （1）了解业务问题——识别实体和用例——划分服务责任，我们可以通过这一流程来划定服务范围。（2）可以采用不同的方式来对服务进行划分：按业务功能划分、按用例划分和按易变性划分。读者可以综合运用这些方法。（3）好的划分决策能够让服务满足微服务的三大关键特性：只负责单一职责、可替换和可独立部署。（4）限界上下文通常是与服务边界相对应的，在思考服务的未来发展时，这是一种很有效的方法。（5）通过对易变领域的深入思考，开发者可以将那些会一起变化的领域封装起来，以提高应对未来变化的适应能力。（6）如果服务划分不好，后期修正的代价是特别大的，因为到那时，开发者需要重构多个代码库，由此产生的工作量会变得特别大。

    （7）我们也可以将技术功能封装成一个服务，这么做既能够简化业务能力，又可以对业务功能提供支撑，并能最大限度地提高服务的可用性。（8）如果服务边界还不够明确，我们宁可选择粗粒度的服务，但是要主动在服务内部采用模块化的方案来为未来的拆分做准备。（9）服务下线是一件特别有挑战性的工作，但是随着微服务应用的不断发展，我们未来终有一天会需要这么做。（10）在大型组织机构中，将所有权拆分到多个团队中是很有必要的，但是这又会引入新的问题：控制变弱、设计受限、开发速度不一致。（11）代码开放化、接口明确化、沟通持续化以及放宽对DRY原则的要求都可以缓解团队之间的紧张关系。

    （1）在跨服务的交互中实现ACID特性是很困难的，微服务需要采用不同的方式来实现一致性。（2）类似两阶段提交这样的协调方案会引入加锁操作，扩展性不好。（3）基于事件的架构可以解除各个独立组件之间的耦合，并为微服务应用的业务逻辑和查询的可扩展性打下基础。（4）倾向于高可用，而非一致性，这会使得架构的可扩展性更强。（5）Saga是由一组消息驱动的、独立的本地事务组成的全局操作。它们通过补偿操作来回滚错误的状态，以实现一致性。（6）在构建反映现实世界环境的微服务时，预见失败场景并做好准备是非常重要的一部分内容，操作的隔离性反而没那么至关重要。（7）我们通常通过组合多个API的结果来实现跨多个微服务的查询功能。（8）高效的复合型查询应该采用CQRS模式来实现一套独立的读数据模型，特别是在那些查询模式需要采用另一种数据存储系统时。