這篇文章作者是Chris Richardson，他是早期基於Java的Amazonite EC2 PaaS平臺CloudFoundry.com的創始人。現在他為企業提供如何開發和部署應用的諮詢服務。他也經常在http://microservices.io上發表有關微服務的文章。

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

　　這篇部落格是關於如何設計、開發和部署微服務的七篇系列文章中的第一篇。讀者將會從中學到方法，並且和單體式架構模式（譯者注：本文中會將 Monolithic翻譯為單體）進行對比。這一系列文章將描述微服務架構中不同元素。你將瞭解到微服務架構模式的優缺點，以便決定是否更好的將微服務架構應用到自己的專案中，以及如何應用這一模式。

　　首先我們看看為什麼要考慮使用微服務。

　　開發單體式應用

　　假設你正準備開發一款與Uber和Hailo競爭的計程車排程軟體，經過初步會議和需求分析，你可能會手動或者使用基於Rails、spring Boot、Play或者Maven的生成器開始這個新專案，它的六邊形架構是模組化的 ，架構圖如下：

　　應用核心是業務邏輯，由定義服務、域物件和事件的模組完成。圍繞著核心的是與外界打交道的介面卡。介面卡包括資料庫訪問元件、生產和處理訊息的訊息元件，以及提供API或者UI訪問支援的web模組等。

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

　　這種應用開發風格很常見，因為IDE和其它工具都擅長開發一個簡單應用，這類應用也很易於除錯，只需要簡單執行此應用，用Selenium連結UI就可以完成端到端

　　單體式應用的不足

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

　　一旦你的應用變成一個又大又複雜的怪物，那開發團隊肯定很痛苦。敏捷開發和部署舉步維艱，其中最主要問題就是這個應用太複雜，以至於任何單個開發者都不可能搞懂它。因此，修正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。

　　·微服務架構模式在上圖中對應於代表可擴充套件Scale Cube的Y軸，這是一個在《The Art of Scalability》書中描述過的三維擴充套件模型。另外兩個可擴充套件軸，X軸由負載均衡器後端執行的多個應用副本組成，Z軸是將需求路由到相關服務。

　　應用基本可以用以上三個維度來表示，Y軸代表將應用分解為微服務。執行時，X軸代表執行多個隱藏在負載均衡器之後的例項，提供吞吐能力。一些應用可能還是用Z軸將服務分割槽。下面的圖演示行程管理服務如何部署在運行於AWS EC2上的docker上。

　　執行時，行程管理服務由多個服務例項構成。每一個服務例項都是一個Docker容器。為了保證高可用，這些容器一般都執行在多個雲VM上。服務例項前是一層諸如NGINX的負載均衡器，他們負責在各個例項間分發請求。負載均衡器也同時處理其它請求，例如快取、許可權控制、API統計和監控。

　　這種微服務架構模式深刻影響了應用和資料庫之間的關係，不像傳統多個服務共享一個數據庫，微服務架構每個服務都有自己的資料庫。另外，這種思路也影響到了企業級資料模式。同時，這種模式意味著多份資料，但是，如果你想獲得微服務帶來的好處，每個服務獨有一個數據庫是必須的，因為這種架構需要這種鬆耦合。下面的圖演示示例應用資料庫架構。

　　每種服務都有自己的資料庫，另外，每種服務可以用更適合自己的資料庫型別，也被稱作多語言一致性架構。比如，駕駛員管理（發現哪個駕駛員更靠近乘客），必須使用支援地理資訊查詢的資料庫。

　　表面上看來，微服務架構模式有點像SOA，他們都由多個服務構成。但是，可以從另外一個角度看此問題，微服務架構模式是一個不包含Web服務（WS-）和ESB服務的SOA。微服務應用樂於採用簡單輕量級協議，比如REST，而不是WS-，在微服務內部避免使用ESB以及ESB類似功能。微服務架構模式也拒絕使用canonical schema等SOA概念。

　　微服務架構的好處

　　微服務架構模式有很多好處。首先，通過分解巨大單體式應用為多個服務方法解決了複雜性問題。在功能不變的情況下，應用被分解為多個可管理的分支或服務。每個服務都有一個用RPC-或者訊息驅動API定義清楚的邊界。微服務架構模式給採用單體式編碼方式很難實現的功能提供了模組化的解決方案，由此，單個服務很容易開發、理解和維護。

　　第二，這種架構使得每個服務都可以有專門開發團隊來開發。開發者可以自由選擇開發技術，提供API服務。當然，許多公司試圖避免混亂，只提供某些技術選擇。然後，這種自由意味著開發者不需要被迫使用某專案開始時採用的過時技術，他們可以選擇現在的技術。甚至於，因為服務都是相對簡單，即使用現在技術重寫以前程式碼也不是很困難的事情。

