微服務淺談&服務治理的演變過程

本篇文章先簡單介紹了網際網路架構的演變，進而介紹了服務化，最後介紹了微服務及最新的服務網格（Service Mesh）。

這兩天對網際網路的架構演變進行了簡單了解，并對微服務的出現很感興趣，是以對相關知識進行了簡單的整理與總結。

---------------------

網際網路架構演變

一體架構

在計算機軟體發展早期，一般桌面軟體都是采用這種架構，不管是界面還是業務處理還是資料處理都放到一個包中。這種其實談不上架構，但也可以說是很好的架構，因為它足夠簡單。

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
服務：提供好服務，要讓使用者感到好用(要做到這一點很不容易)

微服務（Microservices）是一種架構風格，一個大型複雜軟體應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注于完成一件任務并很好地完成該任務。在所有情況下，每個任務代表着一個小的業務能力。

微服務架構 ≈ 子產品化開發 + 分布式計算

從上面這幅圖看出，微服務特别簡單（好的架構就應該簡單），我們把服務再拆分成一個個API，API是一個完整的功能。然後我們把API扔到一個“雲上”，然後使用者就可以到“雲上”擷取所有API的服務，這個“雲”保證能提供好的服務。

我們可以看到，有了微服務之後，服務對使用者來說變得特别簡單，而且上面dubbo的不足之處在微服務這裡都解決了。使用者不再需要依賴任何jar包，不再需要去注冊中心查找服務，不再去做鑒權處理，不用擔心服務挂掉，不用擔心不會使用服務，所有的問題這個“雲”都解決了。這也是微服務的核心之一，提供好服務。

說到這裡，大家就應該大體知道該怎麼做微服務了，圖中的“雲”是關鍵。下面我們就慢慢撥開這朵雲。

微服務的實作

微服務的關鍵是服務網關，是以，上面提到的“雲”就是服務網關。要做微服務，我們先定義一下微服務需要具備的特點。

常見的微服務元件及概念：

服務注冊：服務提供方将自己調用位址注冊到服務注冊中心，讓服務調用方能夠友善地找到自己。
服務發現：服務調用方從服務注冊中心找到自己需要調用的服務的位址。
負載均衡：服務提供方一般以多執行個體的形式提供服務，負載均衡功能能夠讓服務調用方連接配接到合适的服務節點。并且，節點選擇的工作對服務調用方來說是透明的。
服務網關：服務網關是服務調用的唯一入口，可以在這個元件是實作使用者鑒權、動态路由、灰階釋出、A/B 測試、負載限流等功能。
配置中心：将本地化的配置資訊（properties, xml, yaml 等）注冊到配置中心，實作程式包在開發、測試、生産環境的無差别性，友善程式包的遷移。
API 管理：以友善的形式編寫及更新 API 文檔，并以友善的形式供調用者檢視和測試。
內建架構：微服務元件都以職責單一的程式包對外提供服務，內建架構以配置的形式将所有微服務元件（特别是管理端元件）內建到統一的界面架構下，讓使用者能夠在統一的界面中使用系統。
分布式事務：對于重要的業務，需要通過分布式事務技術（TCC、高可用消息服務、最大努力通知）保證資料的一緻性。
調用鍊：記錄完成一個業務邏輯時調用到的微服務，并将這種串行或并行的調用關系展示出來。在系統出錯時，可以友善地找到出錯點。
支撐平台：系統微服務化後，系統變得更加碎片化，系統的部署、運維、監控等都比單體架構更加複雜，那麼，就需要将大部分的工作自動化。現在，可以通過 Docker 等工具來中和這些微服務架構帶來的弊端。例如持續內建、藍綠釋出、健康檢查、性能健康等等。嚴重點，以我們兩年的實踐經驗，可以這麼說，如果沒有合适的支撐平台或工具，就不要使用微服務架構。

微服務架構的優點：

降低系統複雜度：每個服務都比較簡單，隻關注于一個業務功能。
松耦合：微服務架構方式是松耦合的，每個微服務可由不同團隊獨立開發，互不影響。
跨語言：隻要符合服務 API 契約，開發人員可以自由選擇開發技術。這就意味着開發人員可以采用新技術編寫或重構服務，由于服務相對較小，是以這并不會對整體應用造成太大影響。
獨立部署：微服務架構可以使每個微服務獨立部署。開發人員無需協調對服務更新或更改的部署。這些更改可以在測試通過後立即部署。是以微服務架構也使得 CI／CD 成為可能。
Docker 容器：和 Docker 容器結合的更好。
DDD 領域驅動設計：和 DDD 的概念契合，結合開發會更好。

