一、單體結構
1. 什麼是單體架構
一個歸檔包（例如war格式）包含了應用所有功能的應用程序，我們通常稱之爲單體應用。架構單體應用的方法論，我們稱之爲單體應用架構。
2. 單體架構示例圖
3. 單體架構的缺陷
（1）複雜性高。整個項目包含的模塊非常多，模塊的邊界模糊，依賴關係不清晰，代碼質量參差不齊……整個項目非常複雜。每次修改代碼都心驚膽戰，甚至添加一個簡單的功能，或者修改一個BUG都會造成隱含的缺陷。
（2）技術債務。隨着時間推移、需求變更和人員更迭，會逐漸形成應用程序的技術債務，並且越積越多。已使用的系統設計或代碼難以修改，因爲應用程序的其他模塊可能會以意料之外的方式使用它。
（3）部署頻率低。隨着代碼的增加，構建和部署的時間也會增加。而在單體應用中，每次功能的變更或缺陷的修復都會導致我們需要重新部署整個應用。全量部署的方式耗時長、影響範圍大、風險高，這使得單體應用項目上線部署的頻率較低，從而又導致兩次發佈之間會有大量功能變更和缺陷修復，出錯概率較高。
（4）擴展能力受限。單體應用只能作爲一個整體進行擴展，無法結合業務模塊的特點進行伸縮。
（5）阻礙技術創新。單體應用往往使用統一的技術平臺或方案解決所有問題，團隊的每個成員都必須使用相同的開發語言和架構，想要引入新的框架或技術平臺非常困難。
由於單體架構的缺陷日益明顯，所以越來越多的公司採用微服務架構範式解決上面提到的單體架構中的問題。
二、微服務
- 什麼是微服務
2. 微服務架構示例圖
3. 微服務架構的特性
（1）不同於構建單一、龐大的應用，微服務架構將應用拆分爲一套小且互相關聯的服務。每個微服務可獨立運行在自己的進程裏；
（2）系列獨立運行的微服務共同構建起整個系統；
（3）每個服務爲獨立的業務開發，一個微服務只關注某個特定的功能，如訂單管理、用戶管理等；
（4）微服務之間通過一些輕量的通信機制進行通信，如REST API進行調用；
（5）可以使用不同的語言與存儲技術；
（6）全自動的部署機制；
4. 微服務架構的優勢
（1）易於開發和維護。一個微服務只關注一個特定的業務功能，所以它的業務清晰、代碼量較少。開發和維護單個微服務相對比較簡單，整個應用是由若干個微服務構建而成，所以整個應用也會維持在可控狀態；
（2）單個微服務啓動較快。單個微服務代碼量較少，所以啓動會比較快；
（3）局部修改容易部署。單體應用只要有修改，就要重新部署整個應用，微服務解決了這樣的問題。一般來說，對某個微服務進行修改，只需要重新部署這個服務即可；
（4）技術棧不受限。在微服務中，我們可以結合項目業務及團隊的特點，合理地選擇技術棧；
5. 微服務架構的挑戰
（1）運維要求較高。更多的服務意味着更多的運維投入。在單體架構中只需要保證一個應用的正常運行；而在微服務中，需要保證幾十甚至幾百個服務的正常運行與協作，帶來了巨大的挑戰；
（2）分佈式固有的複雜性。使用微服務構建的是分佈式系統。對於一個分佈式系統，系統容錯、網絡延遲、分佈式事務等都帶來了巨大的挑戰；
（3）接口調整成本高。微服務之間通過接口進行通信。如果修改某個微服務的API，可能所有使用了該接口的微服務都需要做調整；
（4）重複勞動。很多服務可能都會使用到相同的功能。而這個功能並沒有達到分解爲一個微服務的程度，這個時候，可能各個服務都會開發這一功能，導致代碼重複。
微服務是一種架構風格，一個大型複雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是鬆耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。在所有情況下，每個任務代表着一個小的業務能力。
可以在“自己的程序”中運行，並通過“輕量級設備與HTTP型API進行溝通”。關鍵在於該服務可以在自己的程序中運行。通過這一點我們就可以將服務公開與微服務架構（在現有系統中分佈一個API）區分開來。在服務公開中，許多服務都可以被內部獨立進程所限制。如果其中任何一個服務需要增加某種功能，那麼就必須縮小進程範圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體進程。
三、對比
SOA VS 微服務
