本篇文章先簡單介紹了互聯(lián)網(wǎng)架構(gòu)的演變，進而介紹了服務(wù)化，最后介紹了微服務(wù)及最新的服務(wù)網(wǎng)格(Service Mesh)。

[[273901]]

 

互聯(lián)網(wǎng)架構(gòu)演變

一體架構(gòu)

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

 

 

mvc架構(gòu)

但隨著瀏覽器的出現(xiàn)便產(chǎn)生了web應(yīng)用，web應(yīng)用的特點是界面部分是顯示在瀏覽器中，服務(wù)處理是在服務(wù)容器中的，頁面顯示一般用css+js+html技術(shù)來處理，而后端可以用java、php等語言，這就產(chǎn)生了前后端分離。對于web系統(tǒng)，一體架構(gòu)難以滿足前后端分離的開發(fā)需求，因而便產(chǎn)生了MVC架構(gòu)。

 

 

MVC才算的上真正意義上的架構(gòu)，因為它除了解決了前后端分離問題，還引入了一種全新的開發(fā)模式，用一種業(yè)務(wù)邏輯、數(shù)據(jù)、界面顯示分離的方法組織代碼，使得整個應(yīng)用層次更加分明，而且各個層次之間不但減低了耦合性，還提高了各個層次的可重用性。

但隨著應(yīng)用規(guī)模的不斷擴大，應(yīng)用模塊不斷增加，整個應(yīng)用也顯得越來越臃腫，維護起來也更加困難，因此便又產(chǎn)生了多應(yīng)用架構(gòu)。

 

[[273904]]

 

多應(yīng)用架構(gòu)

多應(yīng)用架構(gòu)很簡單，就是把原來的應(yīng)用按照業(yè)務(wù)特點拆分成多個應(yīng)用。比如一個大型電商系統(tǒng)可能包含用戶系統(tǒng)、商品系統(tǒng)、訂單系統(tǒng)、評價系統(tǒng)等等，我們可以把他們獨立出來形成一個個單獨的應(yīng)用。多應(yīng)用架構(gòu)的特點是應(yīng)用之間各自獨立 ，不相互調(diào)用。

 

 

多應(yīng)用雖然解決了應(yīng)用臃腫問題，但應(yīng)用之間相互獨立，有些共同的業(yè)務(wù)或代碼無法復(fù)用。

分布式架構(gòu)

對于一個大型的互聯(lián)網(wǎng)系統(tǒng)，一般會包含多個應(yīng)用，而且應(yīng)用之間往往還存在共同的業(yè)務(wù)，并且應(yīng)用之間還存在調(diào)用關(guān)系。除此之外 ，對于大型的互聯(lián)網(wǎng)系統(tǒng)還有一些其它的挑戰(zhàn)，比如如何應(yīng)對急劇增長的用戶，如何管理好研發(fā)團隊快速迭代產(chǎn)品研發(fā)，如何保持產(chǎn)品升級更加穩(wěn)定等等 。

 

 

因此，為了使業(yè)務(wù)得到很好的復(fù)用，模塊更加容易拓展和維護，我們希望業(yè)務(wù)與應(yīng)用分離，某個業(yè)務(wù)不再屬于一個應(yīng)用，而是作為一個獨立的服務(wù)單獨進行維護。應(yīng)用本身不再是一個臃腫的模塊堆積，而是由一個個模塊化的服務(wù)組件組合而成。

服務(wù)化

服務(wù)化的特點

上面介紹的分布式架構(gòu)即服務(wù)化。我們再總結(jié)一下，服務(wù)化主要有如下特點：

• 應(yīng)用按業(yè)務(wù)拆分成服務(wù)
• 各個服務(wù)均可獨立部署
• 服務(wù)可被多個應(yīng)用共享
• 服務(wù)之間可以通信

服務(wù)化的好處

那么企業(yè)采用服務(wù)化有哪些好處呢?

• 架構(gòu)上系統(tǒng)更加清晰
• 核心模塊穩(wěn)定，以服務(wù)組件為單位進行升級，避免了頻繁發(fā)布帶來的風(fēng)險
• 開發(fā)管理方便
• 單獨團隊維護、工作分明，職責(zé)清晰
• 業(yè)務(wù)復(fù)用、代碼復(fù)用
• 非常容易拓展

服務(wù)化實現(xiàn)方式

