你正在開發(fā)一個大型的復(fù)雜項目，并且你想要使用微服務(wù)架構(gòu)。微服務(wù)架構(gòu)把應(yīng)用的結(jié)構(gòu)變成了一系列松耦合的服務(wù)。使用微服務(wù)架構(gòu)的目的是通過持續(xù)交付、持續(xù)部署來加速軟件開發(fā)的速度。

微服務(wù)架構(gòu)用兩種方式來達到目的：

1. 簡化測試，使得組件可以獨立部署
2. 把工程師團隊分成一個個小的、自主的團隊（6到10人），每個團隊負責(zé)一個或多個服務(wù)

這些好處不是自動就能得到的，相反的，它需要我們對服務(wù)有一個仔細的劃分。

一個服務(wù)必須足夠小，使得可以被一個小的團隊開發(fā)和測試。從面向?qū)ο笤O(shè)計那里學(xué)到的一個有用的方法是單一職責(zé)原則。

應(yīng)用也要被一種合適的方法拆分，從而大多數(shù)新的和修改的需求只影響到單個service。因為影響到多個service的改動需要多個團隊之間的合作，這會拖慢開發(fā)的速度。另一個面向?qū)ο笤O(shè)計的有效原則是共同封閉原則，它是說，因為同一個原因修改的類應(yīng)該在同一個包中。這種思想在設(shè)計服務(wù)時也同樣有效：每個變化應(yīng)該只影響一個service。

二、問題和強制條件

如何把應(yīng)用拆解成服務(wù)？

• 架構(gòu)應(yīng)該穩(wěn)定
• 一個服務(wù)應(yīng)該實現(xiàn)一個強相關(guān)的方法的小集合
• 服務(wù)必須遵從共同封閉原則
• 服務(wù)應(yīng)該松耦合：一個服務(wù)的實現(xiàn)的變化不影響調(diào)用它的API的客戶端
• 服務(wù)應(yīng)該是可測試的
• 服務(wù)應(yīng)該足夠小，可以被6到10人的小團隊開發(fā)
• 每個團隊?wèi)?yīng)該是自主的。一個團隊可以開發(fā)和部署他們的服務(wù)，而只需要和別的團隊有一些最小的合作

業(yè)務(wù)能力是業(yè)務(wù)架構(gòu)模型中的一個概念。業(yè)務(wù)模型經(jīng)常對應(yīng)于一個業(yè)務(wù)對象，比如說：訂單管理負責(zé)訂單，客戶管理負責(zé)客戶。

業(yè)務(wù)能力經(jīng)常組織成一個多層等級。比如說，一個企業(yè)應(yīng)用也許有頂級的分類，如產(chǎn)品開發(fā)、產(chǎn)品交付、需求挖掘等。

示例

一個在線商城的業(yè)務(wù)能力包括：

• 產(chǎn)品目錄管理
• 存貨管理
• 訂單管理
• 發(fā)貨管理
• …

對應(yīng)的微服務(wù)架構(gòu)會有一些服務(wù)對應(yīng)于這些業(yè)務(wù)能力：

結(jié)果

2. 根據(jù)子域拆分

定義對應(yīng)于領(lǐng)域驅(qū)動設(shè)計（DDD）的子域的服務(wù)。 一個領(lǐng)域由多個子域組成。每個子域?qū)?yīng)了業(yè)務(wù)的不同組成部分。

子域可以被這樣分類：

• 核心: 業(yè)務(wù)的核心區(qū)分點，應(yīng)用的最有價值的部分
• 支持： 與業(yè)務(wù)是做什么的相關(guān)，但不是主要區(qū)分點。這個可以自己做或者外包。
• 通用： 不特定于業(yè)務(wù)，理想情況下使用現(xiàn)成的軟件來實現(xiàn)

示例

一個在線商城的子域包括

• 商品目錄
• 存貨管理
• 訂單管理
• 發(fā)貨管理
• …

對應(yīng)的微服務(wù)架構(gòu)會有一些服務(wù)對應(yīng)于這些子域。

結(jié)果

這種模式有以下這些好處：（與上面的方法一樣的）

• 架構(gòu)穩(wěn)定，因為業(yè)務(wù)能力相對比較穩(wěn)定
• 開發(fā)團隊是自主的，圍繞著交付業(yè)務(wù)價值而不是技術(shù)特性來組織
• 服務(wù)之間共同合作，松耦合

問題