#朱郭隆、#服務化拆分、#服務定義、#服務監控、#服務治理、#故障定位 無論是縱向拆分還是橫向拆分，都是將單體應用龐雜的功能進行拆分，抽離成單獨的服務部署。但並不是說功能拆分的越細越好，過度的拆分反而會讓服務數量膨脹變得難以管理，因此找到符合自己業務現狀和團隊人員技術水準的拆分粒度才是可取的。 我建議的標準是按照每個開發人員負責不超過 3 個大的服務為標準，畢竟每個人的精力是有限的，所以在拆分微服務時，可以按照開發人員的總人數來決定。

1. @Author Aaron Chu
微服務架構
心懷感恩、面對起落、
擁抱生命的禮物 ~
@Github
github.com/agilego99
Aaron
@Mail
chukuo99@gmail.com

2. @Author Aaron Chu
入門微服務

3. @Author Aaron Chu
單體應用走
向服務化
入門
微服務

4. @Author Aaron Chu
思考題：
想想你現在的業務場景，如
果是單體應用的話，是否需
要進行服務化拆分？ 如果需
要的話，你覺得是縱向拆分
還是橫向拆分合適？ 具體可
以拆分到什麼粒度？

5. @Author Aaron Chu
何時該進行服務化拆分？

6. @Author Aaron Chu
服務化拆分
兩種姿勢
• 這種服務化拆分方式是縱向拆分，是從業務維度進
行拆分。 標準是按照業務的關聯程度來決定，關聯
比較密切的業務適合拆分為一個微服務，而功能相
對比較獨立的業務適合單獨拆分為一個微服務。
業務維度進行拆分：縱向拆分
• 另一種服務化拆分方式是橫向拆分，是從公共且獨
立功能維度拆分。 標準是按照是否有公共的被多個
其他服務調用，且依賴的資源獨立不與其他業務耦
合。
公共且獨立功能維度拆分：橫向拆分

7. @Author Aaron Chu
服務化拆分的前置條件(Cont.)
從單體應用遷移到微服務架構時必將面臨也必須解決的問題：
• 服務如何定義
• 對於微服務來說，每個服務都運行在各自的進程之中，透過通訊接口向外部傳達自身訊息，
無論採用哪種通訊協定，是 HTTP 還是 RPC，服務之間的調用都通過接口描述來約定，約
定內容包括接口名、接口參數以及接口返回值。
• 服務如何發佈和訂閱
• 拆分為微服務獨立部署後，服務提供者該對外暴露自己的地址，需要一個類似登記處的地
方（好比電話簿所提供的功能） ，記錄每個服務提供者的位址以供服務調用者查詢，提供
服務調用者查詢所需要調用的服務的位址 ，在微服務架構裡，這個地方就是註冊中心
一般情況下，業務系統引入新技術就必然會帶來架構的複雜度提升，在具體決策前，需要認識到新架構會帶來哪
些新的問題，這些問題你和你的團隊是否能夠解決？ 如何解決？ 是自己投入人力建設，還是採用業界開源方案？

8. @Author Aaron Chu
服務化拆分的前置條件(Cont.)
• 服務如何監控
• 對於一個服務，運維團隊所關心的 QPS（調用量）、AvgTime（平均耗時）以及 P999（99.9% 的請求
性能在多少毫秒以內）這些指標。 需要以一種通用的監控方案，能夠覆蓋業務埋點、資料收集、資料處
理，最後到資料展示的全鏈路功能。
• 服務如何治理
• 拆分為微服務架構後，服務的數量變多了，依賴關係也變複雜了。 比如一個服務的性能有問題時，依賴
的服務都勢必會受到影響。 可以設定一個調用性能閾值，如果一段時間內一直超過這個值，那麼依賴服
務的調用可以直接返回，這就是熔斷，也是服務治理最常用的手段之一。
• 故障如何定位
• 在單體應用拆分為微服務之後，一次使用者調用可能依賴多個服務，每個服務又部署在不同的節點上，
如果使用者調用出現問題，需要有一種解決方案能夠將一次使用者請求進行標記，並在多個依賴的服務
系統中繼續傳遞，以便串聯所有路徑，從而進行故障定位。

9. @Author Aaron Chu
本節重點
無論是縱向拆分還是橫向拆分，都是將單體應用龐雜的功能進
行拆分，抽離成單獨的服務部署。但並不是說功能拆分的越細
越好，過度的拆分反而會讓服務數量膨脹變得難以管理，因此
找到符合自己業務現狀和團隊人員技術水準的拆分粒度才是可
取的。 我建議的標準是按照每個開發人員負責不超過 3 個大
的服務為標準，畢竟每個人的精力是有限的，所以在拆分微服
務時，可以按照開發人員的總人數來決定。

10. @Author Aaron Chu

11. @Author Aaron Chu
小結附錄