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

時間 2019-11-07

標籤微服淺談服務治理演變過程简体版

原文原文鏈接

這兩天對互聯網的架構演變進行了簡單瞭解，並對微服務的出現很感興趣，因此對相關知識進行了簡單的整理與總結。php

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

互聯網架構演變

一體架構

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

mvc架構

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

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

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

多應用架構

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

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

分佈式架構

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

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

服務化

服務化的特色

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

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

服務化的好處

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

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

服務化實現方式

若是要實現服務化的話，最經常使用的方式就是利用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 的前因後果：