1. 分布式架構解決什麼問題
主要是兩個：
- 大流量的處理通過集群技術將大規模並發請求負載均衡到不同的機器上。
- 關鍵業務的保護提高後台服務的可用性，把故障隔離起來，阻止多米諾骨牌效應，如果流量過大，需要對業務降級。已保證關鍵業務的流轉。
說白了就是干兩件事、一是提高整體架構的吞吐量，二是提高系統的穩定性，讓系統的可用性更高。
2. 如何提高架構性能
- 緩存系統
- 異步調用
- 負載均衡
- 數據分區
- 數據鏡像
3. 如何提高架構穩定性
- 服務拆分
- 服務冗餘
- 限流降級
- 高可用架構
- 高可用運維
4. 分布式系統的核心
img
5. 全棧監控
img
- 基礎層：監控主機和底層資源。比如：CPU、內存、網絡吞吐、硬碟I/O、硬碟使用等。
- 中間層：就是中間件層的監控。比如：Nginx、Reids、ActiveMQ、Kafka、MySQL、Tomcat等。
- 應用層：監控應用層的使用。比如：HTTP訪問吞吐量、響應時間、返回碼、調用鏈路分析、性能瓶頸、還包括用戶端的監控。
6. 服務治理
- 梳理服務之間的依賴關係 （zipkin）
- 服務狀態和服務聲明周期管理 （服務發現）
- 整體架構版本管理 （類似於Springboot和Spring clound之間的版本對應）
- 資源/服務調度
- 服務狀態的維持和擬合（一種不預期的變化會維持服務狀態，例如服務掛掉。預期的變化會擬合服務狀態、例如服務啟動）
- 服務的彈性伸縮和故障遷移 （docker、kubernetes）
- 服務工作流和編排
7. 總結
7.1 構建分布式系統面臨的問題
- 分布式系統的硬體故障發生率高。故障發生是常態，需要儘可能地將運維流程自動化。
- 需要良好的設計服務，避免某服務的單點故障對依賴它的其他服務造成大面積影響。
- 為了容量的可伸縮性，服務的拆分、自治和無狀態變得更加重要，可能需要對老的軟體邏輯做大的修改。
- 老的服務可能是異構的，此時需要讓他們使用標準的協議，以便可以被調度、編排、且互相之間可以通信。
- 服務軟體故障的處理也變得複雜，需要優化的流程，以加快故障的恢復。
- 為了管理各個服務的容量，讓分布式系統發揮出最佳性能，需要有流量調度技術。
- 分布式存儲會讓事務處理變得複雜；在事務遇到故障無法被自動恢復的情況下，手動恢複流程也會變得複雜。
- 測試和查錯的複雜度增大。
- 系統的吞吐量會變大，但響應時間會變長。
7.2 了解一些解決方案
- 需要有完善的監控系統，以便對服務運行狀態有全面的了解。
- 設計服務時要分析其依賴鏈；當非關鍵服務故障時，其他服務要自動降級功能，避免調用該服務。
- 重構老的軟體，使其能被服務化；可以參考 SOA 和微服務的設計方式，目標是微服務化；使用 Docker 和 Kubernetes 來調度服務。
- 為老的服務編寫接口邏輯來使用標準協議，或在必要時重構老的服務以使得它們有這些功能。
- 自動構建服務的依賴地圖，並引入好的處理流程，讓團隊能以最快速度定位和恢復故障，詳見《故障處理最佳實踐：應對故障》一文。
- 使用一個 API Gateway，它具備服務流向控制、流量控制和管理的功能。
- 事務處理建議在存儲層實現；根據業務需求，或者降級使用更簡單、吞吐量更大的最終一致性方案，或者通過二階段提交、Paxos、Raft、NWR 等方案之一，使用吞吐量小的強一致性方案。
- 通過更真實地模擬生產環境，乃至在生產環境中做灰度發布，從而增加測試強度；同時做充分的單元測試和集成測試以發現和消除缺陷；最後，在服務故障發生時，相關的多個團隊同時上線自查服務狀態，以最快地定位故障原因。
- 通過異步調用來減少對短響應時間的依賴；對關鍵服務提供專屬硬體資源，並優化軟體邏輯以縮短響應時間。