一、單體架構存在的問題
缺點：
1、難以維護：當單體應用業務不斷迭代后代碼量非常臃腫，模整個項目非常復雜，每次更改代碼都可能帶來新的bug；
2、部署項目麻煩：龐大之后項目部署效率低，每次升級都需要全部構建打包部署；
3、擴展能力受限：集群只能復制整個系統，即使是某個模塊壓力很大，無法根據業務模塊需要進行伸縮，計算密集型和IO密集型只能部署在一起，硬件成本加大；
4、技術選型受限：只能采用同一種語言，很難根據不同業務需求開發不同的模塊；
綜上，隨着業務需求的發展，功能的不斷增加，單體架構很難滿足互聯網時代業務快速變化的需要，為了解決這些問題，所以微服務架構開始變得流行了。
二、微服務架構
什么是微服務
國外架構師Martin Fowler在他的博客中這樣描述微服務：
https://martinfowler.com/microservices/
微服務架構的特點：
1、每個小型服務都跑在獨立的進程中；
2、可通過自動部署機制進行獨立部署；
3、服務是松散耦合的，服務被拆分后，服務之間沒有很強的依賴關系；
4、服務之間采用輕量級通信(通常有文本協議：http+json數據格式，更輕的二進制協議：grpc+protocol buffer)；
微服務架構的優點：
1、易於開發和維護：一個服務只會關注一個特定的業務，業務依賴減少，代碼量較少；
2、部署容易：某個業務的修改只需要重新部署這個服務；
3、擴展性提高：可以根據業務需求進行細粒度擴展，比如某個業務訪問量加大只需要升級這個微服務的服務器性能或者增加新的節點；
4、技術棧比較靈活：可以根據不同業務選用不同的語言或數據庫，比如面對並發比較高的業務可以選用go語言提供服務；
綜上所述，在面對業務變化很大，系統越來越龐大的時候，單體架構表現的全是缺點，而微服務都是優點。
微服務架構帶來的問題：
使用微服務構建的是分布式系統，帶來了很多問題，例如跟蹤、測試、部署、分布式事務、服務治理等，增加了開發難度和運維成本
三、微服務架構中重要的組件
API網關
為什么需要API網關：
1、客戶端如果直接請求后端微服務，后端服務是十分松散的，這樣會增加客戶端的調用復雜度，所以需要API網關把后端服務的接口統一起來；
2、API網關的路由轉發功能可以把客戶端對后端服務調用完全解耦，后端服務變化不用調整客戶端；
3、API網關有統一認證、負載均衡、流量限制等這些功能，可以有效的保護后端服務；
4、在面向不同客戶端時，可以增加不同的API網關，而不需要調整微服務；
API網關一般會具備的功能：權限認證、流量控制、路由轉發、負載均衡、熔斷保護、緩存、日志記錄等。
下圖是API網關與后端微服務的工作流程：
下圖是API網關面向不同客戶端的調用：
服務注冊與發現
在微服務架構中，每個服務都有自己的IP、Port信息和上線下線狀態，這就需要一個服務治理中心來管理這些服務。 服務注冊與發現組件就是系統內部的DNS服務，服務調用者通過服務名稱從注冊中心解析到IP和Port再完成服務直接調用。 每個服務一上線就會注冊到服務治理中心，同時服務治理中心也會通過心跳檢查每個服務的健康狀態。
服務注冊與發現組件有很多，例如Euraka、Consul、ZooKeeper、Etcd等。下圖是基於Consul的注冊與發現架構圖：
上面就是注冊與發現的架構圖，從上圖中會發現幾個問題，
1、每次請求都要請求Consul服務器性能並不高，可以在請求時對注冊表做緩存，由定時器定時去拉取注冊表來更新緩存，這樣即解決了性能問題也保證高可用的注冊與發現服務真的不可用也不影響服務之間的調用；
2、由於加了緩存，就會出現緩存更新不及時的情況，這樣就會請求到下線的服務器導致請求失敗，這就需要容錯組件了，當請求到不可用的服務時需要做出超時、失敗轉移、重試等這些策略。
容錯組件
為什么需要容錯組件：
微服務架構的應用系統都是通過網絡進行通信，網絡往往會有不可靠性，所以微服務之間的調用並不是100%可用，而微服務之間難免會存在依賴關系，一旦發生某個服務不可用都有可能引發級聯故障，導致整個應用不可用，這個就是“雪崩效應“”。
為了防止雪崩效應，所以我們必須有一套強大的容錯機制，容錯組件應該包含以下幾點：
1、網絡超時：當網絡請求達到設定的超時時間時，讓資源盡快釋放；
2、熔斷器：當請求異常次數達到設定值時打開熔斷器，讓請求直接返回失敗，這樣有效提高服務的響應效率也能保證別的服務不受影響，當熔斷時間一過自動關閉熔斷器讓服務恢復正常使用；
3、重試機制：在網絡調用中有時會存在部分服務提供者不可用的情況，當第一次請求失敗時再重試時又能恢復正常，這樣保證接口成功率，減少用戶請求，也可以設置重試其他節點服務以實現失敗轉移效果；
4、服務降級：當部分服務不可用時為了不影響用戶正常使用可能會降級返回設定好的結果，以提升用戶體驗；
比較有伸縮性的容錯策略為：網絡超時->熔斷->重試。
具體實現的組件java有Hystrix，.net core有Polly。
熔斷器就像是生活中的保險絲，保護用電安全，下圖是熔斷器的調用過程圖：
統一配置中心
對於傳統的單體應用，通常使用配置文件來保存所有配置，如果有多套環境，可以設定多個配置文件不同環境啟用不同的配置文件，而在微服務架構中，由於服務特別的多，一旦配置發生變化，修改配置是件很麻煩的事情而而且手動修改很容易出現漏改的現象，這就需要集中管理配置。
統一配置中心需要滿足如下需求：
1、系統運行期間可以動態調整而不用停止微服務；
2、配置更新后可以自動更新到各個微服務中去；
配置中心架構圖：
具體實現配置中心可以使用ZooKeeper、Redis、RabbitMQ等。
服務跟蹤與監控
為什么需要服務跟蹤：
服務之間通過網絡進行通信，由於會存在網絡不可靠和網絡延遲等網絡問題，我們的服務調用就會因為網絡問題引發很多異常，為了能跟蹤每個請求，了解請求經過哪些微服務、請求耗費時間、網絡延遲、業務處理時間等指標，那么就能更好的分析系統性能和瓶頸、解決系統問題。
服務跟蹤的實現：
所有請求在進入API網關請求頭就帶上一個traceid，用來標識請求並記錄請求開始處理時間和轉發時間等，在服務調用之間也會帶上traceid並記錄所有的請求時間和信息，這樣所有經過的服務都會記錄到到請求，最后通過可視化工具提供服務跟蹤查詢。
服務監控：
一個正在運行的系統少不了監控系統的存在，當我們的服務器出現CPU、內存負荷高或者我們的業務代碼出現警告或異常記錄時，通過采集完整的服務器和微服務運行日志來監控每個微服務的運行狀態，設置一定策略實現提前預警。