為什么我們需要微服務架構？我們如何才能從中受益？

10年前，正值或差不到了SOA炒作的巔峰。那時候，你的服務部署可能涉及到J2EE應用服務器，要進行基于EAR文件的部署，或者是一種更加面向集成的辦法—通過ESB聚焦于遺留的集成點并以基于SOAP的服務將其暴露出來。你所有的服務可能都是一兩支團隊的，因為他們是唯一理解這一技術的人。盡管Thomas Erl當初那本有關SOA的書很火，但大多數服務并未遵循他的服務導向原則。應用服務器或ESB生產時仍然部署在物理硬件上。

時光冉冉，再看看現在，情況已經大為改觀。組織已經有了多得多的服務，且分別由許多不同的團隊擁有。這一切都不是用Java寫的。服務被部署到虛擬機（VM）上，也許甚至是企業(yè)數據中心以外的公有云上。那么，我們?yōu)槭裁慈匀恍枰⒎占軜嬆兀窟@些變化我們一個個來看看吧。

我們仍然需要微服務架構的理由

首先，你的服務多得多了。實際上，你多的可能是操作，但那些被捆綁進了服務里面。只需看看那些操作的使用情況，我敢打賭，它們將遵循帕累托原則：你得流量里面80%（或更多）來自于20%（或更少）的服務。如果這些服務的每一個都由同樣規(guī)模的基礎設施來提供的話，你的資源利用率可能就會非常糟糕。此外，哪怕是在服務里面，也可能不是所有的操作消耗的流量都一樣的。對于特定的操作你卻不能（單獨）伸縮能力；而是在整個服務水平上進行。如果你還使用J2EE服務器的話，在同一集群下你甚至還會有多個EAR軟件，且不得不針對全部增加或移除能力。簡而言之，你無法根據處于獨立操作級的依賴性和需求做出基礎設施決策。

其次，這些服務被擴散到了更多的團隊中間。這會惡化資源利用率的問題，因為此兩支不同的團隊往往不希望共享基礎設施。因此，就得提供更多的服務器，哪怕能力本來就夠。更糟糕的是，組織總是在變的。一旦管理層做出的改變組織無法匹配服務的組織形式該怎么辦？你能否輕易繞開這些東西？記住，這不僅僅是這些基礎設施，還包括底層源代碼以及相關項目。

其三，并非所有的東西都是用Java EE或.NET寫的。帶框架的應用服務器服務天下的日子已經一去不復返。不要誤解我的意思，那些框架還在，如果說有什么區(qū)別的話，現在的趨勢正朝著你只需部署所需的模式發(fā)展。

最后一點是云。盡管我們還沒有到達那種程度，但會繼續(xù)看到越來越多的按需付費模式的出現，而不是2005年那種為固定能力付費的模式，無論你的應用場景如何。盡管這一模式在財務方面并不簡單（涉及到資本支出、運營支出等等），但你很難否認這一趨勢在近期內會有所改變。這意味著基礎設施會繼續(xù)朝著實用模式發(fā)展，最終消費者可以按照需要提高或降低能力。如果情況是這樣的話，我們需要一種能力能盡快就緒的模式，且負載應該僅可能的低。這意味著我們不能等應用服務器加載完一堆未必需要的東西。相反，我們希望擴充的部分正好是我們需要的，不多也不少。

那么，當我們把這些要素一起考慮時，微服務架構模式的情況就很明了了。盡管2005年的SOA的好處仍然有效，基于云的基礎設施、DevOps等這些帶來的變化現在已經使得顆粒度到操作級的服務管理成為可能。我們仍處在這一努力的早期階段，在管理所有這些移動組件上仍存在著最大的鴻溝。幸運的是，我們有很多好的例子可以學習。找一位老一點的有大型主機經驗的同事問問看，他們是如何在主機航管理所有那些獨立的微服務的。只需記住把那叫做事務。