一個應用，拆分為多個小服務，這樣的架構方式，就是微服務架構
微服務核心要素
微服務架構實例
我們拿一個電商貸款場景（如京東白條）劃分微服務舉例，以便后面的描述。 購買場景主要有如下關鍵服務。
- 賬戶服務：負責管理用戶基本信息，如姓名，性別，身份證等
- 額度服務：用戶所能使用的額度。
- 支付服務：負責完成支付操作。
- 賬單服務：指定時間生成賬單給用戶。
- 風控服務：通過數據分析，管理用戶操作權限。
我們一開始設計出如下圖的服務架構：
對比的微服務的標準： 符合單獨部署； 符合進程獨立； 服務間通信使用rpc，符合輕量級。
專注于一件事這一點，看起來是符合，但是我們結合兩個實際流程：
支付流程：
注冊流程：
我們可以看到，除了微服務本身的邏輯，在具體流程下，部分微服務還要考慮如何和別的服務串起來，也就是說，原有的邏輯層，并未消失，而是分散到了各個微服務，職責并不單一！
于是架構進化：
可以看到，多了一層聚合層。專門負責聚合領域層的數據，對外提供接口。而領域層的微服務，只用承擔好自己領域的職責，提供出獨立，通用的服務接口。但在業務擴展的過程中，我們發現聚合層業務越來越重，于是乎，我們需要繼續演進：
聚合層也做了拆分，于是，領域層是一組微服務，聚合層是一組微服務，職責清晰。聚合層劃分通常可以考慮到實際業務的前端界面，頁面為最小粒度來考慮聚合層微服務，不失為一個參考辦法，即一個頁面或者幾個頁面為一個微服務。
微服務的優勢與劣勢
五年前加入騰訊時還是使用典型的logic-server架構，后面微服務如燎原之火，成了新的主角。后續經歷的上市外企，tmd中的一家，微服務也是大行其道。也時常思考微服務的必要性。
微服務 優點:
- 模塊小而獨立，方便新人上手；
- 發布時候，只發布對應的微服務，減少依賴和查錯成本。
- 由于拆分得比較細，重構時不容易背太大的技術債務。
- 新的微服務中，可以大膽使用新技術，不受原有模塊的制約。
缺點
- 容易只關注自己一畝三分地，對整體把握不足。
- 微服務真正的難點在于劃分，如果劃分不當，那么服務存在耦合，比如一些狀態信息，是服務b管理，但是服務a又十分需要，此時無論是通知還是輪詢，都是很麻煩的事。
- 一個完整數據，可能需要從多個服務反復獲取，如果存在層級關系，可能一個請求就導致幾十個rpc。
- 后臺開發中每個其他服務都是不可信的，都需要做錯誤處理，那此時聚合層如果調用5個領域服務成功，一個領域失敗，拋出錯誤還是降級服務，也是個讓人得具體思考的問題。
