一、前言
”微服務“架構是近期以來軟件應用領域最熱門的概念。那什麼是”微服務“？”微服務“又跟我們傳統的架構有什麼區別呢？”微服務“能用來做什麼？
二、什麼是”微服務“
”微服務“是一種架構風格，就是把一個大型的(複雜的)單個應用程序和服務拆分爲一個乃至多個的微服務。系統中的各個微服務可被獨立部署，各個微服務之間是鬆耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。每個任務代表着一個小的業務能力。”微服務“一定要區別於系統，”微服務“是服務於一個或者一組相對較小且獨立的功能單元，是用戶可以感知的最小功能集。每一個功能元素最終都是一個可獨立替換和獨立升級的軟件單元。
其實，”微服務“的本質就是將複雜的服務拆分成單獨的個體，個體之間通過統一的HTTP協議相互溝通的一個過程。
如果把計算機比作一個高效的車輛交通網絡的話，微服務就是將每一臺車輛（服務）當作一個單獨的個體，車輛（服務）和車輛（服務）之間相互聯網溝通，最終達到一個服務目標的整體。
三、”微服務“的由來
”微服務“最早由Martin Fowler與James Lewis於2014年共同提出，微服務架構風格是一種使用一套小服務來開發單個應用的方式途徑，每個服務運行在自己的進程中，並使用輕量級機制通信，通常是HTTP API，這些服務基於業務能力構建，並能夠通過自動化部署機制來獨立部署，這些服務使用不同的編程語言實現，以及不同數據存儲技術，並保持最低限度的集中式管理。
四、”微服務“能用來做什麼
”微服務“並不是一個突然興起的概念，其本質上還是在傳統服務架構上進行演進的一個過程。微服務和其他架構不同的地方在於在過去的軟件架構中，服務往往作爲一個整體來爲統一的目標提供業務上的支持，但是微服務不同，微服務是通過API模式進行，所以微服務更加偏近於編程的後端部分。而且微服務可以將業務進行拆分，這樣在設計很多細節的問題的時候，服務和服務之間的耦合度會非常的小，每個服務都能實現自動測試，自動治理，自動運維。使得計算機後端的業務能力得到飛速的提升。
但是微服務不是解決一切問題的“銀彈”，在計算機的技術裏面，沒有什麼技術可以解決一切的問題，微服務也是這樣。任何問題都要辯證的去看待和實現，微服務也是這樣。所以靈活運用，不斷創新這纔是計算機任何技術真正的內部含義。
五、傳統系統架構與微服務架構的區別
【傳統的系統架構】是單一架構模式。這種架構模式就是把應用整體打包部署，具體的樣式依賴本身應用採用的語言，如果採用java語言，自然你會打包成war包，部署在Tomcat或者Jetty這樣的應用服務器上，如果你使用spring boot還可以打包成jar包部署。其他還有Rails和Node.js應用以目錄層次的形式打包。
【微服務架構】則是將單個的整體應用程序分割成更小的項目關聯的獨立的服務。一個服務通常實現一組獨立的特性或功能，包含自己的業務邏輯和適配器。各個微服務之間的關聯通過暴露api來實現。這些獨立的微服務不需要部署在同一個虛擬機，同一個系統和同一個應用服務器中。
六、傳統架構--->微服務架構
單一架構模式在項目初期很小的時候開發方便，測試方便，部署方便，運行良好。可是當應用隨着時間的推進，加入的功能越來越多，最終會變得巨大，一個項目中很有可能數百萬行的代碼，互相之間繁瑣的jar包。
1、 不再適用敏捷開發，過於複雜，任何開發者都不能夠完全理解，修復漏洞和實現新功能變得困難和耗時。
2、 規模越大，啓動時間越長，自然會拖慢開發進度，一個小功能的修改部署起來變得困難，必須重新部署整個應用。
3、 系統的不同的模塊的需要不同的特定的虛擬機環境時，由於是整體應用，那麼只能折中選擇。
4、 任意模塊的漏洞或者錯誤都會影響這個應用，降低系統的可靠性
5、 還有一個如果想整體應用採用新的技術，新的框架或者語言，那是不可能的。
單體架構在規模比較小的情況下工作情況良好，但是隨着系統規模的擴大，它暴露出來的問題也越來越多，主要有以下幾點：
1.複雜性逐漸變高
比如有的項目有幾十萬行代碼，各個模塊之間區別比較模糊，邏輯比較混亂，代碼越多複雜性越高，越難解決遇到的問題。
2.技術債務逐漸上升
公司的人員流動是再正常不過的事情，有的員工在離職之前，疏於代碼質量的自我管束，導致留下來很多坑，由於單體項目代碼量龐大的驚人，留下的坑很難被發覺，這就給新來的員工帶來很大的煩惱，人員流動越大所留下的坑越多，也就是所謂的技術債務越來越多。
3.部署速度逐漸變慢
這個就很好理解了，單體架構模塊非常多，代碼量非常龐大，導致部署項目所花費的時間越來越多，曾經有的項目啓動就要一二十分鐘，這是多麼恐怖的事情啊，啓動幾次項目一天的時間就過去了，留給開發者開發的時間就非常少了。
4.阻礙技術創新
比如以前的某個項目使用struts2寫的，由於各個模塊之間有着千絲萬縷的聯繫，代碼量大，邏輯不夠清楚，如果現在想用spring mvc來重構這個項目將是非常困難的，付出的成本將非常大，所以更多的時候公司不得不硬着頭皮繼續使用老的struts架構，這就阻礙了技術的創新。
5.無法按需伸縮
比如說電影模塊是CPU密集型的模塊，而訂單模塊是IO密集型的模塊，假如我們要提升訂單模塊的性能，比如加大內存、增加硬盤，但是由於所有的模塊都在一個架構下，因此我們在擴展訂單模塊的性能時不得不考慮其它模塊的因素，因爲我們不能因爲擴展某個模塊的性能而損害其它模塊的性能，從而無法按需進行伸縮。
如果採用微服務架構模式，則可以解決單一架構模式帶來的系統複雜性。主要包括以下幾個好處：
1、 由於每個服務都是獨立並且微小的，由單獨的團隊負責，仍然可以採用敏捷開發模式，自由的選擇合適的技術，甚至可以重寫老服務，當然都要遵守統一的API約 定。
2、 每一個微服務都是獨立部署的，可以進行快速迭代部署，根據各自服務需求選擇合適的虛擬機和使用最匹配的服務資源要求的硬件。
3、 整體應用程序被分解成可管理的模塊和服務，單個的服務可以更快的開發、更簡單的理解和維護。
4、 一些需要進行負載均衡的服務可以部署在多個雲虛擬機上，加入NGINX這樣的負載均衡器在多個實例之間分發請求，這樣不需要整個應用進行負載均衡了。
每個後端服務暴露一套REST API，大部分服務調用其他服務提供的API。每個服務都有自己的數據庫模式，而不是共享單個數據庫模式。儘管這會造成某些數據的冗餘，但是對於微服務架構這個獨立數據庫模式是必要的，確保了獨立服務之間的鬆散耦合。
以上介紹的微服務架構模式表面上類似於SOA，兩種架構都包含一組服務。可以認爲微服務架構是不包括Web服務規範（WS-）、企業服務總線（ESB）的SOA。基於微服務的應用傾向於使用更簡單輕量級的協議，比如 REST 而不是 WS-。微服務自己實現類似 ESB 的功能並且拒絕 SOA 的其他部分，比如規範模式的概念。
微服務的缺點：
1、 微服務應用作爲分佈式系統帶來了複雜性。當應用是整體應用程序時，模塊之間調用都在應用之內，即使進行分佈式部署，依然在應用內調用。可是微服務是多個獨立的服務，當進行模塊調用的時候，分佈式將會麻煩。
2、 多個獨立數據庫，事務的實現更具挑戰性。
3、 測試微服務變得複雜，當一個服務依賴另外一個服務時，測試時候需要另外一個服務的支持。
4、 部署基於微服務的應用也很複雜，整體應用程序部署只需要部署在一組相同的服務器上，在這些服務前面加入傳統的負載均衡器即可。獨立服務的不是講變得複雜，需要更高的自動化形式。
【總結】
單體架構所有的模塊全都耦合在一塊，代碼量大，維護困難，微服務每個模塊就相當於一個單獨的項目，代碼量明顯減少，遇到問題也相對來說比較好解決。
單體架構所有的模塊都共用一個數據庫，存儲方式比較單一，微服務每個模塊都可以使用不同的存儲方式（比如有的用redis，有的用mysql等），數據庫也是單個模塊對應自己的數據庫。
單體架構所有的模塊開發所使用的技術一樣，微服務每個模塊都可以使用不同的開發技術，開發模式更靈活。
微服務的決定因素：
小：微服務體積小，2 pizza 團隊。
獨：能夠獨立的部署和運行。
輕：使用輕量級的通信機制和架構。
鬆：爲服務之間是鬆耦合的。
