淺談服務治理與微服務

互聯網架構演變

一體架構

在計算機軟件發展早期，通常桌面軟件都是採用這種架構，不論是界面仍是業務處理仍是數據處理都放到一個包中。這種其實談不上架構，但也能夠說是很好的架構，由於它足夠簡單。

mvc架構

但隨着瀏覽器的出現便產生了web應用，web應用的特色是界面部分是顯示在瀏覽器中，服務處理是在服務容器中的，頁面顯示通常用css+js+html技術來處理，然後端能夠用java、php等語言，這就產生了先後端分離。對於web系統，一體架構難以知足先後端分離的開發需求，於是便產生了MVC架構。

MVC纔算的上真正意義上的架構，由於它除了解決了先後端分離問題，還引入了一種全新的開發模式，用一種業務邏輯、數據、界面顯示分離的方法組織代碼，使得整個應用層次更加分明，並且各個層次之間不但減低了耦合性，還提升了各個層次的可重用性。

但隨着應用規模的不斷擴大，應用模塊不斷增長，整個應用也顯得愈來愈臃腫，維護起來也更加困難，所以便又產生了多應用架構。

多應用架構

多應用架構很簡單，就是把原來的應用按照業務特色拆分紅多個應用。好比一個大型電商系統可能包含用戶系統、商品系統、訂單系統、評價系統等等，咱們能夠把他們獨立出來造成一個個單獨的應用。多應用架構的特色是應用之間各自獨立 ，不相互調用。

多應用雖然解決了應用臃腫問題，但應用之間相互獨立，有些共同的業務或代碼沒法複用。

分佈式架構

對於一個大型的互聯網系統，通常會包含多個應用，並且應用之間每每還存在共同的業務，而且應用之間還存在調用關係。除此以外 ，對於大型的互聯網系統還有一些其它的挑戰，好比如何應對急劇增加的用戶，如何管理好研發團隊快速迭代產品研發，如何保持產品升級更加穩定等等 。

所以，爲了使業務獲得很好的複用，模塊更加容易拓展和維護，咱們但願業務與應用分離，某個業務再也不屬於一個應用，而是做爲一個獨立的服務單獨進行維護。應用自己再也不是一個臃腫的模塊堆積，而是由一個個模塊化的服務組件組合而成。

服務化

服務化的特色

上面介紹的分佈式架構即服務化。咱們再總結一下，服務化主要有以下特色：

• 應用按業務拆分紅服務
• 各個服務都可獨立部署
• 服務可被多個應用共享
• 服務之間能夠通訊

服務化的好處

那麼企業採用服務化有哪些好處呢？

• 架構上系統更加清晰
• 核心模塊穩定，以服務組件爲單位進行升級，避免了頻繁發佈帶來的風險
• 開發管理方便
• 單獨團隊維護、工做分明，職責清晰
• 業務複用、代碼複用
• 很是容易拓展

服務化實現方式

若是要實現服務化的話，最經常使用的方式就是利用RPC框架。由於服務組件通常分佈在不一樣的服務器上，因此要實現服務化須要解決的第一個問題就是RPC**遠程服務調用**。相似於RPC方案有不少，好比：

• Java RMI
• WebService
• Hessian
• Http
• Thrift
• … …

服務化面臨的挑戰

上面提到要實現服務化首先須要解決遠程服務調用問題，除此以外，還有不少其餘問題須要解決。

• 服務愈來愈多，配置管理複雜
• 服務間依賴關係複雜
• 服務之間的負載均衡
• 服務的拓展
• 服務監控
• 服務降級
• 服務鑑權
• 服務上線與下線
• 服務文檔
• … …

服務治理

上面提到了服務化，其實要想服務化，服務治理是關鍵。那麼有沒有好的服務治理方案呢？答案是有的，並且不少人都在用這個框架，他就是-dubbo。dubbo就是一個帶有服務治理功能的RPC框架。

dubbo提供了一套較爲完整的服務治理方案，因此企業若是要實現服務化的話，dubbo 是很好的一個選擇。這裏簡單介紹一下dubbo服務治理相關方案。

服務發現註冊

服務治理領域最重要的問題就是服務發現與註冊。dubbo中引入了一個註冊中心的概念，服務的註冊與發現主要就依賴這個服務中心。

dubbo註冊中心服務註冊發現的具體過程：

