技術干貨分享：微服務淺談服務治理的演變過程

作者：IT技術分享 2019-08-16 08:59:33

開發后端

本篇文章先簡單介紹了互聯網架構的演變，進而介紹了服務化，最后介紹了微服務及最新的服務網格(Service Mesh)。

[[273901]]

互聯網架構演變

一體架構

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

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 更好的結合。

責任編輯：華軒來源：今日頭條

技術軟件 HTML