如果要實現(xiàn)服務(wù)化的話，最常用的方式就是利用RPC框架。因為服務(wù)組件一般分布在不同的服務(wù)器上，所以要實現(xiàn)服務(wù)化需要解決的第一個問題就是RPC**遠(yuǎn)程服務(wù)調(diào)用**。類似于RPC方案有很多，比如：

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

服務(wù)化面臨的挑戰(zhàn)

上面提到要實現(xiàn)服務(wù)化首先需要解決遠(yuǎn)程服務(wù)調(diào)用問題，除此之外，還有很多其他問題需要解決。

• 服務(wù)越來越多，配置管理復(fù)雜
• 服務(wù)間依賴關(guān)系復(fù)雜
• 服務(wù)之間的負(fù)載均衡
• 服務(wù)的拓展
• 服務(wù)監(jiān)控
• 服務(wù)降級
• 服務(wù)鑒權(quán)
• 服務(wù)上線與下線
• 服務(wù)文檔
• … …

服務(wù)治理

上面提到了服務(wù)化，其實要想服務(wù)化，服務(wù)治理是關(guān)鍵。那么有沒有好的服務(wù)治理方案呢?答案是有的，而且很多人都在用這個框架，他就是-dubbo。dubbo就是一個帶有服務(wù)治理功能的RPC框架。

 

 

dubbo提供了一套較為完整的服務(wù)治理方案，所以企業(yè)如果要實現(xiàn)服務(wù)化的話，dubbo 是很好的一個選擇。這里簡單介紹一下dubbo服務(wù)治理相關(guān)方案。

服務(wù)發(fā)現(xiàn)注冊

服務(wù)治理領(lǐng)域最重要的問題就是服務(wù)發(fā)現(xiàn)與注冊。dubbo中引入了一個注冊中心的概念，服務(wù)的注冊與發(fā)現(xiàn)主要就依賴這個服務(wù)中心。

 

 

dubbo注冊中心服務(wù)注冊發(fā)現(xiàn)的具體過程：

服務(wù)提供者啟動，向注冊中心注冊自己提供的服務(wù)

消費者啟動，向注冊中心訂閱自己需要的服務(wù)

注冊中心返回服務(wù)提供者的列表給消費者

消費者從服務(wù)提供者列表中，按照軟負(fù)載均衡算法，選擇一臺發(fā)起請求

服務(wù)監(jiān)控

 

 

集群容錯

 

 

負(fù)載均衡

• Random Loadbalance
• RoundRobin
• LeastActive
• ConsistentHash

dubbo服務(wù)治理優(yōu)勢

• 注冊中心只負(fù)責(zé)注冊查找，不負(fù)責(zé)請求轉(zhuǎn)發(fā)，壓力小
• 注冊中心宕機影響消費者，消費者本地緩存服務(wù)地址列表
• 注冊中心對等集群，宕掉一臺自動切換到另外 一臺
• 服務(wù)提供者無狀態(tài)，可動態(tài)部署，注冊中心負(fù)責(zé)推送
• 統(tǒng)計無壓力，本地內(nèi)存中累計次數(shù)，每分鐘發(fā)送注冊中心
• 消費者調(diào)用服務(wù)者，自動軟負(fù)載均衡
• 通過服務(wù)中心可追蹤依賴關(guān)系
• 監(jiān)控中心為擴容和降級提供依據(jù)
• 可啟用acl機制進行鑒權(quán)
• 與Spring整合，接入簡單松耦合
• 多種序列化協(xié)議支持

dubbo的不足

• 消費者仍需要依賴配置中心
• 消費者仍需要依賴jar包配置provider
• 提供者文檔管理功能缺失
• 無統(tǒng)一入口
• 不支持OAuth2.0
• 內(nèi)部鑒權(quán)不方便管理
• 無外部應(yīng)用鑒權(quán)
• 接口基本裸奔，無法直接對外暴露服務(wù)
• IT治理不方便

微服務(wù)

現(xiàn)在很多人都在談微服務(wù)，那么到底什么是微服務(wù)呢?這里談?wù)勎覍ξ⒎?wù)的理解。

微服務(wù)有兩個核心：

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

微服務(wù)(Microservices)是一種架構(gòu)風(fēng)格，一個大型復(fù)雜軟件應(yīng)用由一個或多個微服務(wù)組成。系統(tǒng)中的各個微服務(wù)可被獨立部署，各個微服務(wù)之間是松耦合的。每個微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)。在所有情況下，每個任務(wù)代表著一個小的業(yè)務(wù)能力。