• 服務提供者啓動，向註冊中心註冊本身提供的服務
• 消費者啓動，向註冊中心訂閱本身須要的服務
• 註冊中心返回服務提供者的列表給消費者
• 消費者從服務提供者列表中，按照軟負載均衡算法，選擇一臺發起請求

服務監控

集羣容錯

負載均衡

• Random Loadbalance
• RoundRobin
• LeastActive
• ConsistentHash

dubbo服務治理優點

• 註冊中心只負責註冊查找，不負責請求轉發，壓力小
• 註冊中心宕機影響消費者，消費者本地緩存服務地址列表
• 註冊中心對等集羣，宕掉一臺自動切換到另外 一臺
• 服務提供者無狀態，可動態部署，註冊中心負責推送
• 統計無壓力，本地內存中累計次數，每分鐘發送註冊中心
• 消費者調用服務者，自動軟負載均衡
• 經過服務中心可追蹤依賴關係
• 監控中心爲擴容和降級提供依據
• 可啓用acl機制進行鑑權
• 與Spring整合，接入簡單鬆耦合
• 多種序列化協議支持

dubbo的不足

• 消費者仍須要依賴配置中心
• 消費者仍須要依賴jar包配置provider
• 提供者文檔管理功能缺失
• 無統一入口
• 不支持OAuth2.0
• 內部鑑權不方便管理
• 無外部應用鑑權
• 接口基本裸奔，沒法直接對外暴露服務
• IT治理不方便

微服務

如今不少人都在談微服務，那麼到底什麼是微服務呢？這裏談談我對微服務的理解。

微服務有兩個核心：

• 微：服務的粒度要細，即服務要細化到API
• 服務：提供好服務，要讓用戶感到好用(要作到這一點很不容易)

上面兩個核心總結起來，能夠用下面這幅圖表示：

從上面這幅圖看出，微服務特別簡單（好的架構就應該簡單），咱們把服務再拆分紅一個個API，API是一個完整的功能。而後咱們把API扔到一個「雲上」，而後用戶就能夠到「雲上」獲取全部API的服務，這個「雲」保證能提供好的服務。

咱們能夠看到，有了微服務以後，服務對用戶來講變得特別簡單，並且上面dubbo的不足之處在微服務這裏都解決了。使用者再也不須要依賴任何jar包，再也不須要去註冊中心查找服務，再也不去作鑑權處理，不用擔憂服務掛掉，不用擔憂不會使用服務，全部的問題這個「雲」都解決了。這也是微服務的核心之一，提供好服務。

說到這裏，你們就應該大致知道該怎麼作微服務了，圖中的「雲」是關鍵。下面咱們就慢慢撥開這朵雲。

微服務的實現

微服務的關鍵是服務網關，因此，上面提到的「雲」就是服務網關。要作微服務，咱們先定義一下微服務須要具有的特色。

微服務的特色

服務須要再細化成API（服務接口——>服務API）

• 每一個服務由一組API組成
• 以API形式對外提供統一格式的服務
• 使用者無需任何配置，直接調用（http）
• 完整的API文檔
• API服務安全可靠穩定

微服務要解決的問題

上面提到了，dubbo還存在一些問題 ，其實dubbo存在的問題 就是 微服務要解決的問題，這裏 再總結一下。固然，dubbo和微服務的側重點不同，dubbo側重於內部接口之間的RPC，而微服務則側重於對外提供服務。

• 統一入口
• 安全控制：防刷限流
• 統一鑑權：應用鑑權、用戶鑑權、OAuth鑑權、ACL
• 協議轉換：http、dubbo、Protobuf
• API配置管理
• API上線、下線
• API與服務接口映射
• 監控與報警
• 總體架構的可拓展、高併發、分佈式
• 服務容器自動收縮、擴容

實現方案

• 負載均衡層：nginx/lvs/F5
• 微服務層 
  
  • 高性能服務網關
  • 統一入口、API配置管理、分流鑑權、服務監控、協議轉換
  • API映射、OAuth2.0、API文檔管理
  • 分佈式、可拓展
• 服務治理層 
  
  • 成熟的服務治理框架dubbo
  • MQ服務之間解耦
• 彈性雲 
  
  • 服務docker化
  • 基於訪問壓力的實時集羣調度與管理

彈性雲

這裏簡單介紹一下彈性雲的概念，微服務要想提供好服務，保證API不能掛掉而且有好的性能，須要很高的運維要求。這裏的彈性雲即是自動化運維解決方案，對訪問壓力進行監控，根據監控解決調度應用的發佈和回收。

ps：Heaven-Wang