微服務架構的缺點：

微服務強調了服務大小，但實際上這并沒有一個統一的标準：業務邏輯應該按照什麼規則劃分為微服務，這本身就是一個經驗工程。有些開發者主張 10-100 行代碼就應該建立一個微服務。雖然建立小型服務是微服務架構崇尚的，但要記住，微服務是達到目的的手段，而不是目标。微服務的目标是充分分解應用程式，以促進靈活開發和持續內建部署。
微服務的分布式特點帶來的複雜性：開發人員需要基于 RPC 或者消息實作微服務之間的調用和通信，而這就使得服務之間的發現、服務調用鍊的跟蹤和品質問題變得的相當棘手。
分區的資料庫體系和分布式事務：更新多個業務實體的業務交易相當普遍，不同服務可能擁有不同的資料庫。CAP 原理的限制，使得我們不得不放棄傳統的強一緻性，而轉而追求最終一緻性，這個對開發人員來說是一個挑戰。
測試挑戰：傳統的單體WEB應用隻需測試單一的 REST API 即可，而對微服務進行測試，需要啟動它依賴的所有其他服務。這種複雜性不可低估。
跨多個服務的更改：比如在傳統單體應用中，若有 A、B、C 三個服務需要更改，A 依賴 B，B 依賴 C。我們隻需更改相應的子產品，然後一次性部署即可。但是在微服務架構中，我們需要仔細規劃和協調每個服務的變更部署。我們需要先更新 C，然後更新 B，最後更新 A。
部署複雜：微服務由不同的大量服務構成。每種服務可能擁有自己的配置、應用執行個體數量以及基礎服務位址。這裡就需要不同的配置、部署、擴充和監控元件。此外，我們還需要服務發現機制，以便服務可以發現與其通信的其他服務的位址。是以，成功部署微服務應用需要開發人員有更好地部署政策和高度自動化的水準。
總的來說（問題和挑戰）：API Gateway、服務間調用、服務發現、服務容錯、服務部署、資料調用。

微服務要解決的問題

上面提到了，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不能挂掉并且有好的性能，需要很高的運維要求。這裡的彈性雲便是自動化運維解決方案，對通路壓力進行監控，根據監控解決排程應用的釋出和回收。

服務網格（Service Mesh）

2017 年底，非侵入式的 Service Mesh 技術從萌芽到走向了成熟。

Service Mesh 又譯作“服務網格”，作為服務間通信的基礎設施層。

如果用一句話來解釋什麼是 Service Mesh，可以将它比作是應用程式或者說微服務間的 TCP/IP，負責服務之間的網絡調用、限流、熔斷和監控。對于編寫應用程式來說一般無須關心 TCP/IP 這一層（比如通過 HTTP 協定的 RESTful 應用），同樣使用 Service Mesh 也就無須關系服務之間的那些原來是通過應用程式或者其他架構實作的事情，比如 Spring Cloud、OSS，現在隻要交給 Service Mesh 就可以了。

Service Mesh 的來龍去脈：

從最原始的主機之間直接使用網線相連
網絡層的出現
內建到應用程式内部的控制流
分解到應用程式外部的控制流
應用程式的中內建服務發現和斷路器
出現了專門用于服務發現和斷路器的軟體包/庫，如 Twitter 的 Finagle 和 Facebook 的 Proxygen，這時候還是內建在應用程式内部
出現了專門用于服務發現和斷路器的開源軟體，如 Netflix OSS、Airbnb 的 synapse 和 nerve
最後作為微服務的中間層 Service Mesh 出現

Service Mesh 有如下幾個特點：

應用程式間通訊的中間層
輕量級網絡代理
應用程式無感覺
解耦應用程式的重試/逾時、監控、追蹤和服務發現

Service Mesh 架構圖：

關于微服務和服務網格的差別，我的一些了解：微服務更像是一個服務之間的生态，專注于服務治理等方面，而服務網格更專注于服務之間的通信，以及和 DevOps 更好的結合。