微服務經驗分享&雜談
阿新 • • 發佈：2019-12-31
微服務架構
一個應用，拆分為多個小服務，這樣的架構方式，就是微服務架構
微服務核心要素
微服務架構例項
我們拿一個電商貸款場景（如京東白條）劃分微服務舉例，以便後面的描述。 購買場景主要有如下關鍵服務。
- 賬戶服務：負責管理使用者基本資訊，如姓名，性別，身份證等
- 額度服務：使用者所能使用的額度。
- 支付服務：負責完成支付操作。
- 賬單服務：指定時間生成賬單給使用者。
- 風控服務：通過資料分析，管理使用者操作許可權。
我們一開始設計出如下圖的服務架構：
對比的微服務的標準： 符合單獨部署； 符合程式獨立； 服務間通訊使用rpc，符合輕量級。
專注於一件事這一點，看起來是符合，但是我們結合兩個實際流程：
支付流程：
註冊流程：
我們可以看到，除了微服務本身的邏輯，在具體流程下，部分微服務還要考慮如何和別的服務串起來，也就是說，原有的邏輯層，並未消失，而是分散到了各個微服務，職責並不單一！
於是架構進化：
微服務的優勢與劣勢
五年前加入騰訊時還是使用典型的logic-server架構，後面微服務如燎原之火，成了新的主角。後續經歷的上市外企，tmd中的一家，微服務也是大行其道。也時常思考微服務的必要性。
微服務 優點:
- 模組小而獨立，方便新人上手；
- 釋出時候，只發布對應的微服務，減少依賴和查錯成本。
- 由於拆分得比較細，重構時不容易背太大的技術債務。
- 新的微服務中，可以大膽使用新技術，不受原有模組的制約。
缺點
- 容易只關注自己一畝三分地，對整體把握不足。
- 微服務真正的難點在於劃分，如果劃分不當，那麼服務存在耦合，比如一些狀態資訊，是服務b管理，但是服務a又十分需要，此時無論是通知還是輪詢，都是很麻煩的事。
- 一個完整資料，可能需要從多個服務反覆獲取，如果存在層級關係，可能一個請求就導致幾十個rpc。
- 後臺開發中每個其他服務都是不可信的，都需要做錯誤處理，那此時聚合層如果呼叫5個領域服務成功，一個領域失敗，丟擲錯誤還是降級服務，也是個讓人得具體思考的問題。
經驗總結
經驗
- 註冊等資料初始場景，只能做同步呼叫，拿上面的貸款場景舉例，如果賬戶額度初始化都沒成功，那麼支付的時候也會有問題。所以一步錯，必須返回錯誤給前端。此時考慮回滾，但回滾成本太高，分散式事務是一個很難解決，並且很重的場景。而註冊這種使用者必須得重試的場景，可以依賴介面可重入解決。
- 能非同步的場景，儘量非同步，比如支付完成，入帳賬單，賬單並不需要實時，此時就可以通過訊息佇列推送。
- 不要過度劃分，十多個服務打交道的成本，比想象中大很多。一開始粒度可以稍微大點，後面再劃分。
總結
- 微服務最大的貢獻，個人認為在人力排程上，一個新人可以很快地上手某個微服務而不需要其他業務背景。如果團隊比較穩定，那麼建議服務劃分比較粗一點，人員流動很厲害，就可以稍微細些。
- 不要為用微服務而用，其不是銀彈。小型公司創業階段，就圖短平快，沒必要扯這些虛的。
- 微服務容易讓人只管自己一畝三分地。而劃分微服務也是個很考經驗的事情。所以如果要使用微服務，需要有一個人來專門研究微服務，由他來整體劃分和持續調整。
- 微服務因為呼叫服務間變得很多，如果是比較難發生的異常場景，去保證自動相容或修復成本太高了。此時，可以考慮輕輕地打一條日誌或一些其他後臺監控手段，人工解決。