最近兩年，微服務架構盛行，出現了一些優秀的微服務框架，如SpringCloud等。近來工作需要，接觸了部分微服務的內容，和之前的傳統開發模式不相同，進行對比，有所感。

    首先是看一張簡單總結畫的圖：

一.單體應用

    單體應用 - 一個war檔案包含所有功能的應用程式包。這種很常見，在電信CRM開發團隊待過一段時間，像CRM系統，包含複雜的業務邏輯/自服務介面/定時任務/集團介面等等，都在一個war檔案裡面。每次釋出，都是版本管理員拿到一個大war包，上傳到WebSphere，再往幾十臺伺服器上推送。好處是All In One，部署測試比較容易，版本管控比較簡單。但是隨著時間的推移，越來越多的需求被加到war包中，慢慢地，單體應用變得越來越臃腫，上線後執行五六年，war包就有幾百兆，可維護性和靈活性低。參考了《SpringCloud與Docker微服務架構實戰》一書，結合實際工作專案經歷，下面列出單體應用存在的問題：

    1.複雜性高

    拿上面的CRM系統舉例，首先本身包含複雜的業務邏輯，電信的三戶模型，各種套餐受理規則，服務介面，定時任務，都在一個專案裡面。導致的問題是模組之間變得強耦合，邊界模糊，依賴關係不清晰，程式碼質量參差不齊，最後使得專案變得十分複雜。而且容易有Bug的隱患，如果測試錯過一個問題點，上線後可能產生生產故障，影響業務辦理。

    2.技術債務

    “為了短期的利益，而做了欠考慮的決定所導致的後果。” 隨著時間的推移，需求頻繁的變更以及開發人員的更迭，會慢慢形成應用程式的技術債務。作為一個開發人員，也確實做過這樣的事情：為了趕緊上線，少做一些測試，簡單測試沒問題後就匆忙上線。上線之後鐵定出問題，因為“出來混,遲早要還的”。出問題後，就會有緊急補丁，這個補丁就是之前的欠下的“債務”。此外，緊急補丁多了後，會影響系統的原有設計，可能導致後面開發的時候很難修改。

    3.部署頻率低

    單體應用一般是全量部署，每次需求和功能的上線都是重新部署釋出整個應用。相比增量釋出，全量部署的方式耗時長，影響範圍大同時風險高。在此方式下，部署頻率不太可能高。上面舉例的CRM系統基本是一個月一個版本。同時部署頻率低又會導致存在的Bug可能不會很及時的修復，系統的迭代變更可能跟不上快速變化的市場和需求的變更。

    4.可靠性差

    單體應用，當出現稍微大一點的Bug時候，如記憶體溢位，死迴圈，可能導致整個應用崩潰。可能客戶正在提交訂單，突然當前請求所在的伺服器崩潰掉，介面得不到響應，影響客戶體驗。另外，假如通過F5或者負載均衡通過IP或者其他方式負載的情況下，很有可能出現，即使重新登入，客戶的請求最後還是會被路由到宕掉的伺服器上面，導致業務不能受理。

    5.擴充套件能力受限

    單體應用只能作為一個整體擴充套件，要麼是增加單臺伺服器的記憶體，要麼是增加伺服器的數量。所有的模組部署在一起，不能根據業務模組進行伸縮。這樣可能會造成不必要的資源浪費。

    6.技術創新難

    單體應用往往使用統一的技術平臺或方案解決所有的問題。也就是說，對於開發人員來說，專案的技術選型和開發套路都已經規定好了，圈定在一個範圍內。每個成員都必須使用相同的開發語言和框架，要想引入新框架或新技術會非常困難。如一個系統使用的是SSH的有一百多萬行程式碼的單體應用，如果想換成SpringMVC或者SpringBoot，這種切換的成本是很高的。

