微服務架構淺析及實踐心得

1. SOA與微服務

  面向服務(SOA)已經不是一個新名詞了,跟Paxos有同樣古老的年齡,其本質是一種軟件架構的設計思想。相似「雲計算」的分層和服務提供概念(IaaS==>PaaS==>SaaS),SOA是把企業應用的業務功能以能力開放的形式提供出來,好比經過構建企業服務總線ESB來實現企業應用間的服務集成和編排。前端

而微服務更多的是對SOA的一種實踐方式(ESB也是SOA的一種實現方式),主要針對企業應用系統自己的架構設計作解耦和組件服務化,從業務上把原來龐大的系統拆分爲多個能夠獨立設計、獨立開發、獨立部署的小應用,小應用之間經過特定的交互協議(RPC/HTTP等)完成服務的暴露和調用。java

  關鍵詞:組件服務化,去中心化,分佈式,自動化部署和發佈nginx

2. 微服務與傳統集羣

  傳統集羣的常見架構通常是前端作負載均衡(F五、apache、nginx)反向代理一堆Web容器中的war,一般一個war就是整個應用(把整個應用放在一個進程中),後端再接統一的緩存和DB等等。而微服務的一種可能設計是前端作負載均衡,請求代理到控制層後調用部署在不一樣機器上的小應用來共同完成一次請求,小應用之間也會有相互的依賴調用,各個小應用自己能夠有本身的緩存和DB,也能夠多個小應用共用同一個持久層。web

  網上的一個對比圖:左邊是傳統集羣,右邊是微服務,能夠看到一個微服務的小應用就是一個進程,小應用之間的相互調用是經過進程間的通訊實現的而不是傳統組件依賴中的代碼調用,這樣就很是方便作到分佈式部署了。redis

 

  在web開發和部署中的對好比下圖所示:數據庫

 

3. 爲何須要微服務

  支撐互聯網公司快速發展的業務系統面臨着不斷的迭代,當系統規模達到必定的量級後就會發現重構是一件必需要進行但又很是痛苦甚至不可能完成的事情。系統的可擴展可伸縮性一直是架構師努力追求的目標,「業務拆分」是最天然有效的辦法,各個業務模塊相互獨立,形散而神聚,共同構建出一個功能強大的支撐系統。apache

  參考《大型網站技術架構》當中典型的系統演進路線和設計模式,系統的發展最後都會走到分佈式的路子上來,從「單工程單實例單庫」到「多工程多實例多緩存分表分庫」,系統的規模愈來愈龐大,複雜度也愈來愈高,考慮重構的時候首先從業務上尋找突破,可以從業務角度作出拆分的話,那麼就不要勉強的把系統和代碼揉合到一塊兒,只有當系統自己做爲一個獨立的業務體時仍是太龐大時那麼才考慮微服務。後端

4. 微服務實現

  「開發未動 設計先行」,實現系統的微服務化須要一些先決條件和不少的準備工做,首先是系統架構的整體設計,微服務中小應用的邊界通常是原系統中的一個業務模塊,下圖是中國電信CRM3.0的整體系統架構圖,微服務層面主要是按照業務模塊劃分了客帳戶中心、訂單中心、資產中心、資源中心等將近15中心化的微服務,各中心自治,獨立開發和發佈,能夠實現服務的快速迭代(從圖中也能夠看到ESB的影子)。設計模式

 

網上找的一張京東IM咚咚架構圖作對比(微服務化)緩存

 

  實施微服務帶來系統架構的變化的同時也會帶來開發團隊組織架構的變化(這是我結合之前工做經歷畫的一個草圖)之前咱們分前臺組,後臺組,規則組,架構組等,實施微服務後,按中心作劃分,一箇中心由一個小團隊負責,團隊成員可能有前臺也可能有後臺。

 

  組織架構調整好後就是開發流程,微服務更多強調的是「協議先行」(報文協議先約定好,而後並行開發),以及誰開發誰維護,開發人員參與到應用的整個生命週期。

  開發中一些好用的平臺化工具:

    自動化構建部署:Jenkins+Docker

    統一日誌平臺:Hlog

    統一配置平臺:uniConfig/CMDB

    統一監控管理平臺:AI-HPaaS

    在線API編輯和管理:ShowDoc(這個挺重要的,目前不少系統開發中接口都沒有造成文檔,致使後期維護升級很麻煩)

