定義微服務架構
如何定義一個微服務架構？ 不同的人有不同的定義方法，我介紹一種我使用並且效果還不錯的定義方法。
第一步定義系統操作，通過將應用程式的需求提煉為各種關鍵功能。
第二步分解服務，這裡會有不同的分解策略，常規使用的一般有兩種（按照業務能力定義和圍繞領域驅動設計的子域設計）。
第三步 確定每個服務的API及協作方式及流程，因為要與其他服務協作，協作的方式是採用同步呼叫還是訊息的通訊機制。
第四步 通過前面三步之後，應用程式的初步服務已經分解出來了，但是仍然會有不足的地方，隨著對應用程式領域的瞭解越來越多，會發現更多的問題，這個時候就需要針對這些問題選擇更好的解決方式。例如你可能會發現過多的服務呼叫可能會導致特定的分解效率低下，導致你必須把一些服務組合在一起。反之，服務可能會越來越複雜，需要將其拆分成多個服務的程度。
1. 識別系統操作
如何識別系統操作，我們都知道在軟體開發流程中，起點是來自業務方的需求（包括使用者故事或對應的使用者場景）。我們使用兩步式流程識別和定義系統操作：
- 第一步建立由關鍵類組成的抽象領域模型，關鍵類提供用於描述系統操作的詞彙。
- 第二步定義系統操作，並根據領域模型描述每個系統操作的行為。
1.1 建立抽象領域模型
建立領域模型會採用一些標準的技術，例如與領域專家溝通後，分析需求和使用者場景中頻繁出現的名詞。例如 Place an order 使用者故事，我們可以把它分解為多個使用者場景（使用者收貨地址，訂單資訊，商品搜尋） 。場景中出現的名稱，如 Order、User、Product，我們可以將至對應到操作類
- User：下訂單的使用者
- Order：使用者操作的訂單
- Product：使用者搜尋的商品資訊
1.2 定義系統操作
系統操作一般分為兩類
- 命令型：建立、更新或刪除資料的操作
- 查詢型：查詢和讀取資料的操作
| 服務 | 操作 | 命令 | 描述 |
|---|---|---|---|
| User | Get User | getUserInfo | 獲取使用者資訊 |
| Order | create Order | createOrder | 建立一個訂單 |
| Product | Get Product | getProductInfo | 獲取一個商品資訊 |
2. 定義服務
服務的識別會有多種策略，但是結果都是以業務為中心
2.1 根據業務能力進行服務拆分
業務能力是指一些能夠為公司產品價值的商業活動或產品。例如 電商公司的業務能力包括：訂單管理、庫存管理和發貨、商品管理等。
識別業務能力：一個組織或應用程式有哪些業務能力，是通過對組織的目標、結構分析得來的。每一個業務能力都可以認為是一個或多個服務。以YShop為例，其業務能力分為：訂單管理、庫存管理、商品管理
從業務能力到服務：一旦確定了業務能力，就可以為每個能力或相關能力組定義服務
2.2 根據子域進行服務拆分
todo
3. 定義服務API和協作方式
定義服務的API也就是服務的操作和時間。服務API操作有兩種：
- 系統操作：由外部客戶端呼叫，也可能有其他服務呼叫
- 其他操作：和其他服務之間進行協作
3.1 協作方式
一般的協作方式有REST方式，提供對外API，供其他服務進行HTTP呼叫。還有通過訊息的非同步方式進行互動：
- 同步模式：客戶端請求需要服務端實時響應，客戶端等待影響時可能導致堵塞。
- 非同步模式：客戶端請求不是阻塞請求，服務端的響應非實時。
4. 持續優化和迭代
在最初的服務拆分完畢之後，隨著業務不斷的改變和對該領域知識的不斷深入，可能會覺得系統有很多可以優化和改進的地方，這個時候需要好好的衡量優化的意義和改進後是否會帶來新的問題。對現有業務來說是利大於弊 or 弊大於利，這需要認真思考。另外在服務拆分的時候記住兩個主要原則：
- 單一職責原則
- 閉包原則
5. 拆分單體應用未服務的難點
- 網路延遲
- 同步程式間通訊導致可用性降低
- 服務之間維持資料一致性
- 獲取一致的資料檢視