二.微服務

    什麼是微服務？2014年，Martin Fowler與James Lewis共同提出了微服務的概念 - 以開發一組小型服務的方式來開發一個獨立的應用系統，每個服務都以一個獨立程序的方式執行，每個服務與其他服務使用輕量級(通常是HTTP API)的通訊機制。這些服務是圍繞業務功能構建的，可以通過全自動部署機制獨立部署，同時服務會使用最小規模的集中管理(例如Docker)能力，也可以採用不同的程式語言和資料庫。

    微服務與單體應用相比，能夠更好的滿足網際網路時代業務快速變化的需要。下面對比單體應用，列出微服務的部分特性：

    1.業務拆分

    業務拆分，即把一個複雜龐大的業務系統劃分為若干模組，拆分出各種服務和中心。《企業IT架構轉型之道》的介紹，阿里巴巴中臺戰略中，把複雜的業務拆分出了幾大中心：使用者中心，商品中心，交易中心，評價中心等等。不同的中心由不同的團隊負責開發維護各自的服務，服務之間的互動定義好，內部想要怎樣變更都不會影響外部的使用。前面舉例的CRM系統在去年也完成了服務拆分改造，由一個單體應用拆分出了使用者中心，訂單中心等。

    2.持續試錯

    聽過一個原則 - 演進式設計原則。在系統開發的過程中，可能會遇到各種問題，加上頻繁變更的業務需求。在微服務的架構下，可以採用快速迭代的方式進行架構的演進，在這個過程中可能會出現各種問題，但在微服務的架構下，即使是某個服務遇到問題，發版修復，也不會導致這個應用系統不可用。騰訊有一條重要發展原則就是“小步快跑”。

    3.持續整合部署

    相比之前的單體應用，在微服務的架構在，可能被拆分出來幾個模組，如前端模組，系統模組，閘道器模組，許可權模組等。不同的模組由不同的團隊開發負責，模組化後，更利於使用一些持續整合的工具來簡化和提高我們的系統開發運維效率。常用的有Jenkins，關聯到Gitlab，可以實現測試人員一鍵部署，及時測試和釋出修復問題。

    4.分散式高可用

    在微服務架構之前，單體應用往往是中心化的，幾十臺伺服器應用通過集中的Oracle資料庫來協同工作。中心化模式存在一個隱患，當位於中心的資料庫伺服器宕機的時候，整片應用伺服器都將不可用，後果將是不可想象的。還有另外一種匯流排ESB模式也存在這種隱患。在微服務架構下，不同模組服務都是獨立執行在不同的伺服器上，使用的資料庫是分散式資料庫，以前的一個數據庫，現在可能按照服務劃分被拆分成多個分散式資料庫，每個資料庫還能有主備。此外，加上分散式快取，分散式訊息佇列等中介軟體的使用，大大提高了應用系統的可用性。

    5.獨立程序

    前面講到單體應用的擴充套件性受限，相反，在微服務下，獨立程序的方式靈活性很高。拿現在專案中使用到的SpringCloud舉例，每個服務模組都是單獨的程序(jar包)，有系統服務，閘道器服務，訂單服務，假如在某一時刻，發現某個服務的請求比較大，可以通過臨時追加程序數量例項，註冊到服務中心，分散請求。這種方式下，相比之前整體擴充套件，程序級別的伸縮對於伺服器系統資源能更好的利用。

    6.結合容器技術

    不像單體應用很難實現創新，在微服務的架構下，團隊完全可以結合不同成員的優勢，不限開發語言和資料庫，在找到更優的解決方案時，可以使用容器部署的方式來遮蔽這種差異，這種方式需要定義約定好不同模組服務直接的互動方式。通過容器封裝環境，開發人員可以直接將所有軟體和依賴直接封裝到容器中，打包成映象，生產環境直接部署映象，通過容器實現開發測試生產環境的一致。通過容器排程平臺管理容器，資源利用綠更高。

    想到的就是這些，有點晚了，準備休息。有不對的地方，還望大家指正。