服務治理

看服務治理的時候發現的大神文章，寫的太好了

原連接：http://javatar.iteye.com/blog/1345073

 

在大規模服務化以前，應用可能只是經過RMI或Hessian等工具，簡單的暴露和引用遠程服務，經過配置服務的URL地址進行調用，經過F5等硬件進行負載均衡。 

(1) 當服務愈來愈多時，服務URL配置管理變得很是困難，F5硬件負載均衡器的單點壓力也愈來愈大。 

此時須要一個服務註冊中心，動態的註冊和發現服務，使服務的位置透明。 

並經過在消費方獲取服務提供方地址列表，實現軟負載均衡和Failover，下降對F5硬件負載均衡器的依賴，也能減小部分紅本。 

(2) 當進一步發展，服務間依賴關係變得錯蹤複雜，甚至分不清哪一個應用要在哪一個應用以前啓動，架構師都不能完整的描述應用的架構關係。 

這時，須要自動畫出應用間的依賴關係圖，以幫助架構師理清理關係。 

(3) 接着，服務的調用量愈來愈大，服務的容量問題就暴露出來，這個服務須要多少機器支撐？何時該加機器？ 

爲了解決這些問題，第一步，要將服務如今天天的調用量，響應時間，都統計出來，做爲容量規劃的參考指標。 

其次，要能夠動態調整權重，在線上，將某臺機器的權重一直加大，並在加大的過程當中記錄響應時間的變化，直到響應時間到達閥值，記錄此時的訪問量，再以此訪問量乘以機器數反推總容量。 

(4) 規模繼續擴大，應用之間再也不是扁平的對應關係，開始分層，好比核心數據層，業務集成層等，就算沒有出現循環依賴，也不容許從低層向高層依賴，以避免後續被逼循環依賴。 

這時，須要在註冊中心定義架構體系，列明有哪些層的定義，每一個服務暴露或引用時，都必須聲明本身應用屬於哪一層，這樣註冊中心能更快的發現架構的腐化現象。 

(5) 服務多了，溝通成本也開始上升，調某個服務失敗該找誰？服務的參數都有什麼約定？ 

這時就須要登記每一個服務都是誰負責的，並創建一個服務的文檔庫，方便檢索。 

(6) 慢慢一些敏感數據也都服務化了，安全問題開始變得重要，誰能調該服務？如何受權？ 

這樣的服務可能須要一個密碼，訪問時需帶着此密碼，但若是用密碼，要改密碼時，就會很不方便，全部的消費方都要改，因此動態生成令牌(Token)可能會更好，提供方將令牌告之註冊中心，由註冊中心決定是否告之消費方，這樣就能在註冊中心頁面上作複雜的受權模型。 

(7) 就算是不敏感的服務，也不是能任意調用，好比某服務忽然多了一個消費者，這個消費者的請求量直接把服務給拖跨了，其它消費者跟着一塊兒故障。 

首先服務提供方須要流控，當流程超標時，能拒絕部分請求，進行自我保護。 

其次，消費者上線前和提供者約定《服務質量等級協定(SLA)》，SLA包括消費者承諾天天調用量，請求數據量，提供方承諾響應時間，出錯率等，將SLA記錄在監控中心，定時與監控數據對比，超標則報警。 

(8) 雖然有SLA約定，若是不能控制，就只是君子協定，如何確保服務質量？ 

好比：一個應用很重要，一個不那麼重要，它們調用同一個服務，這個服務就應該向重要應用傾斜，而不是一視同仁，當支撐不住時，應限制不重要應用的訪問，保障重要應用的可用，如何作到這一點呢。這時，就須要服務路由，控制不一樣應用訪問不一樣機器，好比： 
應用分離： 
consumer.application = foo => provider.host = 1,2,3 
consumer.application != foo => provider.host = 5,6 
讀寫分離： 
method.name = find*,get* => provider.host = 1,2,3 
method.name != find*,get* => provider.host = 5,6 

(9) 服務上線後，須要驗證服務是否可用，但因防火牆的限制，線下是不能訪問線上服務的，不得不先寫好一個測試Main，而後放到線上去執行，很是麻煩，而且容易忘記驗證。 

因此線上須要有一個自動運行的驗證程序，用戶只需在界面上填上要驗證的服務方法，以及參數值和指望的返回值，當有一個服務提供者上線時，將自動運行該用例，並將運行結果發郵件通知負責人。 

