1. 分布式系統架構有哪些優勢？
1）增大系統容量
2）加強系統可用性
3）因為模塊化，所以系統模塊重用度更高
4）因為軟件模塊化被拆分，開發和發布速度可以並發而變得更快
5）系統擴展性更高
6）團隊協作流程也會得到改善
2. 分布式系統架構有哪些劣勢？
1）架構設計變得復雜（尤其是其中的分布式事務）
2）部署單個服務會比較快，但如果一次部署多個服務，流程會變得復雜
3）系統的吞吐量會變大，但響應時間會邊長。
4）運維復雜度會因為服務變多而變得復雜
5）架構復雜導致學習曲線變大
6）測試和查錯的復雜度增大
7）技術多元化，這會帶來維護和運維的復雜度
8）管理分布式系統中的服務和調度變得困難和復雜
3. 分布式系統中有哪些需要注意的問題？
1）異構系統的不標准問題：軟件、應用、通訊協議、數據格式、開發和運維的過程。需要統一標准。
2）服務架構中的系統依賴問題（業務隔離；數據庫隔離，不同業務有自己不同的數據庫；主要的業務調用路徑圖）
a. 如果非關鍵業務被關鍵業務所依賴，會導致非關鍵衣物變成一個關鍵業務
b. 服務依賴鏈中，出現“木桶短板效應” -- 整個SLA（Service Level Agreement，服務級別協議是指提供服務的企業與客戶之間就服務的品質、水准、性能等方面所達成的雙方共同認可的協議或契約）由最差的那個服務決定。
3）故障發生的概率更大
a. 出現故障不可怕，故障恢復時間過長才可怕（怎么避免？）
b. 出現故障不可怕，故障影響面過大才可怕（怎么避免？）
需要我們在設計或運維系統時都要為這些故障考慮，即所謂 Design for Failure。在設計時就要考慮如何減輕故障。如果無法避免，也要使用自動化的方式恢復故障，減少故障影響面。
4）多層架構的運維復雜度更大
a. 任何一層的問題都會導致整體的問題
b. 沒有統一的視圖和管理，導致運維被割裂開來，造成更大的復雜度
分工不是問題，問題是分工后的協作是否統一和規范。
4. 使用分布式系統的主要目的是什么？
1）大流量處理：通過集群技術把大規模並發請求的負載分散到不同的機器上。
2）關鍵業務保護：提高后來服務的可用性，把故障隔離起來阻止多米諾骨牌效應（雪崩效應）。如果流量過大需要，需要對業務降級，以保護關鍵業務流轉。
5. 怎樣提高系統架構的性能？
1）加緩沖：緩存系統（緩存分區，緩存更新，緩存命中）
2）負載均衡：網關系統（負載均衡，服務路由，服務發現）
3）異步調用：異步系統（消息隊列，消息持久，異步事務）
4）數據鏡像：數據鏡像（數據同步，讀寫分離，數據一致性）
5）數據分區：數據分區（分區策略，數據訪問層，數據一致性）
6. 怎樣提高架構的穩定性？
1）服務拆分：服務治理，服務調用，服務依賴，服務隔離
2）服務冗余：服務調度，彈性伸縮，故障遷移，服務發現
3）限流降級：異步隊列，降級控制，服務熔斷
4）高可用架構：多租戶系統，災備多活，高可用服務
5）高可用運維：運維系統，全棧監控，Devops，自動化運維
7. 分布式服務有哪些關鍵技術？
1）服務治理
2）架構軟件管理
3）DevOps
4）自動化運維
5）資源調度管理
6）整體架構監控
7）流量控制
8. 分布式系統的綱
1）全棧系統監控
2）服務/資源調度
3）流量調度
4）狀態/數據調度
5）開發和運維的自動化
9. 全棧監控主要監控哪些方面？
1）基礎層：監控主機和底層資源。如：CPU、內存、網絡吞吐、硬盤I/O、硬盤使用等
2）中間層：就是中間件的監控。如：Nginx、Redis、ActiveMQ、Kafka、MySQL、Tomcat 等
3）應用層：監控應用層的使用。如：HTTP訪問的吞吐量、響應時間、返回碼，調用鏈路分析、性能瓶頸，還包括用戶端的監控。
10. 監控系統有哪些常見問題？
1）監控數據是隔離開來的
2）監控的數據項太多
11. 監控系統的主要應用場景有哪些？
1）體檢：
a. 容量管理：提供一個全局的運行時數據展示，可以讓工程師團隊知道是否需要增加機器或其他資源。
b. 性能管理：可以通過查看大盤，找到系統瓶頸，並有針對性的優化系統和響應代碼。
2）急診：
a. 定位問題
b. 性能分析：
12. 一個好的監控系統應該實現哪些功能？
1）服務調用鏈跟蹤：
2）服務調用時長分布：使用 Zipkin，可以看到一個服務調用鏈上的時間分布，這樣有助於我們知道最耗時的服務是什么。下圖是 Zipkin 的服務調用時間分布。
3）服務的TOP N視圖：所謂 TOP N 視圖就是一個系統請求的排名情況。一般來說，這個排名會有三種排名的方法：a）按調用量排名，b) 按請求最耗時排名，c）按熱點排名（一個時間段內的請求次數的響應時間和）。
4）數據庫操作關聯：
5）服務資源跟蹤：我們的服務可能運行在物理機上，也可能運行在虛擬機里，還可能運行在一個 Docker 的容器里，Docker 容器又運行在物理機或是虛擬機上。我們需要把服務運行的機器節點上的數據（如 CPU、MEM、I/O、DISK、NETWORK）關聯起來。
13. 我們需要通過監控系統，達成什么樣的目標？
1）當一台機器掛掉是因為 CPU 或 I/O 過高的時候，我們馬上可以知道其會影響到哪些對外服務的 API。
2）當一個服務響應過慢的時候，我們馬上能關聯出來是否在做 Java GC，或是其所在的計算結點上是否有資源不足的情況，或是依賴的服務是否出現了問題。
3）當發現一個 SQL 操作過慢的時候，我們能馬上知道其會影響哪個對外服務的 API。
4）當發現一個消息隊列擁塞的時候，我們能馬上知道其會影響哪些對外服務的 API。
14. 關於服務調度，我們有哪些能做的？
1）服務關鍵程度和服務的依賴關系：
2）服務狀態和生命周期的管理：整個架構中有多少種服務？這些服務的版本是什么樣的？每個服務的實例數有多少個，它們的狀態是什么樣的?每個服務的狀態是什么樣的？是在部署中，運行中，故障中，升級中，還是在回滾中，伸縮中，或者是在下線中……
3）整個架構的版本管理
4）資源和服務調度：
a. 服務狀態的維持和擬合
b. 服務的彈性伸縮和故障遷移
c. 服務工作流和編排
15. 流量調度應該具有哪些功能？
1）依據系統運行情況，自動地進行流量調度，在無需人工干預的情況下，提升整個系統的穩定性。
2）讓系統應對爆品等突發事件時，在彈性計算擴縮容的較長時間窗口內或底層資源消耗殆盡的情況下，保護系統平穩運行。
3）服務流控：服務發現、服務路由、服務降級、服務熔斷、服務保護等。
4）流量控制：負載均衡、流量分配、流量控制、異地災備（多活）等。
5）流量管理：協議轉換、請求校驗、數據緩存、數據計算等。
16. 流量與數據調度：
1）狀態數據調度：一般來說，我們會通過“轉移問題”的方法來讓服務變成“無狀態的服務”。也就是說，會把這些有狀態的東西存儲到第三方服務上，比如 Redis、MySQL、ZooKeeper，或是 NFS、Ceph 的文件系統中。
2）分布式事務一致性的問題：
a. Master-Slave 方案。
b. Master-Master 方案。
c. 兩階段和三階段提交方案。
d. Paxos 方案。
現在，很多公司的分布式系統事務基本上都是兩階段提交的變種。比如：阿里推出的 TCC–Try–Confirm–Cancel，或是我在亞馬遜見到的 Plan–Reserve–Confirm 的方式，等等。凡是通過業務補償，或是在業務應用層上做的分布式事務的玩法，基本上都是兩階段提交，或是兩階段提交的變種。
3）數據結點的分布式方案
17. 狀態數據調度小結：
1）對於應用層上的分布式事務一致性，只有兩階段提交這樣的方式。
2）底層存儲可以解決這個問題的方式是通過一些像 Paxos、Raft 或是 NWR 這樣的算法和模型來解決。
3）狀態數據調度應該是由分布式存儲系統來解決的，這樣會更為完美。但是因為數據存儲的 Scheme 太多，所以，導致我們有各式各樣的分布式存儲系統，有文件對象的，有關系型數據庫的，有 NoSQL 的，有時序數據的，有搜索數據的，有隊列的……