微服务实践目录，可以参见连接。
0. 背景
0.1 拆分与控制的关系
微服务的边界在服务划分的方法中进行说明，拆分出服务之后需要对服务进行管理和控制。服务之间的关系以及调用链的控制不会在服务拆分中进行说明。所以这里主要讨论的是服务之间的关系。
0.2 管理服务之间关系的实践方法
其实业界也有很多方法论可以用来管理服务之间的关系，例如：可以用DDD中的限界上下文映射可以作为服务间关系的理论基础，也可以用AKF中的Y轴的按照功能进行切割，也可以用分层架构中的层次来管理服务之间的关系。
下面主要讨论两种管理服务之间关系的方式：
-
分层模式
以定义层次意义的方式将服务划分到不同的层次中。服务落到层次中之后就可以以层次关系来定义服务之间的关系。 -
分群模式
以服务群的边界定义，使用多个服务组合成一个服务群。以群的边界关系定义服务之间的关系。
1. 分层模式（中台）
1.1 概念
在架构风格中有分层架构风格，在DDD中也有分层模型。分层模式是应用各种场景最直接，也是最容易上手的方式。就像在0.2中说的那样，只要定义清楚分层中每一层的作用即可定义服务之间的关系。
可以以自上而下的设计方法：对层的责任进行定义，然后在定义服务。也可以先进性服务拆分，然后根据服务所提供的内能力在进行分层。例子中可以看出这两种方式的区别。
1.2 例子
DDD分层架构
DDD分层架构并不是只指DDD定义的分层，也可以是DDD分层引申出的六边形架构，洋葱架构，清晰架构等等。他们都有一个特点是以先结论后细节的方式对层次进行划分。每一层都是下层的一个总结流程，每一层都是上层的能力的提供。中台
中台模式是以中台能力为核心的。但是在建设过程中不可能知道哪些能力是需要中台进行承载的。所以，中台是一个对前台和后台提供能力的一个部分，但是它的建设过程是需要不断的抽象与总结来形成中台能力的。
1.3 特点
公用能力
每一层都是向上层提供能力的。所以，下层的服务能力对于上层来说就是公用的。纵向切割的分层模式
分层几乎都是从上之下，或者从下至上的。有明确的层与层的依赖关系
上下层之间关系明确，下层向上层提供服务。不允许下层调用上层未对同层中的服务的能力进行规范
粗粒度的服务，细粒度的服务都在同一个层中。如果服务较多时可能分不清服务之间的划分原则。故障隔离的方式使用调用链隔离的方式进行隔离
使用上下层调用链的方式进行隔离。
1.4 总结
有点很明显，简单易上手并且公共能力提供比较好。缺点也很明显，服务一多之后就很难管理了。
2. 分群模式（子系统）
2.1 概念
以贴合团队管理的方式进行服务的划分工作，这里就可以很好的服务康威定律和逆康威定律。一个团队负责整体系统中的一部分业务，而业务与业务之间有着天然的隔离能力。
2.2 例子
-
openstack中的分群
在openstack的架构中很容易就可以看到，每一个部分是由一群服务来完成的。有专门对外提供能力的，有专门处理业务的，有负责存储的。这一群服务来完成一个业务模块。
2.3 特点
隔离性强
将所有非本群中的服务都认为是第二方服务。然后以管理第二方的方式对外进行管理工作。这样故障基本上就可以隔离在服务群内部。服务群之间的业务边界明显
服务群之间的业务是有着明显的边界的，如果边界模糊或边界不清晰就可以将两个团队合并。但在分层模式中很难进行层次之间的合并。服务群管理可以交给一个团队完成
服务群可以更贴近业务的方式对服务进行划分，所以，业务相近的服务交给一个团队比较合适。无法很好的定义服务群之间的协作关系
具体是服务群A给服务群B提供基础能力，还是服务群B向服务群A提供业务能力。很难进行定义。但在分层中，层次关系就定义了能力的提供方向。
2.4 总结
服务群能很好的进行业务团队之间的隔离，但能力的公用就很难在服务群中被解决。
3. 总结
其实还有一种模式未进行讨论：微服务大泥球。即服务之间是平等的，任何服务都可以调用任何其他服务。这样存在着比较大的问题：调用链无法进行管理，故障无法进行隔离。所以，这里不讨论这种方式。
其实这两种服务间关系的管理方式很多时候也是混用的，并不必要在一个系统中只用一种模式。这个就需要架构师来判断哪些地方使用那种，在不同的地方使用不同的模式即可。