微服務(wù)架構(gòu) ≈ 模塊化開發(fā) + 分布式計算

 

 

從上面這幅圖看出，微服務(wù)特別簡單(好的架構(gòu)就應(yīng)該簡單)，我們把服務(wù)再拆分成一個個API，API是一個完整的功能。然后我們把API扔到一個“云上”，然后用戶就可以到“云上”獲取所有API的服務(wù)，這個“云”保證能提供好的服務(wù)。

我們可以看到，有了微服務(wù)之后，服務(wù)對用戶來說變得特別簡單，而且上面dubbo的不足之處在微服務(wù)這里都解決了。使用者不再需要依賴任何jar包，不再需要去注冊中心查找服務(wù)，不再去做鑒權(quán)處理，不用擔(dān)心服務(wù)掛掉，不用擔(dān)心不會使用服務(wù)，所有的問題這個“云”都解決了。這也是微服務(wù)的核心之一，提供好服務(wù)。

說到這里，大家就應(yīng)該大體知道該怎么做微服務(wù)了，圖中的“云”是關(guān)鍵。下面我們就慢慢撥開這朵云。

微服務(wù)的實現(xiàn)

 

 

微服務(wù)的關(guān)鍵是服務(wù)網(wǎng)關(guān)，所以，上面提到的“云”就是服務(wù)網(wǎng)關(guān)。要做微服務(wù)，我們先定義一下微服務(wù)需要具備的特點。

常見的微服務(wù)組件及概念：

• 服務(wù)注冊 ：服務(wù)提供方將自己調(diào)用地址注冊到服務(wù)注冊中心，讓服務(wù)調(diào)用方能夠方便地找到自己。
• 服務(wù)發(fā)現(xiàn) ：服務(wù)調(diào)用方從服務(wù)注冊中心找到自己需要調(diào)用的服務(wù)的地址。
• 負(fù)載均衡 ：服務(wù)提供方一般以多實例的形式提供服務(wù)，負(fù)載均衡功能能夠讓服務(wù)調(diào)用方連接到合適的服務(wù)節(jié)點。并且，節(jié)點選擇的工作對服務(wù)調(diào)用方來說是透明的。
• 服務(wù)網(wǎng)關(guān) ：服務(wù)網(wǎng)關(guān)是服務(wù)調(diào)用的唯一入口，可以在這個組件是實現(xiàn)用戶鑒權(quán)、動態(tài)路由、灰度發(fā)布、A/B 測試、負(fù)載限流等功能。
• 配置中心 ：將本地化的配置信息(properties, xml, yaml 等)注冊到配置中心，實現(xiàn)程序包在開發(fā)、測試、生產(chǎn)環(huán)境的無差別性，方便程序包的遷移。
• API 管理 ：以方便的形式編寫及更新 API 文檔，并以方便的形式供調(diào)用者查看和測試。
• 集成框架 ：微服務(wù)組件都以職責(zé)單一的程序包對外提供服務(wù)，集成框架以配置的形式將所有微服務(wù)組件(特別是管理端組件)集成到統(tǒng)一的界面框架下，讓用戶能夠在統(tǒng)一的界面中使用系統(tǒng)。
• 分布式事務(wù) ：對于重要的業(yè)務(wù)，需要通過分布式事務(wù)技術(shù)(TCC、高可用消息服務(wù)、最大努力通知)保證數(shù)據(jù)的一致性。
• 調(diào)用鏈 ：記錄完成一個業(yè)務(wù)邏輯時調(diào)用到的微服務(wù)，并將這種串行或并行的調(diào)用關(guān)系展示出來。在系統(tǒng)出錯時，可以方便地找到出錯點。
• 支撐平臺 ：系統(tǒng)微服務(wù)化后，系統(tǒng)變得更加碎片化，系統(tǒng)的部署、運維、監(jiān)控等都比單體架構(gòu)更加復(fù)雜，那么，就需要將大部分的工作自動化?，F(xiàn)在，可以通過 Docker 等工具來中和這些微服務(wù)架構(gòu)帶來的弊端。 例如持續(xù)集成、藍(lán)綠發(fā)布、健康檢查、性能健康等等。嚴(yán)重點，以我們兩年的實踐經(jīng)驗，可以這么說，如果沒有合適的支撐平臺或工具，就不要使用微服務(wù)架構(gòu)。

 

微服務(wù)架構(gòu)的優(yōu)點：

