==============
現在，我們先看看為什麼你應該考慮使用微服務。
<a target="_blank"></a>
該應用的核心是服務子產品、域對象子產品和事件子產品實作的業務邏輯。圍繞在核心周圍的是與外界互動的擴充卡。這些擴充卡包括資料庫通路元件、生産和消費消息的消息傳遞元件、暴露 api 或實作 ui 的 web 元件。
graph-01
盡管具有合乎邏輯的子產品化架構，但是該應用做為整體打包部署。具體的樣式依賴應用的語言和架構。例如許多java應用打成war包，部署在tomcat或 jetty這樣的應用伺服器。還有一些java應用打成獨立可執行的jar包。類似的，rails和node.js應用以目錄層次的形式打包。
寫成這種形式的應用極其普遍。它們非常易于開發，因為我們的ide和其他工具專注于建構一個單獨的應用。這樣的應用通常也易于測試。通過簡單地運作 應用就可以實作端到端的測試，使用selenium就可以測試ui。整體應用也易于部署。你僅僅需要複制打包的應用到伺服器。你也可以通過在負載均衡器後 面運作多個副本的方式擴充應用。在項目的早期階段，這種方式運作的很好。
巨大的、複雜的整體應用程式的另外一個問題是它是持續部署的障礙。目前，saas應用通常在一天之内會多次将改動推到生成環境。對于複雜的龐然大物，這極 其難處理，因為你必須重新部署整個應用來更新程式的任何一小部分。我前面提到的冗長的啟動時間也将産生不利的影響。而且因為改動的影響通常不能被充分的理 解，那麼你可能還必須做更廣泛的手工測試。最終導緻持續部署幾乎是不可能的。
整體應用程式的另外一個問題是可靠性。因為所有的子產品都在同一程序内運作，是以任一子產品的漏洞，比如記憶體洩露，将會影響整個程序。此外，因為應用程式的所有執行個體是一緻的，是以這些漏洞将會影響整個應用的可用性。.
最後但并非不重要，整體應用程式使得采用新架構、新語言極其困難。舉個例子來說，假設你有兩百萬行使用xyz架構寫的代碼。那麼使用新的abc架構重寫整 個應用将會是極其昂貴的（無論是時間還是花費），即使新架構相當的好。是以對于采用新技術，整體應用程式具有巨大的障礙。當你開始新的項目的時候，你将非 常糾結于選擇哪種技術。
總而言之：你有一個已經長成可怕的龐然大物的，幾乎沒有開發者可以了解的，成功的業務關鍵應用。這個應用程式使用過時的、沒有生産力的技術寫成，這使得招聘優秀的開發者變得非常困難。這個應用程式難以擴充而且不可靠。是以，靈活開發和應用傳遞是不可能的。
是以你能怎麼辦呢？
一個服務通常實作一組獨立的特性或功能，比如訂單管理、客戶管理等。每個微服務是一個具有六角形架構的迷你應用，其自己的六角形架構包含業務邏輯以及許多 擴充卡。某些微服務将會暴露供其他微服務或者用戶端使用的api。另外一些微服務可能實作web ui。在運作時，每個執行個體通常是一個雲虛拟機或者一個docker容器。
例如，前文所述的系統的一個可能的分解如下圖所示：
graph-03
應用的每個功能區域現在以微服務的方式實作。此外web應用程式分割成了一組更簡單的web應用程式（一個面向乘客的，一個面向司機的）。這使得更容易為特定的使用者、裝置或特定的用例部署單獨的服務。
每個後端服務暴露一套 rest api，大部分服務調用其他服務提供的 api。例如司機管理子產品使用通知服務告知空閑的司機可能的訂單。ui 服務調用其他服務來渲染 web 頁面。服務也可能使用異步的、基于消息的通信方式。服務間通信将會在本系列後面的文章中詳細讨論。
graph-05
應用通常綜合使用三種擴充。y 軸擴充分解應用程式到微服務，就像上圖展示的那樣。在運作時，為了吞吐量和可用性，x 軸擴充在負載均衡器後面運作多個服務的執行個體。某些應用也可能使用 z 軸擴充分割服務。下圖展示了如何使用 docker 将訂單管理服務部署在 aws ec2 上。
graph-02
微服務架構模式顯著地影響了應用程式與資料庫之間的關系。每個服務有自己的資料庫模式，而不是共享單個資料庫模式。盡管這種方式與企業級資料模型的 想法相悖，也會造成某些資料的備援。但是如果你想獲得微服務的好處，那麼每個服務一個資料庫模式是很關鍵的，因為這確定了松散耦合。下圖展示了應用的資料 庫架構。
graph-04
每個服務有其自己的資料庫。那麼服務就可以選擇使用最符合需求的資料庫，這就是所謂的混合持久化架構。例如查找乘客附近司機的司機管理子產品必須使用支援高效地理查詢的資料庫。
表面上微服務架構模式類似于 soa。這兩種架構都包含一組服務。你可以認為微服務架構模式就是不包括商業化和 web 服務規範（ws-）、企業服務總線（esb）的 soa。基于微服務的應用傾向于使用更簡單輕量級的協定，比如 rest 而不是 ws-。很大程度上也避免使用 esb，取而代之的是使用微服務自己實作類似 esb 的功能。微服務架構模式也拒絕 soa 的其他部分，比如規範模式的概念。
微服務架構模式有許多重要的好處。第一，它解決了複雜性的問題。它将一個可怕的、龐大的整體應用分解成一組服務。在整體的功能沒有改變的同時，應用 程式已經被分解成可管理的子產品或服務。每個服務有以 rpc 或者消息驅動 api 形式定義清楚的界限。微服務架構模式加強了一定程度的子產品化，這在整體應用程式中是很難實作的。是以單個的服務可以更快的開發，更簡單的了解和維護。
第二，這種架構使得每個服務可以由單獨的團隊獨立開發，這些團隊可以專注于某個服務。開發者可以自由地選擇合理的技術，隻要服務遵守 api 約定即可。當然大部分組織想要避免混亂地完全無限制的技術選項。然後這種自由意味着開發者不在受限于使用可能過時的技術開始新的項目。當開始寫一個新服務 的時候，他們可以選擇使用目前的技術。而且因為服務相對較小，是以使用目前的技術重寫老服務是可行的。
第三，微服務架構模式使得每一個微服務能被獨立部署。開發者再也不需要調整本地對其服務的更變 而進行部署。各種類型的變更能在他們測試時立即部署。ui 團隊也可以這樣做，舉例來說，當 ui 發生改變時，能執行 a|b 測試并快速疊代。微服務架構模式讓持續部署成為可能。
最後，微服務架構模式使得每一個服務都可以被獨立擴充。你可以部署大量恰好符合要求容量和有效限制條件的服務執行個體。此外，你可以使用最比對服務資源 要求的硬體。例如，你可以在計算優化過的 ec2上部署一個密集cpu 鏡像處理服務執行個體，還可以在記憶體優化的 ec2 上部署記憶體資料庫服務執行個體。
就像 fred brooks 在30年前說的，沒有銀彈。跟别的技術一樣，微服務架構也有缺點。其中的一個缺點就是名字本身。微服務這個詞過分強調服務的規模。實際上有些開發者支援構 建極其細粒度10-100 loc 的服務。盡管規模小的服務更可取，但是最好記住這隻是手段而不是目的。微服務的目的是充分地分解應用程式以促進靈活開發和部署。
微服務另外一個主要的缺點是微服務應用做為分布式系統帶來的複雜性。開發者需要選擇或者實作基于消息或 rpc 的程序間通信機制。而且必須編寫處理部分失敗的代碼，因為請求的目的地可能很慢或者不可用。雖然這都不是高深莫測的事情，但是相對于整體應用程式這明顯更 複雜，因為整體應用程式中子產品間的調用是通過語言層面的方法/程式調用實作的。
測試微服務也很複雜。使用 spring boot 這樣的現代架構很容易開始一個整體 web 應用程式，編寫測試類測試其 rest api。于此相反，對于微服務的一個類似的測試則需要運作該服務以及依賴的服務（或者至少需要配置那些服務的存根）。這也不是高深莫測的事情，但是不要低 估做這些事情的複雜性。
微服務架構模式另外一個主要的挑戰是實作跨服務的需求變更。設想你實作的使用者故事需要更改服務 a，因為 a 依賴 b，b 依賴 c，是以你又得更改服務 b 和 c。在整體應用中，你可以簡單地更改對應的子產品，內建這些變更一起部署。相反在微服務架構模式中，你需要仔細計劃和協調各個服務的更改上線。例如你需要首 先更新服務 c，接着是服務 b，最後才是服務 a。很幸運的是大部分改動通常隻影響一個服務，需要協調的跨服務更改相對較少。
建構複雜的應用本身就很難。整體架構隻适合簡單的輕量級應用。對于複雜的應用，如果你選用整體架構，那麼最終你會生活在痛苦之中。微服務架構對于複雜的、演化的應用是更好的選擇，盡管微服務架構有些缺點和實作上的挑戰。
在之後的文章中，我将會深入微服務架構模式的各個方面，探讨服務發現、服務部署、整體應用程式重構政策這些主題。
請繼續關注…
原文釋出時間：2015-05-25
本文來自雲栖合作夥伴“linux中國”