微服務實踐目錄，可以參見連接。
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. 總結
其實還有一種模式未進行討論：微服務大泥球。即服務之間是平等的，任何服務都可以調用任何其他服務。這樣存在著比較大的問題：調用鏈無法進行管理，故障無法進行隔離。所以，這里不討論這種方式。
其實這兩種服務間關系的管理方式很多時候也是混用的，并不必要在一個系統中只用一種模式。這個就需要架構師來判斷哪些地方使用那種，在不同的地方使用不同的模式即可。
