1. 單體架構
一個歸檔包（例如war格式）包含所有功能的應用程序，通常稱為單體應用。
> 復雜性高：模塊多，模塊的邊界模糊，依賴關系不清楚，代碼質量參差不齊。
> 技術債務：隨着時間推移、需求變更和人員更迭，逐漸形成應用程序的技術債務，越積越多。“不壞不修”，因為其他模塊可能會以意料之外的方式使用你想修改的代碼。
> 部署頻率低：隨着代碼的增多，構建和部署的時間也會增加。在單體應用中，每次功能的變工或缺陷的修復都會導致重新部署整個應用。
> 可靠性差：某個應用Bug，例如死循環、OOM等，都可能導致整個應用的崩潰。
> 擴展能力受限：單體應用只能作為一個整體進行擴展，無法更加業務模塊的需求進行伸縮。例如，有的模塊是計算密集型，需要強勁的CPU；有的模塊則是IO密集型，需要更大的內存。由於這些模塊部署在一起，不得不在硬件的選擇上作出妥協。
> 阻礙技術創新：單體應用使用統一的技術平台或方案解決所有問題，團隊成員必須使用相同的開發語言和框架，想引入新框架和新技術平台會非常困難。比如將Struts2構建的大型單體應用改造為Spring MVC，成本是非常高的。
2. 微服務
微服務架構風格是一種將一個單一應用程序開發為一組小型服務的方法，每個服務運行在自己的進程中，服務間通信采用輕量級通信機制（通常為HTTP資源API）。這些服務圍繞業務能力構建並且可通過全自動部署機制獨立部署。這些服務公用一個最小型的集中式的管理，服務可用不同的語言開發，使用不同的數據存儲技術。
特征：
- 每個微服務可獨立運行在自己的進程里。
- 每個服務為獨立的業務開發，一個微服務只關注某個特定的功能，例如訂單管理、用戶管理等。
- 微服務之間通過一些輕量的通信機制進行通信，例如通過RESTful API進行調用。
- 可以使用不同的語言與數據存儲技術
- 全自動的部署機制
優點：
- 易於開發和維護：一個微服務只關注一個特定的業務功能，因此業務清晰、代碼量較少。
- 單個微服務啟動較快：單個微服務代碼量較少，因此啟動會比較快。
- 局部修改容易部署：對某個微服務進行修改，只需要重新部署這個服務即可。
- 技術棧不受限：可結合項目業務及團隊的特點，合理地選擇技術棧。例如某些服務可使用關系型數據庫MySQL；某些服務有圖形計算的需求，可使用Neo4j；甚至可根據需要，部分微服務用Java開發，部分用Node.js開發。
- 按需伸縮：可根據需求，實現細粒度的擴展。例如，系統中的某個微服務遇到了瓶頸，可以結合這個微服務的業務特點，增加內存、升級CPU或增加節點。
不足：
- 運維要求較高：更多的服務意味着更多的運維投入。在微服務中，需要保證幾十甚至幾百個服務的正常運行與協作，這給運維帶來了很大的挑戰。
- 分布式固有的復雜性：使用微服務構建的是分布式系統。對於一個分布式系統，系統容錯、網絡延遲、分布式事務等都會帶來巨大的挑戰。
- 接口調整成本高：微服務之間通過接口進行通信。如果修改某個微服務的API，可能所有使用了該接口的微服務都需要做調整。
- 重復勞動：很多微服務可能都會使用到相同的功能，而這個功能並沒有達到分解為一個微服務的程度，這個時候，各個微服務都會開發這一功能，從而導致代碼重復。
3. 微服務設計原則
- 單一職責原則
單一職責原則指的是一個單一（類、方法或服務等）只應關注整個系統功能中單獨、有界限的一部分。
單一職責原則是SOLID原則之一。
- 服務自治原則
服務自治是指每個微服務應具備獨立的業務能力、依賴與運行環境。服務之間高度解耦。每個微服務從開發、測試、構建、部署，都應當可以獨立運行，而不依賴其他的服務。
- 輕量級通信機制
微服務之間應該通過輕量級的通信機制進行交互。輕量級的通信機制應具備兩點：一、體量較輕；二、跨語言，跨平台的。
微服務架構中，常用的協議有REST、AMQP、STOMP、MQTT等。
- 微服務粒度
微服務的粒度是難點，也是爭論的焦點。應當使用合理的粒度划分微服務，而不是一味地把服務做小。代碼量的多少不能作為微服務划分的依據，不同的微服務本身的業務復雜度不同，代碼量也不同。
在微服務設計節點，就應確認其邊界。微服務之間應相對獨立並保持松耦合。
個人認為，領域驅動設計（Domain Driven Design，簡稱DDD）中的“界限上下文（Bounded Context）”可作為划分微服務邊界、確定微服務粒度的重要依據。
4.參考
周立 --- 《Spring Cloud與Docker微服務架構與實戰》