【51CTO.com快譯】時(shí)至今日，微服務(wù)框架已經(jīng)從炒作逐漸轉(zhuǎn)化為切實(shí)可行的方案。整個(gè)技術(shù)行業(yè)開始意識(shí)到，我們很難單純通過在現(xiàn)有組件之上開放HTTP接口的方式構(gòu)建起符合微服務(wù)規(guī)范要求的系統(tǒng)。雖然很多組織機(jī)構(gòu)明確表示，架構(gòu)及其編排的重要意義絲毫不低于基礎(chǔ)設(shè)施優(yōu)化、文化轉(zhuǎn)型乃至組織調(diào)整等事務(wù)，等大部分Java開導(dǎo)得仍然很難把握具體的系統(tǒng)架構(gòu)，或者說很難將微服務(wù)與分布式系統(tǒng)區(qū)分開來。而這些認(rèn)知恰好是決定項(xiàng)目成敗的關(guān)鍵所在。在今天的文章中，我們將通過問答的形式對(duì)此作出闡述。

[[183926]]

為什么要重提微服務(wù)?我們難道不能繼續(xù)編寫EBJ及Servelet嗎?

微服務(wù)的關(guān)鍵在于以獨(dú)立性方式支持應(yīng)用的快速演進(jìn)。另外，其應(yīng)該能夠?qū)崿F(xiàn)獨(dú)立擴(kuò)展且資源需求量較基于服務(wù)器的應(yīng)用程序更低?？紤]到業(yè)務(wù)需求的不斷變化以及應(yīng)用程序客戶量的不斷增加，集中式基礎(chǔ)設(shè)施在運(yùn)營(yíng)以及針對(duì)不可預(yù)測(cè)負(fù)載乃至負(fù)載峰值時(shí)會(huì)帶來過于高昂的成本。如果繼續(xù)堅(jiān)守應(yīng)用服務(wù)器，則根本不可能實(shí)現(xiàn)Netflix、Twitter或者Amazon這類解決方案。

微服務(wù)屬于分布式系統(tǒng)。前者有何特別之處?

分布式系統(tǒng)的初始概念為：“分布式系統(tǒng)是指一套其中各組件位于聯(lián)網(wǎng)計(jì)算機(jī)當(dāng)中，并通過發(fā)送消息實(shí)現(xiàn)彼此通信與協(xié)作的模型。”這一點(diǎn)也同樣適用于微服務(wù)架構(gòu)。

個(gè)別服務(wù)被部署在云實(shí)例當(dāng)中，并通過交換信息的方式實(shí)現(xiàn)運(yùn)行功能。這一思路與集中式應(yīng)用程序構(gòu)建存在巨大差別。相較于在數(shù)據(jù)中心內(nèi)設(shè)置大量服務(wù)器用以處理各類同步、事務(wù)及故障場(chǎng)景，現(xiàn)在我們開始以獨(dú)立形式開發(fā)個(gè)別服務(wù)且各服務(wù)間互不影響。當(dāng)然，分布式計(jì)算也會(huì)帶來一些特殊的基礎(chǔ)性挑戰(zhàn)，具體包括容錯(cuò)、同步、自我修復(fù)、背壓以及網(wǎng)絡(luò)劃分等等。

分布式系統(tǒng)是否正是人們所說的反應(yīng)性系統(tǒng)?

實(shí)際情況更為復(fù)雜。坦率地講，如今很多概念都會(huì)使用“反應(yīng)性”一詞。要利用多個(gè)獨(dú)立微服務(wù)構(gòu)建起應(yīng)用程序或者系統(tǒng)，大家需要利用各項(xiàng)設(shè)計(jì)原則以實(shí)現(xiàn)其彼此反應(yīng)性、彈性以及消息驅(qū)動(dòng)能力。也許這聽起來頗為熟悉——沒錯(cuò)，Reactive Manifesto給出的定義正是如此。

能夠?qū)崿F(xiàn)Reactive Manifesto提出的四大特性的分布式系統(tǒng)即可被稱為反應(yīng)性系統(tǒng)。舉例來說，Lagom框架就基于這些基本原則，但具體來講，大家并不需要利用特定框架或者產(chǎn)品來構(gòu)建此類應(yīng)用，因?yàn)檫@類框架或產(chǎn)品只是為了提升執(zhí)行效率。

我們可以利用哪些選項(xiàng)構(gòu)建一套基于微服務(wù)的系統(tǒng)?

