資訊專欄INFORMATION COLUMN
摘要：服務化的出現假想一個京東的發展路程都是我虛構的。更多的服務的提取抽離，更多的團隊出現業務繼續發展，出現了京東大藥房，專門賣藥，需要調用京東目前的財務系統。
更多詳情請看直播 揭開她的神秘面紗 - 零基礎構建自己的服務治理框架以下內容都是自己的理解，不保證正確，可能是對的，也可能把你帶溝里，自己甄別。
https://segmentfault.com/l/15...
很久之前聽別人分享他們的架構，總會說，因為某某原因，我們進行服務化，我們公司開發了一套服務治理框架。
當時虎軀為之一震，趕緊在手機上記下關鍵詞：“服務化”、“服務治理”、“服務治理框架”。
回去之后馬上搜索，覺得很高大上，弄不懂，為什么要服務化，到底什么是服務治理啊？
很多文章一上來就直接講他們的服務治理多 NB，對于新人來說卻總有一種鏡花水月的感覺，那么我這次，希望從架構的演變出發，逐步說明，希望能讓大家豁然開朗。
服務化的出現總體思路：業務的解耦使得服務化的出現，多套服務化的出現代碼冗余，管理不便最終使得服務治理的出現。
假想一個京東的發展路程（都是我虛構的）。
最初是一個簡單的類似的 ecshop 的購物網站，由 A 團隊在迭代開發。突然有一天運營發現，我們需要一個社區，增加用戶的粘性。
招兵買馬，組件團隊，這個時候京東已經足夠龐大，代碼也很復雜，新團隊（cname B）開發一個社區，如果在原來基礎上打補丁式的開發，反而不合適，所以最終決定開發一套全新的系統。既然是同一家公司，那么沒有理由要用戶重新在社區注冊吧？應該是用戶在 www.jd.com/login 登錄了，然后在論壇 bbs.jd.com 就應該能獲取用戶的基本信息。
那怎么在論壇里獲取用戶的基本信息呢？
為了新人更好的理解，我隨便編了一種方案：
用戶在 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 做驗證，驗證通過之后，算用戶已經登錄。
如此，A 團隊和 B 團隊一起攜手幸福合作了一段時間。
隨著業務的發展，賬號變得越來越復雜，比如我們綁定的社交賬號越來越多，各家郵箱也很多，手機號登錄，企業賬號、子賬號、會員等級等等業務。
我們都知道開發的原則的高內聚，低耦合。最后 A 團隊的老司機，將原來的賬號相關的代碼，獨立出來多帶帶部署。分配域名account.jd.com。這樣用戶都統一到account.jd.com進行登錄， A 團隊和 B 團隊都調用account.jd.com的接口來驗證（走內網 ip:port ）。
災難的發生某一天賬號中心集群被 ddos 攻擊，被機房直接封 ip 了，而 A 團隊和 B 團隊都不知道，很多請求都阻塞在了用戶的身份鑒權接口的驗證上。導致請求越來越多，timeout 時間設置的也比較長，這樣網站都越來越卡。
A 團隊和 B 團隊都吸取了教訓，做出了如下方案：
周期性的去對賬號中心的服務進行健康，比如一分鐘檢測一次。
如果發現服務不可用，那么就緩存服務的狀態10分鐘（unusable），期間繼續不停的進行健康巡查，發現服務可用，則修改狀態為服可用。
發現服務不可用的時候，直接拋出異常，不在阻塞等待。
三方都添加了報警，如果服務不可用，都會收到報警。
更多的服務的提取抽離，更多的團隊出現業務繼續發展，出現了京東大藥房，專門賣藥，需要調用京東目前的財務系統。循環上面的邏輯，財務系統獨立出來了。
大藥房也要調用賬號中心的服務和財務服務。
也要部署之前在 A 團隊和 B 團隊的那套容錯代碼。
服務提供方的變動ip:port 的變動
所有的服務使用者的代碼都修改使用新的ip:port
開會開會 提出服務治理現在系統的代碼都被 A/B/C/D 各個團隊在用，地址更新了了還要手動更新了，我們能不能做到，服務提供者地址更新了，能推送到所有服務消費者。
之前 A,B 對賬號中心的服務做的服務的管理，其實一套通用的方案，能不能搞出來一個平臺或者服務（服務治理的雛形），A/B/C/D 都依賴我這個服務（服務治理的雛形），通過這個服務再去管理各個服務。
也就是現在這個服務治理的就是來管理各個服務，目前有兩個功能，服務注冊、服務訂閱、服務的推送。
a 服務提供方說，我們過幾天要做壓測，你們別不能請求我們192.168.0.10，你們都請求192.168.0.11。哦！也就是權重，把前者的權重調為0，好，所有的服務提供方都可能會有這種需求。那么服務治理也承包了。
b 服務提供方說，你們寫訂單的時候調用我們192.168.0.12，查訂單的時候調我們192.168.0.13或者192.168.0.14。哦！這不是咱們的讀寫分離的套路么，行，我們服務治理加個路由功能，服務提供者只要在動態的配置就行，我們再動態推給消費者。
服務治理的完善整理會議的精髓：
我們服務治理中心，需要一個注冊中心，統計都有哪些人提供了哪些服務，然后消費者，在啟動服務的時候，像注冊中心發送請求，我們需要哪些服務，注冊中心推送提供者的服務信息。
我們服務治理中心，需要一個監控中心，統計各個服務提供的次數、服務響應的時間、服務的健康狀態。
服務提供者和服務消費者之間通信，我們就別走 http 了，我們改成自定義協議，自己封裝一套
rpc 協議才是我們的良藥，這樣我們就像在使用本地方法一樣調用遠程的方法了（這個 php 理解可能有點莫名其妙，推薦學習 java，java 是每個老司機繞不過的坎），最好是服務提供者和服務消費者之間使用長連接，減少每次請求連接的時間消耗和網絡I/O。這個rpc協議也由我們服務治理還給大家指定吧。
就寫到這了吧！
還沒聽夠，老鐵，更多詳情請看直播 揭開她的神秘面紗 - 零基礎構建自己的服務治理框架https://segmentfault.com/l/15...
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/23263.html
摘要：也就使得企業在采用云服務時，多云管理成為首要痛點。而企業部署混合云戰略時，最先解決的一大要務就是簡化混合云的管理和部署，選擇符合自身需求的多云管理平臺。云管理和云連接多廠商異構云平臺的統一管控是多云管理的基礎。云計算作為業務戰略發展的長期選擇已成為行業共識，而混合云作為云計算領域的一匹黑馬，開始被越來越多的企業采納，成為主流的云計算模式，谷歌、微軟、阿里云等已紛紛實施混合云部署戰略。根據云星...
摘要：需求在了解了前面我們關于服務治理出現的必要性之后。我們知道服務治理是建立在眾多服務基礎之上的，那么，第一步，打通這些服務是基礎，也就是我們常說的遠程調用。上面執行遠程調用也類似。 需求 在了解了前面我們關于服務治理出現的必要性之后。我們知道服務治理是建立在眾多服務基礎之上的，那么，第一步，打通這些服務是基礎，也就是我們常說的 RPC 遠程調用。要像調用本地方法一樣調用遠程服務器上的方法...
摘要：云計算十大關鍵詞分別是云原生高性能混沌工程混合云邊緣計算零信任優化治理數字政府低碳云企業數字化轉型。當前，云原生與云安全呈加速融合趨勢。 7月27日，由中國信息通信研究院、中國通信標準化協會主辦的2021年可信云大會在京召開。中國信息通信研究院云計算與大數據研究所所長何寶宏在會上正式發布2021云計算十大關鍵詞以及對應的重要發展趨勢。 ? ...
摘要：目前，網易云輕舟微服務平臺已經應用于銀行證券視頻監控物流工業等行業不少中大型企業，幫助其實施微服務化改造，建設符合行業特點的業務中臺，支撐企業數字化戰略的落地。 微服務技術由于天生支持快速迭代、彈性擴展的特點，使企業能夠在不確定性下提升發展速度及抗風險能力，受到了越來越多的關注。當前，云服務商紛紛試水微服務產品，最為典型的，當屬推出輕舟微服務平臺、劍指整個微服務應用生命周期的網易云。 ...
摘要：劉超，網易云計算首席架構師，有多年的云計算架構與開發經歷，積累了豐富的企業級應用的微服務化，容器化實戰經驗。近日，記者對劉超進行了采訪，跟大家分享了微服務實戰的挑戰和一些常見的微服務誤解，以及他對微服務發展趨勢的判斷。 劉超，網易云計算首席架構師，有10多年的云計算架構與開發經歷，積累了豐富的企業級應用的微服務化，容器化實戰經驗。劉超將擔任今年 5 月份 QCon 全球軟件開發大會廣州...
閱讀 3291·2021-11-25 09:43
閱讀 2093·2021-09-22 10:02
閱讀 3348·2021-09-06 15:00
閱讀 2305·2019-08-30 15:56
閱讀 2356·2019-08-30 15:54
閱讀 3233·2019-08-30 14:14
閱讀 2268·2019-08-29 17:25
閱讀 2909·2019-08-29 17:16
