§ 前言

传统单体应用转变为微服务，不可避免的就是微服务拆分，本章节主要讲解拆分的基本原则，以及工程如何规划

§ 基本概念

微服务就是一些协同工作的小而自治的服务

**松耦合：**服务间的松耦合，即修改一个服务不用修改另一个服务。一个松耦合的服务应该尽可能少地知道与之协作的那些服务信息，这意味着，应该限制两个服务间的调用数量
**高内聚：**把相关的行为聚集在一起，把不相关的行为放在别处。（只把经常一起变化的部分放在一起，从而实现高内聚合）

如果要改变某个服务的形为，只需要修改一个地方，然后就可以尽快的发布。如果需要修改多个服务，说明服务拆分的不合理

任何一个给定的领域都包含很多个限界上下文，每个限界上下文中的模型分为两部分，一部分不需要与外部通信，另一部分则需要，每个限界上下文都有明确的接口，该接口决定了它会暴露哪些模型给其他的上下文
另一个定义：“一个由显式边界限定的特定职责”

一个例子：细胞之所以存在，是因为细胞膜定了什么在细胞内，什么在细胞外，并且确定了什么介质可以通过细胞膜

两个上下文都会用到的模型即为共享模型(即上文中提到的需要与外部通信的)，但是共享模型是否要全部暴露出去？一般存在内部和外部两种表现方式，这样的目的是松耦合，内部服务变化了可以尽可能的不影响其它服务

只在一个上下文中会用到的模型，不与外部通信

单体应用中的模块是一个很好的微服务拆分侯选。模块是单体应用用来减少彼此之间耦合的一种选择，所以一旦你发现了领域内部的限界上下文，一定要使用模块对其进行建模，同时使用共享和隐藏模型。如果服务边界和领域的限界上下文能保持一致，并且微服务可以很好地表示这些限界上下文的话，高内聚低耦合的第一步就完成了

组织内的限界上下文，不应该从共享数据的角度考虑，而应该从这些上下文能够提供的功能来考虑

但拆分需要遵循几个基本的原则：

在拆分时，也需要注意，避免出现大量的分布式事务，以及微服务暴露过多的接口，微服务间应该是低耦合关系，高耦合性将会诱发很多问题