分散式系統主要包含的內容很多，我就針對兩個核心方面做一下解讀：分散式應用服務和物件遠端呼叫、資料的分散式儲存。先說說分散式應用服務以及物件遠端呼叫的元老之一：

EJB/RMI（Enterprise Java Beans/Remote Method Invocation）吧！

（一）分散式應用服務和物件遠端呼叫

那個時候的Java工程師，對於EJB的大名如雷貫耳，曾經EJB VS Spring大戰（Spring With Not EJB）讓程式設計師們的論戰激情興奮。其實爭論的主題就是需不需要元件間實現分散式呼叫，並在分散式網路環境保持住元件狀態，到底什麼是分散式環境的元件狀態呢？所謂分散式服務元件的無狀態 VS 有狀態

簡單點說，有狀態就是後端服務元件讓遠端呼叫過程看起來更像本地化呼叫，客戶端不用考慮過多元件狀態hold的問題，這樣更容易設計出純粹的面向物件化元件。而無狀態反過來，後端服務元件專注於接收客戶端請求並處理問題，給予客戶端迴應就夠了，不要hold住狀態徒增煩惱，狀態保持的事情讓客戶端自己解決。

例如：購物車就是個例子，無狀態的購物車，服務元件是讓客戶端透過cookie解決購物清單問題；有狀態的購物，元件服務是自己保持住購物清單狀態，那麼客戶端和服務端的物件看起來責任更清晰。

Rod Jonhson（Spring之父）就是用這本書掀起了當年的Spring的奪位之戰。

大戰最終的結局大家已經很清楚了——Spring逆襲完勝，EJB從此淡出江湖。無狀態呼叫模式成為了主流，當然EJB本身的問題也不少，雖然之後EJB3標準由Hibernate作者重新操刀設計，也是為時已晚。曾經我也是EJB力挺者之一，也跟著EJB一起淡出江湖了！^_^"

其實這種勝出，本質上是分散式系統架構向單態架構的認慫。JavaEE的頭牌EJB（企業級JavaBean）在當時代表著一種超前的設計，這種設計架構也算是當前流行的微服務架構的前浪吧，只是被拍死在了沙灘上。我們看看當時EJB VS Spring 架構：

上面的圖是JavaEE的元件服務通訊圖，有獨立部署的遠端Remote EJB容器，也有和WEB一起部署的本地Local EJB容器，它們作為元件互相之間通訊（RMI），既可以WEB應用訪問EJB，也可以EJB訪問EJB，透過JTA（JAVA事務介面）統一管理資料庫的事務操作，實現真正的分散式事務。像不像現在的微服務，像不像現在的常用的RPC呼叫，作為分散式系統架構，難道它不標準嗎，難道這個架構它不美嗎！！！

我們再看看Spring早期逆襲的架構：

上圖是Spring的SSH架構圖，典型的單例項架構，透過一個AOP切面攔截技術，對程式設計師程式碼層面的實現了事務呼叫的隱藏和透明化，讓開發專注於自身的服務。這就很有親和力，架構看起來是不是很簡單。

對了，就是用這種簡單的架構打敗了看起來很美但複雜的架構。所以你問我，分散式系統的優點是什麼？它很美，透過網路服務的元件化，實現更純粹的面向物件模型，給程式設計師一個統一的程式設計模式來應對分散式服務在網路上的複雜性。

那分散式系統的缺點又是什麼呢？

頭號缺點，部署複雜，就憑這點，就極不利於測試，嚴重影響敏捷。這個真的不是單EJB部署複雜，只要是分散式應系統，就一定部署複雜，我們可以想想目前的微服務，再輕量化設計，依然逃不開部署複雜的問題，雖然生產環境部署分開發布也有好處，但是90%的部署都發生在開發階段，那麼頻繁的測試、開發除錯和重新啟動部署，對於個體程式設計師來講，就是比單例項服務要更加是個沉重負擔。

第二個缺點就是將原來集中在資料庫的SQL訪問模式轉變成了網路服務之間的介面呼叫，無論是EJB也好，微服務也好，這種分散式系統的呼叫模式本質都是反人性的，因為人都喜歡集中在一箇中心去解決問題，形式簡單，出現變化更容易定位和適應，分散不同地方的服務，無論從服務編排也好，介面變更也好，錯誤跟蹤也好，讓人去處理都太費勁了。

因此Spring的單體服務就是憑藉著部署簡單、適應敏捷、人性化等特質，打敗了EJB，分散式系統第一次完敗。但是為什麼最終依然演化出了微服務架構呢？而且熱度不減當年，其實我認為就是曾經EJB熱度的又一次輪迴，SpringCloud也開始了當年EJB之路。微服務在架構拆解之路上，甚至開始了資料庫和微服務打包獨立的情況，下面是微服務的架構模樣：

上圖是API閘道器進行多個微服務的排程，微服務之間互相排程，每個微服務擁有自己的獨立資料庫，都是從一個傳統Master單庫切分而來，Master庫也逐漸成為資料中心庫，提供基礎資料交換和資料分析（OLAP）

