淺談服務(wù)治理與微服務(wù)

作者：Heaven-Wang
來源：blog.csdn.net/suifeng3051

近期都在談微服務(wù)，本人也正在做相關(guān)的工作，應(yīng)領(lǐng)導(dǎo)要求做了一個(gè)微服務(wù)的分享，本篇文章主要來源于分享的PPT，所以有些簡單，有問題可以在下面留言，大家 一起討論。

本篇文章先簡單介紹了互聯(lián)網(wǎng)架構(gòu)的演變，進(jìn)而介紹了服務(wù)化，最后再介紹微服務(wù)，微服務(wù)是服務(wù)治理的升級也是互聯(lián)網(wǎng)架構(gòu)的進(jìn)一步延伸。

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

一體架構(gòu)

在計(jì)算機(jī)軟件發(fā)展早期，一般桌面軟件都是采用這種架構(gòu)，不管是界面還是業(yè)務(wù)處理還是數(shù)據(jù)處理都放到一個(gè)包中。這種其實(shí)談不上架構(gòu)，但也可以說是很好的架構(gòu)，因?yàn)樗銐蚝唵巍?br style="margin: 0px;padding: 0px;max-width: 100%;overflow-wrap: break-word !important;box-sizing: border-box !important;">

mvc架構(gòu)

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

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

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

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

分布式架構(gòu)

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

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

服務(wù)化

服務(wù)化的特點(diǎn)

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

• 應(yīng)用按業(yè)務(wù)拆分成服務(wù)

• 各個(gè)服務(wù)均可獨(dú)立部署

• 服務(wù)可被多個(gè)應(yīng)用共享

• 服務(wù)之間可以通信

服務(wù)化的好處

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

• 架構(gòu)上系統(tǒng)更加清晰

• 核心模塊穩(wěn)定，以服務(wù)組件為單位進(jìn)行升級，避免了頻繁發(fā)布帶來的風(fēng)險(xiǎn)

• 開發(fā)管理方便

• 單獨(dú)團(tuán)隊(duì)維護(hù)、工作分明，職責(zé)清晰

• 業(yè)務(wù)復(fù)用、代碼復(fù)用

• 非常容易拓展

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

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

• Java RMI

• WebService

• Hessian

• Http

• Thrift

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

上面提到要實(shí)現(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ù)化，其實(shí)要想服務(wù)化，服務(wù)治理是關(guān)鍵。那么有沒有好的服務(wù)治理方案呢？答案是有的，而且很多人都在用這個(gè)框架，他就是-dubbo。dubbo就是一個(gè)帶有服務(wù)治理功能的RPC框架。

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

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

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

• 消費(fèi)者啟動(dòng)，向注冊中心訂閱自己需要的服務(wù)

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

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

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

集群容錯(cuò)

負(fù)載均衡

• Random Loadbalance

• RoundRobin

• LeastActive

• ConsistentHash

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

• 注冊中心只負(fù)責(zé)注冊查找，不負(fù)責(zé)請求轉(zhuǎn)發(fā)，壓力小

• 注冊中心宕機(jī)影響消費(fèi)者，消費(fèi)者本地緩存服務(wù)地址列表

• 注冊中心對等集群，宕掉一臺(tái)自動(dòng)切換到另外 一臺(tái)

• 服務(wù)提供者無狀態(tài)，可動(dòng)態(tài)部署，注冊中心負(fù)責(zé)推送

• 統(tǒng)計(jì)無壓力，本地內(nèi)存中累計(jì)次數(shù)，每分鐘發(fā)送注冊中心

• 消費(fèi)者調(diào)用服務(wù)者，自動(dòng)軟負(fù)載均衡

• 通過服務(wù)中心可追蹤依賴關(guān)系

• 監(jiān)控中心為擴(kuò)容和降級提供依據(jù)

• 可啟用acl機(jī)制進(jìn)行鑒權(quán)

• 與Spring整合，接入簡單松耦合

• 多種序列化協(xié)議支持

dubbo的不足

• 消費(fèi)者仍需要依賴配置中心

• 消費(fèi)者仍需要依賴jar包配置provider

• 提供者文檔管理功能缺失

• 無統(tǒng)一入口

• 不支持OAuth2.0

• 內(nèi)部鑒權(quán)不方便管理

• 無外部應(yīng)用鑒權(quán)

• 接口基本裸奔，無法直接對外暴露服務(wù)

• IT治理不方便

微服務(wù)

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

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

• 微：服務(wù)的粒度要細(xì)，即服務(wù)要細(xì)化到API

• 服務(wù)：提供好服務(wù)，要讓用戶感到好用(要做到這一點(diǎn)很不容易)

上面兩個(gè)核心總結(jié)起來，可以用下面這幅圖表示：

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

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

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

微服務(wù)的特點(diǎn)

服務(wù)需要再細(xì)化成API（服務(wù)接口——>服務(wù)API）

• 每個(gè)服務(wù)由一組API組成

• 以API形式對外提供統(tǒng)一格式的服務(wù)

• 使用者無需任何配置，直接調(diào)用（http）

• 完整的API文檔

• API服務(wù)安全可靠穩(wěn)定

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

上面提到了，dubbo還存在一些問題 ，其實(shí)dubbo存在的問題 就是 微服務(wù)要解決的問題，這里 再總結(jié)一下。當(dāng)然，dubbo和微服務(wù)的側(cè)重點(diǎn)不一樣，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)控與報(bào)警

• 整體架構(gòu)的可拓展、高并發(fā)、分布式

• 服務(wù)容器自動(dòng)收縮、擴(kuò)容

實(shí)現(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化

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

彈性云

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