　　第三，微服務架構模式是每個微服務獨立的部署。開發者不再需要協調其它服務部署對本服務的影響。這種改變可以加快部署速度。UI團隊可以採用AB測試，快速的部署變化。微服務架構模式使得持續化部署成為可能。

　　最後，微服務架構模式使得每個服務獨立擴充套件。你可以根據每個服務的規模來部署滿足需求的規模。甚至於，你可以使用更適合於服務資源需求的硬體。比如，你可以在EC2 Compute Optimized instances上部署CPU敏感的服務，而在EC2 memory-optimized instances上部署記憶體資料庫。

　　微服務架構的不足

　　Fred Brooks在30年前寫道，“there are no silver bullets”，像任何其它科技一樣，微服務架構也有不足。其中一個跟他的名字類似，『微服務』強調了服務大小，實際上，有一些開發者鼓吹建立稍微大一些的，10-100 LOC服務組。儘管小服務更樂於被採用，但是不要忘了這只是終端的選擇而不是最終的目的。微服務的目的是有效的拆分應用，實現敏捷開發和部署。

　　另外一個主要的不足是，微服務應用是分散式系統，由此會帶來固有的複雜性。開發者需要在RPC或者訊息傳遞之間選擇並完成程序間通訊機制。更甚於，他們必須寫程式碼來處理訊息傳遞中速度過慢或者不可用等區域性失效問題。當然這並不是什麼難事，但相對於單體式應用中通過語言層級的方法或者程序呼叫，微服務下這種技術顯得更復雜一些。

　　另外一個關於微服務的挑戰來自於分割槽的資料庫架構。商業交易中同時給多個業務分主體更新訊息很普遍。這種交易對於單體式應用來說很容易，因為只有一個數據庫。在微服務架構應用中，需要更新不同服務所使用的不同的資料庫。使用分散式交易並不一定是好的選擇，不僅僅是因為CAP理論，還因為今天高擴充套件性的NoSQL資料庫和訊息傳遞中介軟體並不支援這一需求。最終你不得不使用一個最終一致性的方法，從而對開發者提出了更高的要求和挑戰。

　　測試一個基於微服務架構的應用也是很複雜的任務。比如，採用流行的Spring Boot架構，對一個單體式web應用，測試它的REST API，是很容易的事情。反過來，同樣的服務測試需要啟動和它有關的所有服務（至少需要這些服務的stubs）。再重申一次，不能低估了採用微服務架構帶來的複雜性。

　　另外一個挑戰在於，微服務架構模式應用的改變將會波及多個服務。比如，假設你在完成一個案例，需要修改服務A、B、C，而A依賴B，B依賴C。在單體式應用中，你只需要改變相關模組，整合變化，部署就好了。對比之下，微服務架構模式就需要考慮相關改變對不同服務的影響。比如，你需要更新服務C，然後是B，最後才是A，幸運的是，許多改變一般隻影響一個服務，而需要協調多服務的改變很少。

　　部署一個微服務應用也很複雜，一個分散式應用只需要簡單在複雜均衡器後面部署各自的伺服器就好了。每個應用例項是需要配置諸如資料庫和訊息中介軟體等基礎服務。相對比，一個微服務應用一般由大批服務構成。例如，根據Adrian Cockcroft，Hailo有160個不同服務構成，NetFlix有大約600個服務。每個服務都有多個例項。這就造成許多需要配置、部署、擴充套件和監控的部分，除此之外，你還需要完成一個服務發現機制（後續文章中發表），以用來發現與它通訊服務的地址（包括伺服器地址和埠）。傳統的解決問題辦法不能用於解決這麼複雜的問題。接續而來，成功部署一個微服務應用需要開發者有足夠的控制部署方法，並高度自動化。

　　一種自動化方法是使用PaaS服務，例如Cloud Foundry。PaaS給開發者提供一個部署和管理微服務的簡單方法，它把所有這些問題都打包內建解決了。同時，配置PaaS的系統和網路專家可以採用最佳實踐和策略來簡化這些問題。另外一個自動部署微服務應用的方法是開發對於你來說最基礎的PaaS系統。一個典型的開始點是使用一個叢集化方案，比如配合Docker使用Mesos或者Kubernetes。後面的系列我們會看看如何基於軟體部署方法例如NGINX，可以方便的在微服務層面提供快取、許可權控制、API統計和監控。

　　總結

　　構建複雜的應用真的是非常困難。單體式的架構更適合輕量級的簡單應用。如果你用它來開發複雜應用，那真的會很糟糕。微服務架構模式可以用來構建複雜應用，當然，這種架構模型也有自己的缺點和挑戰。

　　在後續的部落格中，我會深入探索微服務架構模式，並討論諸如服務發現、服務部署選擇和如何分解一個分散式應用為多個服務的策略。

　　待續。。。