分佈式系統與架構

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 的，有時序數據的，有搜索數據的，有隊列的……