不好意思最近實在是有點太忙了，將近一個月沒更新部落格，其實前幾天我是有發表一篇關於HSF框架的原始碼解析，後來由於一些原因不得不刪除。其實HSF也跟Dubbo類似，解決了分散式系統中的一系列問題。

分散式帶來的優勢就是能夠將複雜業務拆分成多個服務的組合，就如同controller-service-dao中的service介面部署在不同的機器上，service不就是服務的抽象麼。讓不同的團隊維護不同的service，這樣便於精細化開發和維護。當然，服務的獨立部署也給動態擴容帶來的了可能性，因為不同服務的負載是不同的，所以我們能夠給每個服務配置不同的資源，達到最大限度的利用資源，例如計算密集型的機器配置強大的CPU，IO密集的配置強大的網絡卡等等。我們可以根據不同的服務，做很多個性化的處理，例如在交易模組後面構建大資料平臺進行資料探勘，訓練模型能夠個性化的推薦給不同的使用者可能購買的商品提升購買率。

當然分散式也會帶來很多問題

1. 分散式事務：
   這是一個老生常談的問題，我們都知道事務就是一些列操作的原子性保證，在單機的情況下，我們能夠依靠本機的資料庫連線和元件輕易做到事務的控制，但是分散式情況下，業務原子性操作很可能是跨服務的，這樣就導致了分散式事務，例如A和B操作分別是不同服務下的同一個事務操作內的操作，A呼叫B，A如果可以清楚的知道B是否成功提交從而控制自身的提交還是回滾操作，但是在分散式系統中呼叫會出現一個新狀態就是超時，就是A無法知道B是成功還是失敗，這個時候A是提交本地事務還是回滾呢？其實這是一個很難的問題，如果強行保證事務一致性，可以採取分散式鎖，但是那樣會增加系統複雜度而且會增大系統的開銷，而且事務跨越的服務越多，消耗的資源越大，效能越低，所以最好的解決方案就是避免分散式事務。
   還有一種解決方案就是重試機制，但是重試如果不是查詢介面，必然涉及到資料庫的變更，如果第一次呼叫成功但是沒返回成功結果，那呼叫方第二次呼叫對呼叫方來說依然是重試，但是對於被呼叫方來說是重複呼叫，例如A向B轉賬，A-100,B + 100，這樣會導致A扣了100，而B增加200。這樣的結果不是我們期望的，因此需在要寫入的介面做冪等設計。多次呼叫和單次呼叫是一樣的效果。通常可以設定一個唯一鍵，在寫入的時候查詢是否已經存在，避免重複寫入。但是冪等設計的一個前提就是服務是高可用，否則無論怎麼重試都不能呼叫返回一個明確的結果呼叫方會一直等待，雖然可以限制重試的次數，但是這已經進入了異常狀態了，甚至到了極端情況還是需要人肉補償處理。其實根據CAP和BASE理論，不可能在高可用分散式情況下做到一致性，一般都是最終一致性保證。

2. 負載均衡
   每個服務單獨部署，為了達到高可用，每個服務至少是兩臺機器，因為網際網路公司一般使用可靠性不是特別高的普通機器，長期執行宕機概率很高，所以兩臺機器能夠大大降低服務不可用的可能性，這正大型專案會採用十幾臺甚至上百臺來部署一個服務，這不僅是保證服務的高可用，更是提升服務的QPS，但是這樣又帶來一個問題，一個請求過來到底路由到哪臺機器？路由演算法很多，有DNS路由，如果session在本機，還會根據使用者id或則cookie等資訊路由到固定的機器，當然現在應用伺服器為了擴充套件的方便都會設計為無狀態的，session會儲存到專有的session伺服器，所以不會涉及到拿不到session問題。那路由規則是隨機獲取麼？這是一個方法，但是據我所知，實際情況肯定比這個複雜，在一定範圍內隨機，但是在大的範圍也會分為很多個域，例如如果為了保證異地多活的多機房，誇機房呼叫的開銷太大，肯定會優先選擇同機房的服務，這個要參考具體的機器分佈來考慮。

3. 服務發現
   服務的提供者如何被服務的使用者發現，當然很多情況一個服務既是某些服務的提供者，也是其他服務的使用者，這就需要一箇中間的機制來讓大家互相感知，例如Zookeeper(簡稱ZK)，我簡單介紹下ZK的作用和實現，其他類似於spring boot的ureka和taobao的HSF的配置中心大概都一樣的作用，只是不同的技術實現而已。Zookeeper是一個高可用叢集元件，因為它可以在叢集之間保持同步和一致，維護統一的一個類似於檔案目錄的結構。ZK包含服務端和客戶端，每個機器維護一個客戶端保持與服務端的心跳，客戶端可以在整個目錄的任何節點設定Watcher感知，這樣只要ZK維護的該目錄有任何改動，客戶端都能收到回撥通知。如果這個目錄存放的某個服務提供者的ip列表，ZK能夠感知該服務的心跳，一旦該機器與ZK失去聯絡，目錄變化，服務使用者感知到請求，這樣服務使用者呼叫的時候就獲取不到該服務提供者的ip，這樣完成動態的失效轉移。當服務恢復，ip又添加回原有ZK維護的節點列表。ZK採用了Paxos演算法保證了ZK之間的一致性，內部的選舉機制保證了叢集只要有超過半數的機器正常，叢集就可用。高可用的ZK成為一個服務的訂閱與通知的中心，這樣完成服務發現的功能。

4. 資料庫效能與高可用
   資料庫是重要的部分，因為大部門時候我們需要持久化很多資料完成業務邏輯，但是資料庫很難像應用伺服器那樣做到線性的擴容，尤其是關係資料庫，所以現在會引入一些對叢集支援比較好的NoSQL去支撐系統對效能的要求，但是NoSQL也有很多侷限性，例如沒有事務支援，這點在一些對事務敏感的情況下是難以忍受的，還有查詢的不方便，很難支援join等操作，所以NoSQL的使用對於場景的判斷非常重要，現在Redis和Memcache等更多應用在快取使用上，核心資料庫依然採用關係資料庫，以MySQL為代表。資料庫的效能主要是在查詢的優化上，專案實戰中DBA經常會警告一些常用的SQL並沒走索引進行了全表掃描，所以合理使用索引進行高效的查詢是很必要的。當然索引也不是建立的越多越好，例如某些重複率很高的欄位不適合建索引，大量的索引甚至比資料本身更佔用空間。對於資料量多的情況，我們可以採用分表分庫的方案進行拆分，分表一般採用關鍵欄位進行取模，儘量讓多個表進行均分。負載過高可以採用主從讀寫分離等等。
   高可用的資料庫一般採用主從機制，主庫掛了之後會自動轉移到備庫，曾經跟DBA討論過，線上不能引入流量到備庫，如果效能不夠自動擴容，因為如果線上主庫掛掉，瞬間流量落到從庫依然會掛，到頭一臺機器也不能用了。原則主從是為了高可用，而不是為了擴容，擴容操作應該在機器負載較高的時候就能收到警報之後。能夠失效轉移。現在高可用主要的方案也是冗餘，包括異地機房等等，本質上都是冗餘。