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