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

[[183926]]

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

微服務的關鍵在于以獨立性方式支持應用的快速演進。另外，其應該能夠實現獨立擴展且資源需求量較基于服務器的應用程序更低。考慮到業務需求的不斷變化以及應用程序客戶量的不斷增加，集中式基礎設施在運營以及針對不可預測負載乃至負載峰值時會帶來過于高昂的成本。如果繼續堅守應用服務器，則根本不可能實現Netflix、Twitter或者Amazon這類解決方案。

微服務屬于分布式系統。前者有何特別之處?

分布式系統的初始概念為：“分布式系統是指一套其中各組件位于聯網計算機當中，并通過發送消息實現彼此通信與協作的模型。”這一點也同樣適用于微服務架構。

個別服務被部署在云實例當中，并通過交換信息的方式實現運行功能。這一思路與集中式應用程序構建存在巨大差別。相較于在數據中心內設置大量服務器用以處理各類同步、事務及故障場景，現在我們開始以獨立形式開發個別服務且各服務間互不影響。當然，分布式計算也會帶來一些特殊的基礎性挑戰，具體包括容錯、同步、自我修復、背壓以及網絡劃分等等。

分布式系統是否正是人們所說的反應性系統?

實際情況更為復雜。坦率地講，如今很多概念都會使用“反應性”一詞。要利用多個獨立微服務構建起應用程序或者系統，大家需要利用各項設計原則以實現其彼此反應性、彈性以及消息驅動能力。也許這聽起來頗為熟悉——沒錯，Reactive Manifesto給出的定義正是如此。

能夠實現Reactive Manifesto提出的四大特性的分布式系統即可被稱為反應性系統。舉例來說，Lagom框架就基于這些基本原則，但具體來講，大家并不需要利用特定框架或者產品來構建此類應用，因為這類框架或產品只是為了提升執行效率。

我們可以利用哪些選項構建一套基于微服務的系統?

我個人認為目前的微服務呈現出兩種解決問題的趨勢。其一為將問題下移，從而將其交由編排、數據中心或者云系統負責解決。第二種解決方案則是立足應用程序或者框架層面進行本地解決。

每服務一容器，為什么不能讓容器容納更多應用元素?

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

就個人而言，我認為這種方案的弊端在于缺少與基礎設施的緊密耦合。這意味著整套系統無法在選定的平臺之外運行。另外，有人認為可以單純依靠容器技術解決微服務領域的所有難題。但通過回顧Reactive Manifesto，大家就會意識到這類系統無法幫助我們實現服務之間的信息傳遞要求。

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

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

反應性編程、系統、流程：是否都屬于同一回事?

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

原文標題：From Microservices to Distributed Systems: A Survival Guide for Java Devs

原文作者：Markus Eisele

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】