為什么我們需要微服務(wù)架構(gòu)?我們?nèi)绾尾拍軓闹惺芤妫?br />
10年前,正值或差不到了SOA炒作的巔峰。那時(shí)候,你的服務(wù)部署可能涉及到J2EE應(yīng)用服務(wù)器,要進(jìn)行基于EAR文件的部署,或者是一種更加面向集成的辦法—通過ESB聚焦于遺留的集成點(diǎn)并以基于SOAP的服務(wù)將其暴露出來。你所有的服務(wù)可能都是一兩支團(tuán)隊(duì)的,因?yàn)樗麄兪俏ㄒ焕斫膺@一技術(shù)的人。盡管Thomas Erl當(dāng)初那本有關(guān)SOA的書很火,但大多數(shù)服務(wù)并未遵循他的服務(wù)導(dǎo)向原則。應(yīng)用服務(wù)器或ESB生產(chǎn)時(shí)仍然部署在物理硬件上。
時(shí)光冉冉,再看看現(xiàn)在,情況已經(jīng)大為改觀。組織已經(jīng)有了多得多的服務(wù),且分別由許多不同的團(tuán)隊(duì)擁有。這一切都不是用Java寫的。服務(wù)被部署到虛擬機(jī)(VM)上,也許甚至是企業(yè)數(shù)據(jù)中心以外的公有云上。那么,我們?yōu)槭裁慈匀恍枰⒎?wù)架構(gòu)呢?這些變化我們一個(gè)個(gè)來看看吧。
我們?nèi)匀恍枰⒎?wù)架構(gòu)的理由
首先,你的服務(wù)多得多了。實(shí)際上,你多的可能是操作,但那些被捆綁進(jìn)了服務(wù)里面。只需看看那些操作的使用情況,我敢打賭,它們將遵循帕累托原則:你得流量里面80%(或更多)來自于20%(或更少)的服務(wù)。如果這些服務(wù)的每一個(gè)都由同樣規(guī)模的基礎(chǔ)設(shè)施來提供的話,你的資源利用率可能就會非常糟糕。此外,哪怕是在服務(wù)里面,也可能不是所有的操作消耗的流量都一樣的。對于特定的操作你卻不能(單獨(dú))伸縮能力;而是在整個(gè)服務(wù)水平上進(jìn)行。如果你還使用J2EE服務(wù)器的話,在同一集群下你甚至還會有多個(gè)EAR軟件,且不得不針對全部增加或移除能力。簡而言之,你無法根據(jù)處于獨(dú)立操作級的依賴性和需求做出基礎(chǔ)設(shè)施決策。
其次,這些服務(wù)被擴(kuò)散到了更多的團(tuán)隊(duì)中間。這會惡化資源利用率的問題,因?yàn)榇藘芍Р煌膱F(tuán)隊(duì)往往不希望共享基礎(chǔ)設(shè)施。因此,就得提供更多的服務(wù)器,哪怕能力本來就夠。更糟糕的是,組織總是在變的。一旦管理層做出的改變組織無法匹配服務(wù)的組織形式該怎么辦?你能否輕易繞開這些東西?記住,這不僅僅是這些基礎(chǔ)設(shè)施,還包括底層源代碼以及相關(guān)項(xiàng)目。
其三,并非所有的東西都是用Java EE或.NET寫的。帶框架的應(yīng)用服務(wù)器服務(wù)天下的日子已經(jīng)一去不復(fù)返。不要誤解我的意思,那些框架還在,如果說有什么區(qū)別的話,現(xiàn)在的趨勢正朝著你只需部署所需的模式發(fā)展。
最后一點(diǎn)是云。盡管我們還沒有到達(dá)那種程度,但會繼續(xù)看到越來越多的按需付費(fèi)模式的出現(xiàn),而不是2005年那種為固定能力付費(fèi)的模式,無論你的應(yīng)用場景如何。盡管這一模式在財(cái)務(wù)方面并不簡單(涉及到資本支出、運(yùn)營支出等等),但你很難否認(rèn)這一趨勢在近期內(nèi)會有所改變。這意味著基礎(chǔ)設(shè)施會繼續(xù)朝著實(shí)用模式發(fā)展,最終消費(fèi)者可以按照需要提高或降低能力。如果情況是這樣的話,我們需要一種能力能盡快就緒的模式,且負(fù)載應(yīng)該僅可能的低。這意味著我們不能等應(yīng)用服務(wù)器加載完一堆未必需要的東西。相反,我們希望擴(kuò)充的部分正好是我們需要的,不多也不少。
那么,當(dāng)我們把這些要素一起考慮時(shí),微服務(wù)架構(gòu)模式的情況就很明了了。盡管2005年的SOA的好處仍然有效,基于云的基礎(chǔ)設(shè)施、DevOps等這些帶來的變化現(xiàn)在已經(jīng)使得顆粒度到操作級的服務(wù)管理成為可能。我們?nèi)蕴幵谶@一努力的早期階段,在管理所有這些移動組件上仍存在著最大的鴻溝。幸運(yùn)的是,我們有很多好的例子可以學(xué)習(xí)。找一位老一點(diǎn)的有大型主機(jī)經(jīng)驗(yàn)的同事問問看,他們是如何在主機(jī)航管理所有那些獨(dú)立的微服務(wù)的。只需記住把那叫做事務(wù)?!?