5. 服務治理框架

  微服務要求線上系統具有水平擴展的能力,那麼小應用和小應用之間的調用就不能直接寫成固定的IP地址了,這時候通常引入第三方的服務治理框架Spring Cloud /Dubbo(Dubbox)來作到服務發現、服務註冊、負載均衡、過載保護(熔斷和降級)等等。

Spring Cloud(Eureka):通常以Spring Boot爲基礎實現快速構建微服務應用,應用也再也不是必須打包成war部署到web容器中,而是打成jar包,直接 java -jar XXX.jar 運行。

Spring Cloud 中一些重要的組件有:Eureka、Robbion、Zuul、Hystrix、Config等等

Dubbo:註冊中心(Registry)通常能夠用zookeeper或者redis等實現,經過註冊中心來實現服務的自動註冊和發現。

 

6. 潛力與挑戰並存

  優點:

  可擴展性:解決了企業應用持久化層的瓶頸問題(關係數據庫單機性能問題以及NoSQL還不能徹底替代數據庫成爲持久層解決方案),同時,符合設計模式的單一職責原則,一個微服務應用自己只專一於某一個業務模塊,能夠根據業務特性單獨架構和優化更新,甚至選擇不一樣的技術棧,並且小應用自己代碼行數少相對來講產生Bug的概率也減小,也更利於小應用自己的測試和維護。

  可用性:經過服務熔斷和降級能夠有效保證應用系統的總體可用性,即便某個微服務的某個實例掛掉也不會影響系統的其餘功能。同時系統可水平擴展以提升總體吞吐量來適應業務的快速發展或者是併發量的忽然增長(如電商的秒殺和運營商的促銷活動等)

  並行開發:由於小應用之間是解耦的,這樣就能夠儘早約定接口協議而後開發人員並行開發,只要協議不變,那麼服務調用方對服務提供方的變化是無感知的,這樣下降了業務模塊之間的耦合度,有利於快速構建系統的原型。

  不足:

  系統複雜性增長:1.整個系統的內聚性下降了,常常會出現來了某個需求,要改好幾個服務(分別由不一樣的小團隊配合完成),工做中也常常聽到同事訴苦「以前一句SQL就搞定的接口如今要調3/4個服務)。2.因爲天生的分佈式特性,勢必會帶來數據一致性的問題,這對系統架構師是個很大的挑戰(必須從業務上尋找突破口來實現最終的一致性)。3.系統工程數量急劇增長,四川電信CRM系統實施微服務後工程數量由原來的40個不到一會兒增長到120+,給源碼管理和版本管控帶來了很大的挑戰。

  運維難度增大:變動或升級的管理難度增大,服務之間常常是A依賴B,B依賴C,而後C又依賴其餘,對於已經約定好的報文協議很難作修改(對擴展開放,對修改關閉),同時因爲服務數量的增長和服務自己的無狀態帶來了服務的監控與治理變得更加複雜要依賴強大的服務治理框架。

  管理難度增大:開發和測試時只能經過模擬報文或者直連的方式調用服務提供方的接口,增長了團隊溝通成本和協調管理的難度。

7. 總結

  微服務架構只是金字塔尖的那一朵小紅花,須要下面一層層的Pass綠葉來襯托。實施微服務須要基礎設施的自動化(包括自動化構建、測試、部署和監控等),同時也要求開發團隊組織架構的調整來適應新的開發模式(微服務很適合敏捷開發,能夠實現快速構建快速交付,迭代發佈)。

  幸運的是目前Java平臺已經有不少不少成熟的PaaS中間件來解決企業應用在微服務化重構時遇到的挑戰。

  軟件架構總在不斷演進,微服務以後會是Service Mesh麼?

相關文章
相關標籤/搜索