最近兩年，微服務架構盛行，出現了一些優秀的微服務框架，如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.結合容器技術
不像單體應用很難實現創新，在微服務的架構下，團隊完全可以結合不同成員的優勢，不限開發語言和數據庫，在找到更優的解決方案時，可以使用容器部署的方式來屏蔽這種差異，這種方式需要定義約定好不同模塊服務直接的交互方式。通過容器封裝環境，開發人員可以直接將所有軟件和依賴直接封裝到容器中，打包成鏡像，生產環境直接部署鏡像，通過容器實現開發測試生產環境的一致。通過容器調度平臺管理容器，資源利用率更高。
想到的就是這些，有點晚了，準備休息。有不對的地方，還望大家指正。