第三章 分佈式服務框架的選擇

1.大項目工程且多人維護的弊端
    （1）項目團隊協同成本高，業務響應愈來愈慢
    （2）應用複雜度已超出人的認知負載（向雜亂的電線同樣）
    （3）錯誤難於隔離（一個模塊出錯，整個系統掛掉）
    （4）數據庫連接能力很難擴展
    （5）應用擴展成本高（越堆系統越複雜，後續添加更加困難）
2.中心化與去中心化服務框架對比
    （1）根本訴求不一樣：ESB模式的中心化服務框架是實現異構系統之間的交互；去中心化分佈式服務架構是在於擴展性是首要的。去中心化分佈式服務架構相比中心化服務架構的最重要不一樣在於服務提供者和服務調用者之間在進行服務交互時無需經過任何服務路由中介，避免由於中心點帶來平臺能力難擴展問題。
    （2）服務調用方式的不一樣帶來業務的響應和擴展成本
        ESB方式：服務調用者-->ESB-->服務提供者-->ESB-->服務調用者
        去中心化分佈式服務架構方式：服務調用者-->服務提供者
        兩者對比，前者比後者多兩次網絡會話建立和數據傳輸開銷
        邏輯上看，ESB的全部服務調用都經過服務總線，服務總線的訪問和計算壓力都會很是大。
        企業全部的業務都經過服務總線的方式，服務調用量大，所需的網絡帶寬要求很是高。
    （3）雪崩效應束縛了中心化服務框架的擴展能力
        好比，共有10臺機器，峯值平均每臺負載80%，一旦一臺掛了，那麼剩下9臺會承擔壞掉的，達到88%，再壞一個，接下來就全完蛋，即便斷流重啓也難以短期找到問題根源，致使服務掛掉，隨之用戶流失等損失。
3.簡單介紹HSF分佈式服務框架
    （1）服務提供者：在服務框架中真正提供服務功能實現的應用實例，爲保證高可用，通常是集羣部署。
    （2）服務調用者：服務的消費者。
    （3）地址服務器：給服務提供者和服務調用者提供部署環境中全部配置服務器和Diamond服務器的服務器列表信息。
    （4）配置服務器：主要負責記錄環境內全部服務發佈（服務提供者的IP地址和服務端口信息）和服務訂閱（服務調用者的IP地址和服務端口信息）
    （5）Diamond服務器：一個通用的統一配置管理服務（相似Zookeeper）給應用提供統一的配置設置和推送服務。
         Diamond服務器設置的典型場景
              經過設置白名單的方式設置某些服務或服務中心的方法只能讓特定IP地址的服務器調用。
              經過用戶認證的方式控制服務是否可以調用
              按照不一樣的服務器權重設置服務調用者對多個服務提供者服務節點的訪問；
              設置某些服務的QPS能力上限值，一旦該服務的QPS達到該閾值，則拒絕服務的繼續調用，限流技術。
4.HSF組件
    （1）服務節點對配置服務器列表的獲取
    （2）服務的註冊發佈
    （3）服務的訂閱
    （4）服務規則的推送
    （5）服務交互
    HSF服務框架工做原理如圖：

5.HSF容錯機制，如圖

6.HSF框架的線性擴展支持：當服務壓力過大時，可對服務提供者擴充服務器（分佈式的因此好弄）

7.微服務架構的典型特徵的描述
    （1）分佈式服務組成的系統
    （2）按照業務而不是技術來劃分組織
    （3）作有生命的產品而不是項目
    （4）智能化服務端點與傻瓜式服務編排
    （5）自動化運維
    （6）系統容錯
    （7）服務快速化
8.使用docker會面臨的問題
    （1）微服務化的應用架構如何進行有效的服務管控
    （2）分佈式事務難題
    （3）自動化運維和平臺穩定性
    （4）微服務的服務設計
    （5）原有組織架構是否可以知足微服務架構持續發展的須要