• 降低系統(tǒng)復(fù)雜度 ：每個服務(wù)都比較簡單，只關(guān)注于一個業(yè)務(wù)功能。
• 松耦合 ：微服務(wù)架構(gòu)方式是松耦合的，每個微服務(wù)可由不同團隊獨立開發(fā)，互不影響。
• 跨語言 ：只要符合服務(wù) API 契約，開發(fā)人員可以自由選擇開發(fā)技術(shù)。這就意味著開發(fā)人員可以采用新技術(shù)編寫或重構(gòu)服務(wù)，由于服務(wù)相對較小，所以這并不會對整體應(yīng)用造成太大影響。
• 獨立部署 ：微服務(wù)架構(gòu)可以使每個微服務(wù)獨立部署。開發(fā)人員無需協(xié)調(diào)對服務(wù)升級或更改的部署。這些更改可以在測試通過后立即部署。所以微服務(wù)架構(gòu)也使得 CI/CD 成為可能。
• Docker 容器 ：和 Docker 容器結(jié)合的更好。
• DDD 領(lǐng)域驅(qū)動設(shè)計 ：和 DDD 的概念契合，結(jié)合開發(fā)會更好。

微服務(wù)架構(gòu)的缺點：

• 微服務(wù)強調(diào)了服務(wù)大小，但實際上這并沒有一個統(tǒng)一的標(biāo)準(zhǔn) ：業(yè)務(wù)邏輯應(yīng)該按照什么規(guī)則劃分為微服務(wù)，這本身就是一個經(jīng)驗工程。有些開發(fā)者主張 10-100 行代碼就應(yīng)該建立一個微服務(wù)。雖然建立小型服務(wù)是微服務(wù)架構(gòu)崇尚的，但要記住，微服務(wù)是達(dá)到目的的手段，而不是目標(biāo)。微服務(wù)的目標(biāo)是充分分解應(yīng)用程序，以促進敏捷開發(fā)和持續(xù)集成部署。
• 微服務(wù)的分布式特點帶來的復(fù)雜性 ：開發(fā)人員需要基于 RPC 或者消息實現(xiàn)微服務(wù)之間的調(diào)用和通信，而這就使得服務(wù)之間的發(fā)現(xiàn)、服務(wù)調(diào)用鏈的跟蹤和質(zhì)量問題變得的相當(dāng)棘手。
• 分區(qū)的數(shù)據(jù)庫體系和分布式事務(wù) ：更新多個業(yè)務(wù)實體的業(yè)務(wù)交易相當(dāng)普遍，不同服務(wù)可能擁有不同的數(shù)據(jù)庫。CAP 原理的約束，使得我們不得不放棄傳統(tǒng)的強一致性，而轉(zhuǎn)而追求最終一致性，這個對開發(fā)人員來說是一個挑戰(zhàn)。
• 測試挑戰(zhàn) ：傳統(tǒng)的單體WEB應(yīng)用只需測試單一的 REST API 即可，而對微服務(wù)進行測試，需要啟動它依賴的所有其他服務(wù)。這種復(fù)雜性不可低估。
• 跨多個服務(wù)的更改 ：比如在傳統(tǒng)單體應(yīng)用中，若有 A、B、C 三個服務(wù)需要更改，A 依賴 B，B 依賴 C。我們只需更改相應(yīng)的模塊，然后一次性部署即可。但是在微服務(wù)架構(gòu)中，我們需要仔細(xì)規(guī)劃和協(xié)調(diào)每個服務(wù)的變更部署。我們需要先更新 C，然后更新 B，最后更新 A。
• 部署復(fù)雜 ：微服務(wù)由不同的大量服務(wù)構(gòu)成。每種服務(wù)可能擁有自己的配置、應(yīng)用實例數(shù)量以及基礎(chǔ)服務(wù)地址。這里就需要不同的配置、部署、擴展和監(jiān)控組件。此外，我們還需要服務(wù)發(fā)現(xiàn)機制，以便服務(wù)可以發(fā)現(xiàn)與其通信的其他服務(wù)的地址。因此，成功部署微服務(wù)應(yīng)用需要開發(fā)人員有更好地部署策略和高度自動化的水平。
• 總的來說(問題和挑戰(zhàn)) ：API Gateway、服務(wù)間調(diào)用、服務(wù)發(fā)現(xiàn)、服務(wù)容錯、服務(wù)部署、數(shù)據(jù)調(diào)用。

微服務(wù)要解決的問題

