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