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

摘要: 微處理架構——處理復瑣事物 　　許多公司，好比Amazon、eBay和NetFlix，經過採用微處理結構模式解決了上述問題。其思路不是開發一個巨大的單體式的應用，而是將應用分解爲小的、互相鏈接的微服務。

微服務正在博客、社交媒體討論組和會議演講中得到愈來愈多的關注，在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