上面提到了，dubbo還存在一些問題 ，其實dubbo存在的問題 就是 微服務(wù)要解決的問題，這里 再總結(jié)一下。當(dāng)然，dubbo和微服務(wù)的側(cè)重點不一樣，dubbo側(cè)重于內(nèi)部接口之間的RPC，而微服務(wù)則側(cè)重于對外提供服務(wù)。

• 統(tǒng)一入口
• 安全控制：防刷限流
• 統(tǒng)一鑒權(quán)：應(yīng)用鑒權(quán)、用戶鑒權(quán)、OAuth鑒權(quán)、ACL
• 協(xié)議轉(zhuǎn)換：http、dubbo、Protobuf
• API配置管理
• API上線、下線
• API與服務(wù)接口映射
• 監(jiān)控與報警
• 整體架構(gòu)的可拓展、高并發(fā)、分布式
• 服務(wù)容器自動收縮、擴容

實現(xiàn)方案

 

 

• 負(fù)載均衡層：nginx/lvs/F5
• 微服務(wù)層

高性能服務(wù)網(wǎng)關(guān);

統(tǒng)一入口、API配置管理、分流鑒權(quán)、服務(wù)監(jiān)控、協(xié)議轉(zhuǎn)換;

API映射、OAuth2.0、API文檔管理;

分布式、可拓展;

• 服務(wù)治理層

成熟的服務(wù)治理框架dubbo;

MQ服務(wù)之間解耦;

• 彈性云

服務(wù)docker化;

基于訪問壓力的實時集群調(diào)度與管理;

彈性云

這里簡單介紹一下彈性云的概念，微服務(wù)要想提供好服務(wù)，保證API不能掛掉并且有好的性能，需要很高的運維要求。這里的彈性云便是自動化運維解決方案，對訪問壓力進行監(jiān)控，根據(jù)監(jiān)控解決調(diào)度應(yīng)用的發(fā)布和回收。

 

 

服務(wù)網(wǎng)格(Service Mesh)

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

Service Mesh 又譯作“服務(wù)網(wǎng)格”，作為 服務(wù)間通信的基礎(chǔ)設(shè)施層 。

如果用一句話來解釋什么是 Service Mesh，可以將它比作是 應(yīng)用程序或者說微服務(wù)間的 TCP/IP，負(fù)責(zé)服務(wù)之間的網(wǎng)絡(luò)調(diào)用、限流、熔斷和監(jiān)控 。對于編寫應(yīng)用程序來說一般無須關(guān)心 TCP/IP 這一層(比如通過 HTTP 協(xié)議的 RESTful 應(yīng)用)，同樣使用 Service Mesh 也就無須關(guān)系服務(wù)之間的那些原來是通過應(yīng)用程序或者其他框架實現(xiàn)的事情，比如 Spring Cloud、OSS，現(xiàn)在只要交給 Service Mesh 就可以了。

Service Mesh 的來龍去脈：

1. 從最原始的主機之間直接使用網(wǎng)線相連
2. 網(wǎng)絡(luò)層的出現(xiàn)
3. 集成到應(yīng)用程序內(nèi)部的控制流
4. 分解到應(yīng)用程序外部的控制流
5. 應(yīng)用程序的中集成服務(wù)發(fā)現(xiàn)和斷路器
6. 出現(xiàn)了專門用于服務(wù)發(fā)現(xiàn)和斷路器的軟件包/庫，如 Twitter 的 Finagle 和 Facebook 的 Proxygen，這時候還是集成在應(yīng)用程序內(nèi)部
7. 出現(xiàn)了專門用于服務(wù)發(fā)現(xiàn)和斷路器的開源軟件，如 Netflix OSS、Airbnb 的 synapse 和 nerve
8. 最后作為微服務(wù)的中間層 Service Mesh 出現(xiàn)

Service Mesh 有如下幾個特點：

• 應(yīng)用程序間通訊的中間層
• 輕量級網(wǎng)絡(luò)代理
• 應(yīng)用程序無感知
• 解耦應(yīng)用程序的重試/超時、監(jiān)控、追蹤和服務(wù)發(fā)現(xiàn)

Service Mesh 架構(gòu)圖：

 

 

關(guān)于微服務(wù)和服務(wù)網(wǎng)格的區(qū)別，我的一些理解： 微服務(wù)更像是一個服務(wù)之間的生態(tài)，專注于服務(wù)治理等方面，而服務(wù)網(wǎng)格更專注于服務(wù)之間的通信，以及和 DevOps 更好的結(jié)合 。