我對java分布式系統的一點認識 - biakia

相對于單機系統，分布式系統非常復雜，涉及到非常多的技術，作為一個屌絲，有幸能夠在大規模分布式系統下工作，故在此記錄一些淺薄認識，作為自己未來學習路線的參考。

一、分布式系統概述

分布式系統往往是把應用拆分成多個應用，每個團隊維護一個應用，應用與應用通過遠程過程調用或者消息中間件通信。這種系統的優點是能夠做到高內聚 低耦合，可以支撐業務的快速發展，缺點則是運維成本大大提高了，系統出了問題，需要全鏈路排查。如圖所示，用戶使用應用A，應用A首先需要調用應用B，然 后調用應用C，其中應用B又要調用應用D和E，其中任何一個應用掛了，都會影響整個系統的鏈路。以上只是一個很簡單的例子，真實的系統之間的依賴關系往往 非常復雜。

二 分布式系統下的技術棧

在此主要是挖個坑，后續我會一個一個填的。。。

對于分布式系統中的某個應用來說，它的入口往往有三個：遠程過程調用（其他應用來調用我的服務）、消息中間件（我訂閱了其他系統的消息，其他系統 會給我發消息）、web訪問（主要訪問頁面），它的出口則有很多：遠程過程調用（調用其他應用的服務）、消息中間件（我向消息服務器發消息，供其他應用消 費）、訪問分布式緩存、訪問分布式日志、訪問數據庫，執行調度任務。有了入口和出口，剩下的就是應用的核心部分，包括核心邏輯代碼和輔助框架。對于分布式 系統來說，有個東西必不可少，那就是配置中心。無論是遠程過程調用、消息中間件還是分布式緩存，它們都需要從配置中心獲取地址列表。

下面簡要概括一下分布式系統涉及的技術：

1、遠程服務框架：遠程服務框架是分布式系統中不可或缺的，對于遠程服務框架來說，關鍵的幾個點是：服務消費者、服務提供者、協議（java序列 號、反序列化、hessian協議等等）、網絡（NIO、多路復用等等）、地址列表。其中協議的選擇、網絡的優化以及地址列表的獲取是難點。目前業界比較 有名的開源框架有：Apache Thrift（跨語言）、Dubbo等等。

2、消息中間件：引入消息中間件是用來降低應用之間的耦合的。對于上游應用來說，它往往會依賴非常多的下游應用，如果全部用同步調用（遠程過程調 用就是同步調用）的方式，那么上游應用必須等到所有下游應用全部執行成功后，才能返回成功，這種等待往往是不可忍受的。為此，需要將同步異步化，而消息中 間件可以實現這種異步化。使用消息中間件后，上游應用只需要向消息服務器發送消息就可以了，它不用等待所有應用執行完，它可以提前返回執行成功，后續，消 息服務器會去向這些下游應用發消息，通知它們執行。雖然異步化降低了應用之間的耦合，但也引入了新的問題。比如，下游系統執行的時候掛了，而這時候上游系 統其實是返回的成功，這樣就導致了狀態不一致。要解決這個問題，就需要使用消息中間件本身的重試機制，對于一些系統異常，需要重試直到成功，對于應用本 身，又需要對這種重試進行冪等處理，并且使用正向狀態機管理整個系統的狀態。消息中間件的規范可以參考JMS，業界也有成熟的開源方案，比如 ActivityMQ。

3、wrapper層：warpper層主要是上面兩個入口的包裝層，進行一些異常管理，日志管理和AOP攔截

4、MVC框架：這個不用多說了吧，個人比較喜歡spring MVC，有空可以閱讀下源代碼

5、分布式緩存：待填坑。。

6、分布式日志：待填坑。。

7、文件存儲系統：待填坑。。

8、IOC容器：目前用的最多的是spring容器，對于spring的核心的幾個模塊，可以參考《spring源碼深度解析》

9、ORM框架：ORM最好使用ibatis，不推薦hibernate，因為ibatis可以控制sql，在大數據量讀寫下，必須對sql進行優化。至于ibatis本身的架構，有空我會單獨寫文章。

10、調度引擎：用于執行異步的定時任務的引擎，待填坑。。

11、分布式數據訪問層：正在學習中。。

12、配置中心：統一的配置管理中心，待填坑。。

13、web容器：tomcat，結合《tomcat源代碼分析》和tomcat本身的源代碼，應該可以很容易的懂tomcat的架構和實現。

14、業務邏輯層：流程引擎和規則引擎，配合spring來治理極易變動的業務邏輯，后續有空單獨寫個流程引擎