(10) 服務應用和Web應用是有區別的，它是一個後臺Daemon程序，不須要Tomcat之類的Web容器。但因公司以前以Web應用爲主，規範都是按Web應用的，因此不得不把服務跑在一個根本用不上的Web容器裏，而搭一個這樣的Web工程也很是費事。 

因此須要實現一個非Web的容器，只需簡單的Main加載Spring配置便可，並提供Maven模板工程，只需mvn dubbo:generate 便可建立一個五臟俱全的服務應用。 

(11) 開發服務的人愈來愈多，更注重開發效率，IDE的集成支持必不可少。 

經過插件，能夠在Eclipse中直接運行服務，提供方能夠直接填入測試數據測試服務，消費方能夠直接Mock服務不依賴提供方開發。 

(12) 由於暴露服務很簡單，服務的上線愈來愈隨意，有時候負責服務化的架構師都不知道有人上線了某個服務，使得線上服務魚龍混雜，甚至出現重複的服務，而服務下線比上線還困難。 

須要一個新服務上線審批流程，必須通過服務化的架構師審批過了，才能夠上線。 

而服務下線時，應先標識爲過期，而後通知調用方儘快修改調用，直到沒有人調此服務，才能下線。 

(13) 因服務接口設計的經驗一直在慢慢的積累過程當中，不少接口並不能一促而蹴，在修改的過程當中，如何保證兼容性，怎麼判斷是否兼容？另外，更深層次的，業務行爲兼容嗎？ 

能夠根據使用的協議類型，分析接口及領域模型的變動是否兼容，好比：對比加減字段，方法簽名等。 

而業務上，可能須要基於自動迴歸測試用例，造成Technology Compatibility Kit (TCK)，確保兼容升級。 

(14) 隨着服務的不停升級，總有些意想不到的事發生，好比cache寫錯了致使內存溢出，故障不可避免，每次核心服務一掛，影響一大片，人心慌慌，如何控制故障的影響面？服務是否能夠功能降級？或者資源劣化？ 

應用間聲明依賴強度，哪些功能強依賴，哪些弱依賴，而後基於依賴強度，計算出影響面，並按期測試複查，增強關鍵路徑上的服務的優化和容錯，清理不應在關鍵路徑上的服務。 

提供容錯Mock數據，Mock數據也應能夠在註冊中心在運行時動態下發，當某服務不可用時，用Mock數據代替，能夠減小故障的發生，好比某驗權服務，當驗權服務所有掛掉後，直接返回false表示沒有權限，並打印Error日誌報警。 

另外，前端的頁面也應採用Portal進行降級，當該Portal獲取不到數據時，直接隱藏，或替換爲其它模塊展現，並提供功能開關，可人工干預是否展現，或限制多少流量能夠展現。 

(15) 當已有不少小服務，可能就須要組合多個小服務的大服務，爲此，不得不增長一箇中間層，暴露一個新服務，裏面分別調其它小服務，這樣的新服務業務邏輯少，卻帶來不少開發工做量。 

此時，須要一個服務編排引擎，內置簡單的流程引擎，只需用XML或DSL聲明如何聚合服務，註冊中心能夠直接下發給消費者執行聚合邏輯，或者部署通用的編排服務器，全部請求有編排服務器轉發。 

(16) 並非全部服務的訪問量都大，不少的服務都只有一丁點訪問量，卻須要部署兩臺提供服務的機器，進行HA互備，如何減小浪費的機器。 

此時可能須要讓服務容器支持在一臺機器上部署多個應用，能夠用多JVM隔離，也能夠用ClassLoader隔離。 

(17) 多個應用若是不是一個團隊開發的，部署在一臺機器上，頗有能夠誤操做，停掉了別人的服務。 

因此須要實現自動部署，全部的部署都無需人工干擾，最好是一鍵式部署。 

(18) 機器老是的閒時和忙時，或者冗餘機器防災，如何提升機器的利用率？ 

即然已經能夠自動部署了，那根據監控數據，就能夠實現資源調度，根據應用的壓力狀況，自動添加機器並部署。

若是你的應用是國際化的，有中文站，美國站之類，由於時差，美國站的機器晚上閒的時候，可能正是中文站的白天忙時，能夠經過資源調度，分時段自動調配和部署雙方應用。