分布式部署
目錄
什么是分布式系統... 1
為何需要分布式... 1
分布式系統的特點... 1
分布式系統的缺點... 2
什么是分布式部署... 2
什么是分布式架構... 2
架構師需要懂部署嗎... 2
架構分布式系統的常見關注點... 2
分布式架構部署的演變... 3
分布式部署給開發帶來的問題... 4
模塊間的相互調用... 4
統一會話管理... 6
單點登錄... 7
一致性更新... 7
分布式事務... 8
高可用性（HA）... 9
什么是分布式系統
通俗點說：就是能把系統進行拆分並部署到多台服務器上的系統。（注意區分 分層和集群）
專業點說：分布式軟件系統(Distributed Software Systems)是支持分布式處理的軟件系統，是在由網絡互聯的多處理機體系結構上執行任務的系統。常見的有：分布式操作系統、分布式程序設計語言及其編譯(解釋)系統、分布式文件系統、分布式數據庫系統、分布式應用系統等。
為何需要分布式
單台服務器已經無法承受訪問壓力、大數據處理、高並發訪問、高可用性，自動容錯、並行、高性能應用……
分布式系統的特點
1：面對高並發、大數據量的處理要求
2：高可擴展性（可伸縮）
3：高性能
4：異構：操作系統、硬件、程序語言等
5：同步、異步操作混雜
6：安全性：授權認證、SSO單點登錄、0auth等
7：透明性，如：訪問透明、位置透明、並發透明、故障透明、伸縮透明等
分布式系統的缺點
相互調用不便、網絡通信的可靠性、網絡傳輸數據的安全問題、系統開發更復雜、測試困難……
什么是分布式部署
簡單點說：就是把程序或數據，分散部署到多台物理服務器上，但他們組
合起來，形成一個整體對外提供服務。
什么是分布式架構
簡單點說：就是系統的架構和設計，要能支持和滿足系統進行分布式部署的需要
架構師需要懂部署嗎
必須要懂，不但要懂，還要會規划。程序的架構、設計和實現都要考慮部署。
架構分布式系統的常見關注點
常見的有：可用性、性能、可靠性、可擴展、易管理、成本等。
實際設計中，要根據具體應用，對這些點進行綜合考慮和權衡。
分布式架構部署的演變
■1台服務器的最簡部署
■分離Web服務器和數據庫服務器
■水平增加Web服務器，加入Varnish
■加入分布式的文件系統
■加入緩存服務
■MySq1數據庫的主從集群、讀寫分離
■繼續水平增加Web服務器，加入Nginx
■按業務進行緩存分離，緩存集群
■數據庫分區、分庫、分表
■加入NoSQL數據庫
■加入消息系統，進行異步處理
■集群：Web服務器、緩存服務器、文件系統、消息處理系統、數據庫、NoSQL等
■對應用進行拆分部署，比如：分層拆分、甚至是功能級的細粒度拆分
■加入F5等硬件設備，加入CDN
■對重要的節點進行HA集群，或者是雙機熱備，以保障可用性
分布式部署給開發帶來的問題
■分布式部署會帶來很多問題，有很多在開發期間就要考慮到，比如：
1：各個拆分開的模塊間如何相互調用
2：單點登錄
3：會話的統一管理
4：一致性更新
5：分布式事務
6：關鍵服務的可用性保障
模塊間的相互調用
■Java中常見的遠程調用方式：
Socket、Http、TCP、UDP、RPC、RMI、JMS、WebService……
■常見的框架介紹
1：Hessian:類似於RMI，使用二進制消息來進行遠程調用。與RMI不同的是，它的二進制消息可以在非Java中使用，它實現了一種跨編程語言的對象序列化方法
2：Burlap：是一種基於XL的遠程調用技術，但和其他基於XML的遠程技術（如SOAP
或XML-RPC)不同，Burlap的消息結構是盡可能的簡單，不需要額外的外部定義
語言（如WSDL）
3：Dubbo：阿里開源的分布式服務框架，通過高性能的RPC實現遠程服務的調用，可以和Spring框架無縫集成，其架構類似於ESB。
4：Sprinlg的HttpInvoker：類似於RMI，基於HTTP協議來進行遠程調用，使用java的序列化機制，要求客戶端和服務端都是基於Java的
5：WebService
■方案的選擇
一：如果系統全部為內部可控的
1：量級不太大，可以考慮使用Hessian/Burlap
2：量級較大，且交互要求較高，那么dubbo是一個現成、成熟的選擇
缺點：需要很多額外的成本，比如學習成本，按需改進的成本等
3：交互要求並不高，主要是相互調用的需求，可以考慮自己實現
優點：完全按需定制，完全可控，升級、改進和完善都方便
缺點：需要投入開發成本，且完善成熟有一個過程
二：系統包含很多外部的應用，不能全部可控，且很多異構的系統
1：如果要求不是很復雜的話，WebService是不錯的選擇
2：如果要求非常復雜，且涉及很多業務流，那就選擇一個ESB平台
■更多需要考慮的問題
1：長連接，連接池，可以考慮HttpClient
2：高並發，多線程池，可以考慮使用apache的common-pool
3：快速的網絡傳輸，可以考慮使用NI0，比如：Mina框架，Netty框架等
4：大數據量，數據壓縮傳輸，可以考慮Java的GZip
5：可用性、穩定性、容錯
6：分布式的事務
7：訪問安全、數據安全等
8：服務的集群，服務的注冊和管理等
統一會話管理
■解決方案
1：根據IP或者Cookie來映射訪問同一服務器，如：Nginx的IP_Hash，nginx-
upstream-jvm-route等
2：采用統一的會話管理，可以把會話數據存放在公共的地方，比如Memcached
（1）自行實現
（2）結合框架去實現，比如使用Shiro
3：把會話序列化后，存放到客戶端Cookie里面
■更多的問題
1：如果用戶關閉了Cookie
2：Cookie數據的安全性
3：跨域訪問Cookie
4：公共緩存的規划、集群和數據維護
單點登錄
跟EAI中的SSO相比，這里所說的單點登錄是很簡單的，算不上是“真正”的SSO
1：本身就是一個系統，只有一套用戶和權限系統
2：對用戶的驗證方式是統一的
3：都是內部系統，相互信任，所以也就不用驗證是否可訪問系統了
■解決方案
1：簡單的：使用Shiro的統一會話管理，實現單點登錄
2：稍麻煩些的：使用Shiro+CAS來實現
3：更麻煩的：使用專業的SSO框架或產品
一致性更新
■分布式的一致性介紹
對於一致性，可以分為從客戶端和服務端兩個不同的視角。從客戶端來看，一致性指的是並發訪問時更新過的數據如何獲取的問題；從服務端來看，則是更新的數據如何復制分布到整個系統，以保證數據最終一致。一致性是有並發讀寫才有的問題，因此在理解一致性的問題時，一定要注意結合考慮並發讀寫的場景。
■CAP的最終一致性
從客戶端角度，並發訪問時，更新過的數據在不同進程如何獲取的不同策略，決定了不同的一致性。
對於關系型數據庫，要求更新過的數據能被后續的訪問都能看到，這是強一致性；如果能容忍后續的部分或者全部訪問不到，則是弱一致性；如果經過一段時間后要求能訪問到更新后的數據，則是最終一致性。
■常見的解決方案
一：有一個公共的數據庫
1：單點部署，也就是整個系統中只有一個地方能修改這個數據
2：采用版本控制
二：分散到多個數據庫
1：可以把問題簡化成為只有一個數據庫的情況
2：采用預分配數據，動態進行邏輯調整
分布式事務
■解決方案
1：同一個Web服務器，多個數據庫，可以使用Atomikos
2：跨越多個Web服務器的事務，如果遠程調用支持事務傳播，那么使用JTA就可以；如果不支持事務傳播，就盡量轉化為一個web服務器的情況
3：自行開發事務邏輯事務管理器
4：采用業務補償回滾的方式
5：重新設計和規划
高可用性（HA）
■解決方案
可以使用Keepalived/Heartbeat等類似的軟件
■什么是HA
HA（High Available),高可用性群集，指的是通過一組計算機系統提供透明的冗余處理能力，從而保證系統服務高度的連續可用。
■幾點說明
1：HA通常是軟件和硬件相結合的集群方案，是自動且透明的
2：只有硬件的方案不是HA，那是熱備，通常是人工的切換備用機
3：HA通常由軟件檢測故障，一旦故障發生立即切換服務到集群中正常的服務上，通過提供故障恢復，實現最大化系統和應用的可用性
4：HA在故障恢復的切換過程中，會有短暫的服務暫停的過程，因為選舉新的服務器，以及資源轉移都需要一定的時間，當然這個時間很短
5：HA的衡量指標通常有：平均無故障時間（MTTF），平均維修時間（MTTR），可用性=MTTF/(MTTF+MTTR)
■HA的幾種常見部署模式
1：主從方式：兩台服務器，一台為主，另外一台為備份服務器
2：對稱方式：兩台服務器，互為備份
3：多機方式：多台服務器，故障時切換至其中一台
■HA的基本實現原理
1：提供虛擬IP給外部訪問
2：節點之間通過心跳或信息報文來確定健康狀態
3：節點之間通訊通常會加密，以防止非法主機加入
4：當前提供服務的機器出現問題后，需要按照一定的規則，投票選舉出新的提供服務的機器，並接管服務