人中心_normal.png)
微服務(wù)概述
SOA團(tuán)隊(duì) 2020-03-16
■ 微服務(wù)架構(gòu)的概念
從上圖可以看到，微服務(wù)架構(gòu)的第一個(gè)重點(diǎn)，即業(yè)務(wù)系統(tǒng)本身的組件化和服務(wù)化，原來開發(fā)一個(gè)業(yè)務(wù)系統(tǒng)本身雖然分了組件和模塊，但是本質(zhì)還是緊耦合的，這關(guān)鍵的一個(gè)判斷標(biāo)準(zhǔn)就是如果要將原有的業(yè)務(wù)系統(tǒng)按照模塊分開部署到不同的進(jìn)程里面并完成一個(gè)完整業(yè)務(wù)系統(tǒng)是不可能實(shí)現(xiàn)的。而對于微服務(wù)架構(gòu)強(qiáng)調(diào)的第一個(gè)重點(diǎn)就是業(yè)務(wù)系統(tǒng)需要徹底的組件化和服務(wù)化，原有的單個(gè)業(yè)務(wù)系統(tǒng)會(huì)拆分為多個(gè)可以獨(dú)立開發(fā)，設(shè)計(jì)，運(yùn)行和運(yùn)維的小應(yīng)用。這些小應(yīng)用之間通過服務(wù)完成交互和集成。每個(gè)小應(yīng)用從前端web ui，到控制層，邏輯層，數(shù)據(jù)庫訪問，數(shù)據(jù)庫都完全是獨(dú)立的一套。在這里我們不用組件而用小應(yīng)用這個(gè)詞更加合適，每個(gè)小應(yīng)用除了完成自身本身的業(yè)務(wù)功能外，重點(diǎn)就是還需要消費(fèi)外部其它應(yīng)用暴露的服務(wù)，同時(shí)自身也將自身的能力朝外部發(fā)布為服務(wù)。
把這個(gè)核心搞清楚后，再來看下網(wǎng)上找到的對微服務(wù)架構(gòu)的一些定義和闡述：
微服務(wù)可以在“自己的程序”中運(yùn)行，并通過“輕量級設(shè)備與HTTP型API進(jìn)行溝通”。關(guān)鍵在于該服務(wù)可以在自己的程序中運(yùn)行。通過這一點(diǎn)我們就可以將服務(wù)公開與微服務(wù)架構(gòu)（在現(xiàn)有系統(tǒng)中分布一個(gè)API）區(qū)分開來。在服務(wù)公開中，許多服務(wù)都可以被內(nèi)部獨(dú)立進(jìn)程所限制，如果其中任何一個(gè)服務(wù)需要增加某種功能，那么就必須縮小進(jìn)程范圍。而在微服務(wù)架構(gòu)中，只需要在特定的某種服務(wù)中增加所需功能，而不影響整體進(jìn)程。
微服務(wù)不需要像普通服務(wù)那樣成為一種獨(dú)立的功能或者獨(dú)立的資源。定義中稱，微服務(wù)是需要與業(yè)務(wù)能力相匹配，這種說法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設(shè)計(jì)是錯(cuò)誤的，那么，我們就必須付出很多代價(jià)。如果你閱讀了Fowler的整篇文章，你會(huì)發(fā)現(xiàn)，其中的指導(dǎo)建議是非常實(shí)用的。在決定將所有組件組合到一起時(shí)，開發(fā)人員需要非常確信這些組件都會(huì)有所改變，并且規(guī)模也會(huì)發(fā)生變化。服務(wù)粒度越粗，就越難以符合規(guī)定原則。服務(wù)粒度越細(xì)，就越能夠靈活地降低變化和負(fù)載所帶來的影響。然而，利弊之間的權(quán)衡過程是非常復(fù)雜的，我們要在配置和資金模型的基礎(chǔ)上考慮到基礎(chǔ)設(shè)施的成本問題。
對于上面紅色字體標(biāo)注的兩點(diǎn)，再強(qiáng)調(diào)下即：
● 首先對于應(yīng)用本身暴露出來的服務(wù)，是和應(yīng)用一起部署的，即服務(wù)本身并不單獨(dú)部署，服務(wù)本身就是業(yè)務(wù)組件已有的接口能力發(fā)布和暴露出來的。了解到這點(diǎn)我們就看到一個(gè)關(guān)鍵，即我們在進(jìn)行單個(gè)應(yīng)用組件設(shè)計(jì)的時(shí)候，本身在組件內(nèi)部就會(huì)有很大接口的設(shè)計(jì)和定義，那么這些接口我們可以根據(jù)和外部其它組件協(xié)同的需要將其發(fā)布為微服務(wù)，而如果不需要對外協(xié)同我們完全可以走內(nèi)部API接口訪問模式提高效率。
● 其次，微服務(wù)架構(gòu)本身來源于互聯(lián)網(wǎng)的思路，因此組件對外發(fā)布的服務(wù)強(qiáng)調(diào)了采用HTTP Rest API的方式來進(jìn)行。這個(gè)也可以看到在互聯(lián)網(wǎng)開放能力服務(wù)平臺(tái)基本都采用了Http API的方式進(jìn)行服務(wù)的發(fā)布和管理。從這個(gè)角度來說，組件朝外部暴露的能力才需要發(fā)布為微服務(wù)，其本身也是一種封裝后的粗粒度服務(wù)。而不是將組件內(nèi)部的所有業(yè)務(wù)規(guī)則和邏輯，組件本身的底層數(shù)據(jù)庫CRUD操作全部朝外部發(fā)布。否則將極大的增加服務(wù)的梳理而難以進(jìn)行整體服務(wù)管控和治理。
微服務(wù)的基本思想在于考慮圍繞著業(yè)務(wù)領(lǐng)域組件來創(chuàng)建應(yīng)用，這些應(yīng)用可獨(dú)立地進(jìn)行開發(fā)、管理和加速。在分散的組件中使用微服務(wù)云架構(gòu)和平臺(tái)使部署、管理和服務(wù)功能交付變得更加簡單。
■ 微服務(wù)架構(gòu)的核心內(nèi)容
■ 傳統(tǒng)的單體應(yīng)用
要講微服務(wù)架構(gòu)，一定涉及到微服務(wù)架構(gòu)和傳統(tǒng)單體應(yīng)用的區(qū)別問題，先看下傳統(tǒng)單體應(yīng)用：
很多單體應(yīng)用有時(shí)候也在強(qiáng)調(diào)是基于組件化和模塊化的開始思路開發(fā)的，或者說是基于SOA架構(gòu)開發(fā)，那從運(yùn)行態(tài)和設(shè)計(jì)態(tài)分別來看的話可以看到。
● 從運(yùn)行態(tài)的視角：
1. DB走HA或RAC集群，但是擴(kuò)展性是大問題，很多應(yīng)用后期即使走了RAC也無法解決性能問題。
2. 部署的是一個(gè)大WAR包，無法分模塊獨(dú)立分開部署。
3. WAR部署當(dāng)前可以是物理機(jī)，也可以是虛擬機(jī)，但是WAR包偏重，很少直接部署到Docker容器的。
4. Application Server層的性能可以通過負(fù)載均衡方式進(jìn)行水平擴(kuò)展。
● 從設(shè)計(jì)態(tài)的視角：
1. DB本身是無法拆分的，各個(gè)模塊的數(shù)據(jù)庫，視圖全在一個(gè)大的SID或Schema里面。
2. 模塊之間的交互除了通過邏輯層外，還有些是直接通過DB層的跨表連接完成的。
3. 邏輯層的模塊和模塊之間往往是緊耦合的，相互間的調(diào)用隨意，很多都是內(nèi)部API或方法調(diào)用。
不管是從運(yùn)行態(tài)還是設(shè)計(jì)態(tài)來看，傳統(tǒng)的單體應(yīng)用最大的問題就是各個(gè)組件和模塊之間緊耦合，而這種耦合帶來的問題就是擴(kuò)展困難，升級和變更困難（模塊間相互影響大）。
其次，傳統(tǒng)單體應(yīng)用面臨的第二個(gè)問題是展現(xiàn)層和邏輯層的緊耦合，而實(shí)際在當(dāng)前應(yīng)用架構(gòu)設(shè)計(jì)和開發(fā)中，可以看到需要同時(shí)滿足電腦，平板，手機(jī)APP終端等多種前端展現(xiàn)和訪問。而這種訪問必須是支持分布式的接口服務(wù)訪問模式。傳統(tǒng)單體應(yīng)用要做到這點(diǎn)也只有進(jìn)行改造，比如再單獨(dú)增加一個(gè)服務(wù)代理組件來發(fā)布服務(wù)。
■ 傳統(tǒng)單體應(yīng)用到微服務(wù)架構(gòu)
正是由于傳統(tǒng)單體應(yīng)用存在的一些問題，微服務(wù)架構(gòu)提出了將傳統(tǒng)單體應(yīng)用打散為多個(gè)離散，自治的獨(dú)立組件。這些組件你可以稱呼它為微服務(wù)模塊，這些微服務(wù)模塊本身需要滿足的就是從數(shù)據(jù)庫，到邏輯層，到界面展現(xiàn)層都能夠是獨(dú)立的一套；微服務(wù)模塊能夠從需求，設(shè)計(jì)，開發(fā)，測試，部署上線和運(yùn)維都相對獨(dú)立。
這個(gè)思想本質(zhì)仍然是SOA架構(gòu)思想和組件化思想在業(yè)務(wù)系統(tǒng)內(nèi)部應(yīng)用的體現(xiàn)?；谝陨纤伎?，傳統(tǒng)單體應(yīng)用轉(zhuǎn)變?yōu)槲⒎?wù)架構(gòu)后如下圖所示：
● 從運(yùn)行態(tài)的視角：
1. 數(shù)據(jù)庫在部署的時(shí)候是可物理拆分的，即不同微服務(wù)模塊的數(shù)據(jù)庫可以獨(dú)立部署。
2. 微服務(wù)模塊的應(yīng)用組件包是獨(dú)立部署的。
3. WAR包由于已經(jīng)按模塊拆分為多個(gè)，因此每個(gè)WAR包相對來說更加輕，而容易部署到類似Docker容器上。
4. 由于WAR包之間有接口交互和協(xié)同，需要增加微服務(wù)網(wǎng)關(guān)實(shí)現(xiàn)服務(wù)管理和治理。
● 從設(shè)計(jì)態(tài)的視角：
1. 數(shù)據(jù)庫，邏輯層和界面展現(xiàn)在設(shè)計(jì)的時(shí)候就是完全相對獨(dú)立的一套。
2. 邏輯層的各個(gè)組件之間只能通過Service API接口進(jìn)行交互，微服務(wù)架構(gòu)下推薦輕量Http Rest接口。
3. 邏輯層各個(gè)模塊之間徹底實(shí)現(xiàn)松耦合，各個(gè)模塊本身也更加輕量。
■ 微服務(wù)架構(gòu)的核心單元-微服務(wù)網(wǎng)關(guān)
在引入微服務(wù)架構(gòu)后，最大的一個(gè)變化就是原來單個(gè)業(yè)務(wù)系統(tǒng)內(nèi)部的各個(gè)模塊之間需要通過分布式的服務(wù)接口進(jìn)行調(diào)用和協(xié)同了，而不是簡單的走內(nèi)部的API調(diào)用。
那么對于復(fù)雜的各個(gè)模塊間的點(diǎn)對點(diǎn)調(diào)用，就需要有一個(gè)類似ESB總線的中間件將這些接口服務(wù)統(tǒng)一管理起來，以實(shí)現(xiàn)對服務(wù)注冊，安全，流控，日志審計(jì)，消息，代理和路由的統(tǒng)一管理。而這些轉(zhuǎn)到微服務(wù)架構(gòu)后即是由微服務(wù)網(wǎng)關(guān)來完成。
在這個(gè)意思上來看，微服務(wù)網(wǎng)關(guān)類似簡化了的ESB，沒有了ESB總線復(fù)雜的適配，協(xié)議轉(zhuǎn)換，內(nèi)容轉(zhuǎn)換，數(shù)據(jù)映射，服務(wù)編排等功能。也可以說微服務(wù)網(wǎng)關(guān)是傳統(tǒng)OSGI網(wǎng)關(guān)能力的進(jìn)一步增強(qiáng)。
遠(yuǎn)行科技
遠(yuǎn)行云商