我們看看微服務的架構和上面的EJB分散式架構多麼的像，其實都是一個血脈遺傳下來的，那就是分散式系統。但是微服務演化到拆庫就真的好嗎？我不敢苟同，咱們可以把資料庫的不同資料表比喻成一個家庭的多個成員，難道把家庭成員強行拆開就一定好嗎？家裡原來公用一臺電視機，現在拆分一個成員，就要配一臺電視，難道看電視還要跑回來看嗎？這就是類比了資料欄位到底是冗餘，還是走介面呼叫？這個會讓設計者太痛苦的，本質是反人性的。

為什麼非要這樣做呢？說到底就是想讓關係型資料庫實現垂直切分，形成更好的效能水平提升，也就是說，問題根子出在關係型資料庫身上了，關係型資料庫天然就不支援分散式化，無法更好的實現資料庫級的水平伸縮，所以將來一定是分散式資料儲存系統替代關係型資料庫的時代。因為我們如果有了一個廉價且效能強大的資料庫系統，透過水平伸縮解決效能問題，我們又何必費勁的搞業務資料的垂直切分呢！這就是下來說分散式儲存的關鍵作用。

（二）資料的分散式儲存

資料的分散式儲存具體表現形式也就是分散式資料庫，分散式資料庫不同於分散式應用服務，不存在開發測試階段費勁的釋出重啟，所以並不影響敏捷性；另外資料呼叫都集中在一個訪問代理上，因此不需要像分散式應用服務那麼反人性的考慮介面管理，分散式資料庫的水平伸縮力，恰恰解決了微服務必須分庫的尷尬問題，可以讓程式設計師專注於資料訪問的業務問題上。既然這麼多好處，為什麼不能大規模應用呢？問題的根源就出在事務上了！

為什麼關係型資料庫就具備ACID的事務的優勢呢？先簡單點說說事務的原理，事務就是對資料的加鎖解鎖，給資料行集加鎖，我（事務）要處理一行資料，我（事務）就申請一把鑰匙，給資料行上個鎖，其他人（事務）等著我解鎖了，其他人才能訪問。這個操作放到以單機設計為主的關係型資料庫上好解決，但是放到如今的分散式資料庫環境，這就特別麻煩了，因為資料被分成片，分佈在不同的機器節點庫中，事務加鎖就要定位到所有相關的節點，事務問題就淋漓盡致地體現出了分散式系統在網路環境中多節點協作的複雜性，協作越緊密的事情，分散式系統幹起來越吃力，為什麼Key/Value資料庫，例如Redis用起來最舒服，也很流行，就是資料相互之間沒什麼協作關係。

分散式資料庫事務這個夠嗆的問題，也沒有難住偉大的計算機科學家們，例如：TIDB繼承自Google Percolator，使用 Percolator 事務模型，實現了分散式事務。也就是現在又出現的一個新名詞：NewSQL，傳統關係型資料庫ACID特性+NoSQL。

我們先說說分散式資料庫的關鍵是什麼？就是對一大塊資料進行分片（分塊/分割槽），平平整整地放到不同的物理節點上，保持每個節點的資料量差不多是最佳的，這樣吞吐效能最好，若節點有的多，有的少，這就是出現傾斜了，那麼資料多的節點就會承載更大的資料訪問壓力。

不同的資料節點有管理者進行管理，有的管理者是集中式任命的，例如HDFS的namenode，有的管理者是被推舉的，例如Elasticsearch master node。總之分散式資料庫就有管理節點負責排程資料節點，也有資料節點服務資料讀寫。就是這麼一回事兒。

上圖就是兩種不同的資料管理方式，第一個是主從模型，例如HDFS的分塊，由namenode統一負責資料塊節點的分配排程；第二個是對等模型，例如Kafka的分割槽，也就是每個節點即是主又是從，關鍵看自己節點對應的分片狀態是主還是從。

我們再看看分散式事務的架構有多麼複雜，就看看TIDB的架構吧！

上圖是TIDB作為一個整體存在，作為玩分散式資料庫的專家看了這個架構都會頭大。

TIDB作為面向客戶端的SQL請求和邏輯處理者，PD是叢集的管理者，TiKV又透過key/value的形式持久化資料，TIDB、PD、TiKV，各自又是分散式叢集，那麼事務的發起、資料路由由PD負責，SQL的接收、事務過程的控制由TiDB負責，資料的落地由TiKV負責。透過這麼一個責任分工明確的體系，就形成了真正的分散式事務。

其優點就是事務加鎖終於去中心化了，到達了分散式資料庫技術航行最遠的地方了，這可是谷歌的Percolator論文在2011年就發表了，谷歌真的是神族所在地。

可付出的代價依然不小，第一個很明顯，物理機器少不了，但是能到了這份上的業務也不在乎這麼多資源了。第二就是TiDB的事務過程控制是在記憶體中進行的，等事務一致性同步好了，才會進入TiKV持久化，因此記憶體的消耗一定不得了，遇到延時類bug，記憶體就有可能因為資料洪水決堤，最後的問題還是網路互動太頻繁了，保障一個良好的網路環境極為重要。

好，就聊這麼多吧，希望本文的一些淺見使我們對分散式系統有一些更深刻的理解，一句話：分散式系統太複雜了，你很難去控制它，需要的是深入去理解它。