隨著網際網路的發展，網站應用的規模不斷擴大，常規的垂直應用架構已無法應對，分散式服務架構以及流動計算架構勢在必行，亟需一個治理系統確保架構有條不紊的演進。

分散式服務架構
當垂直應用越來越多，應用之間互動不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。此時，用於提高業務複用及整合的分散式服務框架(RPC)是關鍵。

設計的需求：
在大規模服務化之前，應用可能只是通過 RMI 或 Hessian 等工具，簡單的暴露和引用遠端服務，通過配置服務的URL地址進行呼叫，通過 F5 等硬體進行負載均衡。

當服務越來越多時，服務 URL 配置管理變得非常困難，F5 硬體負載均衡器的單點壓力也越來越大。 此時需要一個服務註冊中心，動態的註冊和發現服務，使服務的位置透明。並通過在消費方獲取服務提供方地址列表，實現軟負載均衡和 Failover，降低對 F5 硬體負載均衡器的依賴，也能減少部分成本。

當進一步發展，服務間依賴關係變得錯蹤複雜，甚至分不清哪個應用要在哪個應用之前啟動，架構師都不能完整的描述應用的架構關係。 這時，需要自動畫出應用間的依賴關係圖，以幫助架構師理清理關係。

接著，服務的呼叫量越來越大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？什麼時候該加機器？ 為了解決這些問題，第一步，要將服務現在每天的呼叫量，響應時間，都統計出來，作為容量規劃的參考指標。其次，要可以動態調整權重，在線上，將某臺機器的權重一直加大，並在加大的過程中記錄響應時間的變化，直到響應時間到達閥值，記錄此時的訪問量，再以此訪問量乘以機器數反推總容量。

呼叫關係說明
0.服務容器負責啟動，載入，執行服務提供者。
1.服務提供者在啟動時，向註冊中心註冊自己提供的服務。
2.服務消費者在啟動時，向註冊中心訂閱自己所需的服務。
3.註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。
4.服務消費者，從提供者地址列表中，基於軟負載均衡演算法，選一臺提供者進行呼叫，如果呼叫失敗，再選另一臺呼叫。
5.服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘傳送一次統計資料到監控中心。

Dubbo 架構具有以下幾個特點，分別是連通性、健壯性、伸縮性、以及向未來架構的升級性。

dubbo和dubbox的區別：
dubbox是噹噹網在dubbo的基礎上演化來的

dubbo2017年以後又重新維護

序列化的成熟度
我們發現其實java的序列化效能還是比較低的

先聊聊 Java的序列化，Java官方的序列化和反序列化的實現被太多人吐槽，這得歸於Java官方序列化實現的方式。

1、Java序列化的效能經常被吐槽。
2、Java官方的序列化後的資料相對於一些優秀的序列化的工具，還是要大不少，比如probuf，這大大影響儲存和傳輸的效率。
3、Java序列化一定需要實現Serializable介面
4、Java序列化的 serialVersionUID 也是個大坑

另外，序列化和反序列化中還需要考慮：跨語言，新舊物件版本相容，安全，效能。今天主要來說說，Hessian2是如何來解決這些問題的？

目前hessian2已經支援了非常多語言，Java,Node,php,Erlang,c#…….

二、新舊物件版本相容：hessian2將類的描述資訊寫入byte[]中，以便於在反序列化時候能正常。但是這樣就帶來了一個問題：序列化後的內容較大。

三、安全，hessian序列化時，會呼叫writeReplace方法得到一個新的物件，能將物件中的一些值進行加密後在進行序列化。

四、效能：hessian2的序列化在內容的序列化上做了一些優化，hessian2將需要序列化的多個相同的物件只會寫入一次，其他用到該物件的只使用物件的引用，而不重新寫入物件的描述資訊和值資訊。但是hessian2在描述資訊上寫入的資訊來相容動態化的反序列化支援，所以內容相對於一些描述性的序列化工具(thrift,protobuf)來說，在效能上沒有優勢。

再回到序列化，相對於 Java來說，hessian的序列化從跨語言，新舊物件的版本相容，安全以及效能方面都做的好，主要體現在：

一、Java的序列化無法跨語言。
二、新舊物件的版本Java可以通過一個serialVersionUID來處理，這就需要開發者關注序列化的幾個語義。
三、Java需要實現一個接口才能進行序列化和反序列化，序列化沒有進行加解密的介面。
四、Java序列化後的內容比Hessian更大，這不利於序列化本身的效能和網路傳輸、以及儲存的效能。

當然我們還有更加優秀的一些序列化和反序列化的工具，根據不同的使用場景可以自行選擇

失敗策略

負載均衡策略