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

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協議也由我們服務治理還給大家指定吧。

就寫到這了吧！

 揭開她的神祕面紗 - 零基礎構建自己的服務治理框架