微服務經驗分享&雜談

微服務架構

一個應用，拆分爲多個小服務，這樣的架構方式，就是微服務架構

微服務核心要素

微服務架構實例

咱們拿一個電商貸款場景（如京東白條）劃分微服務舉例，以便後面的描述。 購買場景主要有以下關鍵服務。

• 帳戶服務：負責管理用戶基本信息，如姓名，性別，身份證等
• 額度服務：用戶所能使用的額度。
• 支付服務：負責完成支付操做。
• 帳單服務：指定時間生成帳單給用戶。
• 風控服務：經過數據分析，管理用戶操做權限。

咱們一開始設計出以下圖的服務架構：

對比的微服務的標準： 符合單獨部署； 符合進程獨立； 服務間通訊使用rpc，符合輕量級。

專一於一件事這一點，看起來是符合，可是咱們結合兩個實際流程：

支付流程：

註冊流程：

咱們能夠看到，除了微服務自己的邏輯，在具體流程下，部分微服務還要考慮如何和別的服務串起來，也就是說，原有的邏輯層，並未消失，而是分散到了各個微服務，職責並不單一！

因而架構進化：

能夠看到，多了一層聚合層。專門負責聚合領域層的數據，對外提供接口。而領域層的微服務，只用承擔好本身領域的職責，提供出獨立，通用的服務接口。但在業務擴展的過程當中，咱們發現聚合層業務愈來愈重，因而乎，咱們須要繼續演進：

聚合層也作了拆分，因而，領域層是一組微服務，聚合層是一組微服務，職責清晰。聚合層劃分一般能夠考慮到實際業務的前端界面，頁面爲最小粒度來考慮聚合層微服務，不失爲一個參考辦法，即一個頁面或者幾個頁面爲一個微服務。

微服務的優點與劣勢

五年前加入騰訊時仍是使用典型的logic-server架構，後面微服務如燎原之火，成了新的主角。後續經歷的上市外企，tmd中的一家，微服務也是大行其道。也時常思考微服務的必要性。

微服務 優勢:

1. 模塊小而獨立，方便新人上手；
2. 發佈時候，只發布對應的微服務，減小依賴和查錯成本。
3. 因爲拆分得比較細，重構時不容易背太大的技術債務。
4. 新的微服務中，能夠大膽使用新技術，不受原有模塊的制約。

缺點

1. 容易只關注本身一畝三分地，對總體把握不足。
2. 微服務真正的難點在於劃分，若是劃分不當，那麼服務存在耦合，好比一些狀態信息，是服務b管理，可是服務a又十分須要，此時不管是通知仍是輪詢，都是很麻煩的事。
3. 一個完整數據，可能須要從多個服務反覆獲取，若是存在層級關係，可能一個請求就致使幾十個rpc。
4. 後臺開發中每一個其餘服務都是不可信的，都須要作錯誤處理，那此時聚合層若是調用5個領域服務成功，一個領域失敗，拋出錯誤仍是降級服務，也是個讓人得具體思考的問題。

經驗總結

經驗

• 註冊等數據初始場景，只能作同步調用，拿上面的貸款場景舉例，若是帳戶額度初始化都沒成功，那麼支付的時候也會有問題。因此一步錯，必須返回錯誤給前端。此時考慮回滾，但回滾成本過高，分佈式事務是一個很難解決，而且很重的場景。而註冊這種用戶必須得重試的場景，能夠依賴接口可重入解決。
• 能異步的場景，儘可能異步，好比支付完成，入賬帳單，帳單並不須要實時，此時就能夠經過消息隊列推送。
• 不要過分劃分，十多個服務打交道的成本，比想象中大不少。一開始粒度能夠稍微大點，後面再劃分。

總結

1. 微服務最大的貢獻，我的認爲在人力調度上，一個新人能夠很快地上手某個微服務而不須要其餘業務背景。若是團隊比較穩定，那麼建議服務劃分比較粗一點，人員流動很厲害，就能夠稍微細些。
2. 不要爲用微服務而用，其不是銀彈。小型公司創業階段，就圖短平快，不必扯這些虛的。
3. 微服務容易讓人只管本身一畝三分地。而劃分微服務也是個很考經驗的事情。因此若是要使用微服務，須要有一我的來專門研究微服務，由他來總體劃分和持續調整。
4. 微服務由於調用服務間變得不少，若是是比較難發生的異常場景，去保證自動兼容或修復成本過高了。此時，能夠考慮輕輕地打一條日誌或一些其餘後臺監控手段，人工解決。