服務治理深刻淺出（1）- 服務治理出現的必要性探索

如下內容都是本身的理解，不保證正確，多是對的，也可能把你帶溝裏，本身甄別。

更多詳情請看直播 揭開她的神祕面紗 - 零基礎構建本身的服務治理框架

https://segmentfault.com/l/15...

好久以前聽別人分享他們的架構，總會說，由於某某緣由，咱們進行服務化，咱們公司開發了一套服務治理框架。

當時虎軀爲之一震，趕忙在手機上記下關鍵詞：「服務化」、「服務治理」、「服務治理框架」。
回去以後立刻搜索，以爲很高大上，弄不懂，爲何要服務化，到底什麼是服務治理啊？
不少文章一上來就直接講他們的服務治理多 NB，對於新人來講卻總有一種鏡花水月的感受，那麼我此次，但願從架構的演變出發，逐步說明，但願能讓你們豁然開朗。

整體思路：業務的解耦使得服務化的出現，多套服務化的出現代碼冗餘，管理不便最終使得服務治理的出現。

服務化的出現

假想一個京東的發展路程（都是我虛構的）。

1. 最初是一個簡單的相似的 ecshop 的購物網站，由 A 團隊在迭代開發。忽然有一天運營發現，咱們須要一個社區，增長用戶的粘性。
2. 招兵買馬，組件團隊，這個時候京東已經足夠龐大，代碼也很複雜，新團隊（cname B）開發一個社區，若是在原來基礎上打補丁式的開發，反而不合適，因此最終決定開發一套全新的系統。既然是同一家公司，那麼沒有理由要用戶從新在社區註冊吧？應該是用戶在 www.jd.com/login 登陸了，而後在論壇 bbs.jd.com 就應該能獲取用戶的基本信息。

3. 那怎麼在論壇裏獲取用戶的基本信息呢？
   爲了新人更好的理解，我隨便編了一種方案：

   • 用戶在 www.jd.com/login 登陸以後，www.jd.com 服務器端把一份對稱加密的 cookie 存在客戶端的 *.jd.com 下。
   • 而後 bbs.jd.com 服務器端拿到客戶端的 cookie 解密以後，獲得一個 json 串，{uid:xxxx,username:'xxx',token:'xxxx'}
   • 最後 bbs.jd.com 服務器端拿着 uid + token 去 www.jd.com 提供的一個 api 作驗證，驗證經過以後，算用戶已經登陸。
4. 如此，A 團隊和 B 團隊一塊兒攜手幸福合做了一段時間。
5. 隨着業務的發展，帳號變得愈來愈複雜，好比咱們綁定的社交帳號愈來愈多，各家郵箱也不少，手機號登陸，企業帳號、子帳號、會員等級等等業務。
6. 咱們都知道開發的原則的高內聚，低耦合。最後 A 團隊的老司機，將原來的帳號相關的代碼，獨立出來單獨部署。分配域名account.jd.com。這樣用戶都統一到account.jd.com進行登陸， A 團隊和 B 團隊都調用account.jd.com的接口來驗證（走內網 ip:port ）。

災難的發生

某一天帳號中心集羣被 ddos 攻擊，被機房直接封 ip 了，而 A 團隊和 B 團隊都不知道，不少請求都阻塞在了用戶的身份鑑權接口的驗證上。致使請求愈來愈多，timeout 時間設置的也比較長，這樣網站都愈來愈卡。

A 團隊和 B 團隊都吸收了教訓，作出了以下方案：

1. 週期性的去對帳號中心的服務進行健康，好比一分鐘檢測一次。
2. 若是發現服務不可用，那麼就緩存服務的狀態10分鐘（unusable），期間繼續不停的進行健康巡查，發現服務可用，則修改狀態爲服可用。
3. 發現服務不可用的時候，直接拋出異常，不在阻塞等待。
4. 三方都添加了報警，若是服務不可用，都會收到報警。

更多的服務的提取抽離，更多的團隊出現

1. 業務繼續發展，出現了京東大藥房，專門賣藥，須要調用京東目前的財務系統。循環上面的邏輯，財務系統獨立出來了。
2. 大藥房也要調用帳號中心的服務和財務服務。
3. 也要部署以前在 A 團隊和 B 團隊的那套容錯代碼。

服務提供方的變更

1. ip:port 的變更
2. 全部的服務使用者的代碼都修改使用新的ip:port

開會開會 提出服務治理

1. 如今系統的代碼都被 A/B/C/D 各個團隊在用，地址更新了了還要手動更新了，咱們能不能作到，服務提供者地址更新了，能推送到全部服務消費者。
2. 以前 A,B 對帳號中心的服務作的服務的管理，其實一套通用的方案，能不能搞出來一個平臺或者服務（服務治理的雛形），A/B/C/D 都依賴我這個服務（服務治理的雛形），經過這個服務再去管理各個服務。
3. 也就是如今這個服務治理的就是來管理各個服務，目前有兩個功能，服務註冊、服務訂閱、服務的推送。
4. a 服務提供方說，咱們過幾天要作壓測，大家別不能請求咱們192.168.0.10，大家都請求192.168.0.11。哦！也就是權重，把前者的權重調爲0，好，全部的服務提供方均可能會有這種需求。那麼服務治理也承包了。
5. b 服務提供方說，大家寫訂單的時候調用咱們192.168.0.12，查訂單的時候調咱們192.168.0.13或者192.168.0.14。哦！這不是我們的讀寫分離的套路麼，行，咱們服務治理加個路由功能，服務提供者只要在動態的配置就行，咱們再動態推給消費者。

服務治理的完善

整理會議的精髓：

1. 咱們服務治理中心，須要一個註冊中心，統計都有哪些人提供了哪些服務，而後消費者，在啓動服務的時候，像註冊中心發送請求，咱們須要哪些服務，註冊中心推送提供者的服務信息。
2. 咱們服務治理中心，須要一個監控中心，統計各個服務提供的次數、服務響應的時間、服務的健康狀態。
3. 服務提供者和服務消費者之間通訊，咱們就別走 http 了，咱們改爲自定義協議，本身封裝一套
   rpc 協議纔是咱們的良藥，這樣咱們就像在使用本地方法同樣調用遠程的方法了（這個 php 理解可能有點莫名其妙，推薦學習 java，java 是每一個老司機繞不過的坎），最好是服務提供者和服務消費者之間使用長鏈接，減小每次請求鏈接的時間消耗和網絡I/O。這個rpc協議也由咱們服務治理還給你們指定吧。

就寫到這了吧！

還沒聽夠，老鐵，更多詳情請看直播 揭開她的神祕面紗 - 零基礎構建本身的服務治理框架

https://segmentfault.com/l/15...