我個(gè)人認(rèn)為目前的微服務(wù)呈現(xiàn)出兩種解決問題的趨勢(shì)。其一為將問題下移，從而將其交由編排、數(shù)據(jù)中心或者云系統(tǒng)負(fù)責(zé)解決。第二種解決方案則是立足應(yīng)用程序或者框架層面進(jìn)行本地解決。

每服務(wù)一容器，為什么不能讓容器容納更多應(yīng)用元素?

這里我們先來討論之前提到的***種方法。編寫一項(xiàng)微服務(wù)，將其與運(yùn)行時(shí)一道打包在小型容器內(nèi)，而后將其推送至云端。作為全棧DevOps開發(fā)者，大家應(yīng)該能夠輕松創(chuàng)建起云運(yùn)行時(shí)所必需的元信息。另外，我們也能夠憑借著詳盡的監(jiān)控信息輕松檢測(cè)到失敗服務(wù)并對(duì)其進(jìn)行重啟。另外，也有很多神奇的框架(NetflixOSS)有助于應(yīng)對(duì)分布式系統(tǒng)中的各類挑戰(zhàn)。

就個(gè)人而言，我認(rèn)為這種方案的弊端在于缺少與基礎(chǔ)設(shè)施的緊密耦合。這意味著整套系統(tǒng)無法在選定的平臺(tái)之外運(yùn)行。另外，有人認(rèn)為可以單純依靠容器技術(shù)解決微服務(wù)領(lǐng)域的所有難題。但通過回顧Reactive Manifesto，大家就會(huì)意識(shí)到這類系統(tǒng)無法幫助我們實(shí)現(xiàn)服務(wù)之間的信息傳遞要求。

沒有容器作為輔助的微服務(wù)?這可能嗎?

誠(chéng)然，容器技術(shù)擁有一項(xiàng)***的優(yōu)勢(shì)：將完整堆棧以可控方式打包為單一可部署單元。其在基礎(chǔ)設(shè)施層面來看可算是一種隔離機(jī)制。而容器標(biāo)準(zhǔn)本身亦是一項(xiàng)助益，意味著我們的容器更易于保存及使用。但這還遠(yuǎn)遠(yuǎn)不夠。要構(gòu)建起具備彈性與自我修復(fù)能力的系統(tǒng)，我們需要能夠容納錯(cuò)誤、將其定義為信息、將信息發(fā)送給其它組件(即監(jiān)控型組件)并在故障組件之外進(jìn)行安全管理。而這一切需要信息驅(qū)動(dòng)型機(jī)制方可實(shí)現(xiàn)：遠(yuǎn)離強(qiáng)耦合、脆弱及深層嵌套當(dāng)中的同步調(diào)用鏈，轉(zhuǎn)而讓各個(gè)組件擁有容錯(cuò)能力……或者忽略能力。我們的思路是對(duì)調(diào)用鏈內(nèi)的故障管理機(jī)制進(jìn)行去耦，意味著客戶不再需要負(fù)責(zé)處理服務(wù)器故障。很明顯，沒有哪種容器或者編排工具能夠?qū)崿F(xiàn)這樣的效果。大家需要進(jìn)行事件溯源。事件驅(qū)動(dòng)型架構(gòu)正因?yàn)樵谠O(shè)計(jì)概念中考慮到了事件溯源，因此能夠很好地同微服務(wù)架構(gòu)模式進(jìn)行配合。

反應(yīng)性編程、系統(tǒng)、流程：是否都屬于同一回事?

反應(yīng)性已經(jīng)成為一個(gè)被濫用的詞匯，目前不同的人對(duì)其有所不同的理解——在出色的企業(yè)中，其代表著“流式”、“輕量化”以及“實(shí)時(shí)”等含義。反應(yīng)性編程能夠通過性能與資源效率等角度提升開發(fā)者生產(chǎn)力，且立足于內(nèi)部邏輯與數(shù)據(jù)流管理的組件層面。反應(yīng)性系統(tǒng)則幫助架構(gòu)師與DevOps團(tuán)隊(duì)通過彈性能力實(shí)現(xiàn)生產(chǎn)力提升，立足于云原生或者其它大規(guī)模分布式系統(tǒng)的系統(tǒng)構(gòu)建層面。

原文標(biāo)題：From Microservices to Distributed Systems: A Survival Guide for Java Devs

原文作者：Markus Eisele

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】