微服務正在博客、社交媒體討論組和會議演講中獲得越來越多的關註，在Gartner的2014 Hype Cycle上它的排名非常靠前。同時，軟件社區中也有不少持懷疑論者，認為微服務不是什麽新東西。Naysayers認為這就是SOA架構的重新包裝。然 而，盡管存在著不同的爭論，微服務架構模式卻正在為敏捷部署以及復雜企業應用實施提供巨大的幫助。

首先我們看看為什麽要使用微服務。

開發單體式應用

假設你正準備開發一款與Uber和Hailo競爭的出租車調度軟件，經過初步會議和需求分析，你可能會手動或者使用基於Rails、Spring Boot、Play或者Maven的生成器開始這個新項目，它的六邊形架構是模塊化的 ，架構圖如下：

應用核心是業務邏輯，由定義服務、域對象和事件的模塊完成。圍繞著核心的是與外界打交道的適配器。適配器包括數據庫訪問組件、生產和處理消息的消息組件，以及提供API或者UI訪問支持的web模塊等。

盡管也是模塊化邏輯，但是最終它還是會打包並部署為單體式應用。具體的格式依賴於應用語言和框架。例如，許多Java應用會被打包為WAR格 式，部署在Tomcat或者Jetty上，而另外一些Java應用會被打包成自包含的JAR格式，同樣，Rails和Node.js會被打包成層級目錄。

這種應用開發風格很常見，因為IDE和其它工具都擅長開發一個簡單應用，這類應用也很易於調試，只需要簡單運行此應用，用Selenium鏈接 UI就可以完成端到端測試。單體式應用也易於部署，只需要把打包應用拷貝到服務器端，通過在負載均衡器後端運行多個拷貝就可以輕松實現應用擴展。在早期這 類應用運行的很好。

單體式應用的不足

不幸的是，這種簡單方法卻有很大的局限性。一個簡單的應用會隨著時間推移逐漸變大。在每次的sprint中， 開發團隊都會面對新“故事”，然後開發許多新代碼。幾Year後，這個小而簡單的應用會變成了一個巨大的怪物。這兒有一個例子，我最近和一個開發者討論，他正在 寫一個工具，用來分析他們一個擁有數百萬行代碼的應用中JAR文件之間的依賴關系。我很確信這個代碼正是很多開發者經過多Year努力開發出來的一個怪物。

一旦你的應用變成一個又大又復雜的怪物，那開發團隊肯定很痛苦。敏捷開發和部署舉步維艱，其中最主要問題就是這個應用太復雜，以至於任何單個開 發者都不可能搞懂它。因此，修正bug和正確的添加新功能變的非常困難，並且很耗時。另外，團隊士氣也會走下坡路。如果代碼難於理解，就不可能被正確的修 改。最終會走向巨大的、不可理解的泥潭。

單體式應用也會降低開發速度。應用越大，啟動時間會越長。比如，最近的一個調查表明，有時候應用的啟動時間居然超過了12分鐘。我還聽說某些應用需要40分鐘啟動時間。如果開發者需要經常重啟應用，那麽大部分時間就要在等待中渡過，生產效率受到極大影響。

另外，復雜而巨大的單體式應用也不利於持續性開發。今天，SaaS應用常態就是每天會改變很多次，而這對於單體式應用模式非常困難。另外，這種變化帶來的影響並沒有很好的被理解，所以不得不做很多手工測試。那麽接下來，持續部署也會很艱難。

單體式應用在不同模塊發生資源沖突時，擴展將會非常困難。比如，一個模塊完成一個CPU敏感邏輯，應該部署在AWS EC2 Compute Optimized instances，而另外一個內存數據庫模塊更合適於EC2 Memory-optimized instances。然而，由於這些模塊部署在一起，因此不得不在硬件選擇上做一個妥協。

單體式應用另外一個問題是可靠性。因為所有模塊都運行在一個進程中，任何一個模塊中的一個bug，比如內存泄露，將會有可能弄垮整個進程。除此之外，因為所有應用實例都是唯一的，這個bug將會影響到整個應用的可靠性。

最後，單體式應用使得采用新架構和語言非常困難。比如，設想你有兩百萬行采用XYZ框架寫的代碼。如果想改成ABC框架，無論是時間還是成本都是非常昂貴的，即使ABC框架更好。因此，這是一個無法逾越的鴻溝。你不得不在最初選擇面前低頭。

總結一下：一開始你有一個很成功的關鍵業務應用，後來就變成了一個巨大的，無法理解的怪物。因為采用過時的，效率低的技術，使得雇傭有潛力的開發者很困難。應用無法擴展，可靠性很低，最終，敏捷性開發和部署變的無法完成。

那麽如何應對呢？

微處理架構——處理復雜事物

許多公司，比如Amazon、eBay和NetFlix，通過采用微處理結構模式解決了上述問題。其思路不是開發一個巨大的單體式的應用，而是將應用分解為小的、互相連接的微服務。

一個微服務一般完成某個特定的功能，比如下單管理、客戶管理等等。每一個微服務都是微型六角形應用，都有自己的業務邏輯和適配器。一些微服務還 會發布API給其它微服務和應用客戶端使用。其它微服務完成一個Web UI，運行時，每一個實例可能是一個雲VM或者是Docker容器。

比如，一個前面描述系統可能的分解如下：

每一個應用功能區都使用微服務完成，另外，Web應用會被拆分成一系列簡單的Web應用（比如一個對乘客，一個對出租車駕駛員）。這樣的拆分對於不同用戶、設備和特殊應用場景部署都更容易。

每一個後臺服務開放一個REST API，許多服務本身也采用了其它服務提供的API。比如，駕駛員管理使用了告知駕駛員一個潛在需求的通知服務。UI服務激活其它服務來更新Web頁面。所有服務都是采用異步的，基於消息的通訊。微服務內部機制將會在後續系列中討論。

一些REST API也對乘客和駕駛員采用的移動應用開放。這些應用並不直接訪問後臺服務，而是通過API Gateway來傳遞中間消息。API Gateway負責負載均衡、緩存、訪問控制、API 計費監控等等任務，可以通過NGINX方便實現，後續文章將會介紹到API Gateway。

學習研究相關技術，求求（企鵝）2670716182

帶你走進微處理架構的世界