(#)背景
随着網際網路的發展，網站應用的規模不斷擴大，正常的垂直應用架構已無法應對，分布式服務架構以及流動計算架構勢在必行，亟需一個治理系統確定架構有條不紊的演進。
- 單一應用架構
- 當網站流量很小時，隻需一個應用，将所有功能都部署在一起，以減少部署節點和成本。
- 此時，用于簡化增删改查工作量的 資料通路架構(ORM) 是關鍵。
- 垂直應用架構
- 當通路量逐漸增大，單一應用增加機器帶來的加速度越來越小，将應用拆成互不相幹的幾個應用，以提升效率。
- 此時，用于加速前端頁面開發的 Web架構(MVC) 是關鍵。
- 分布式服務架構
- 當垂直應用越來越多，應用之間互動不可避免，将核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
- 此時，用于提高業務複用及整合的 分布式服務架構(RPC) 是關鍵。
- 流動計算架構
- 當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個排程中心基于通路壓力實時管理叢集容量，提高叢集使用率。
- 此時，用于提高機器使用率的 資源排程和治理中心(SOA) 是關鍵
(#)架構
節點角色說明：
- Provider: 暴露服務的服務提供方。
- Consumer: 調用遠端服務的服務消費方。
- Registry: 服務注冊與發現的注冊中心。
- Monitor: 統計服務的調用次調和調用時間的監控中心。
- Container: 服務運作容器。
調用關系說明：
- 0. 服務容器負責啟動，加載，運作服務提供者。
- 1. 服務提供者在啟動時，向注冊中心注冊自己提供的服務。
- 2. 服務消費者在啟動時，向注冊中心訂閱自己所需的服務。
- 3. 注冊中心傳回服務提供者位址清單給消費者，如果有變更，注冊中心将基于長連接配接推送變更資料給消費者。
- 4. 服務消費者，從提供者位址清單中，基于軟負載均衡算法，選一台提供者進行調用，如果調用失敗，再選另一台調用。
- 5. 服務消費者和提供者，在記憶體中累計調用次數和調用時間，定時每分鐘發送一次統計資料到監控中心。
(#)簡介與技術選型
RPC（REMOTE PROCEDURE CALL），說的簡單點就是在本地，調用另一個伺服器上的服務。
RPC在資料傳輸上，可以基于HTTP,TCP協定，如Hession是基于HTTP協定的RPC架構，本身的有點是跨平台性，但是性能上
确不如基于TPC協定的RPC架構，因為TCP協定是傳輸層協定，HTTP是應用層協定，越底層的一般性能上會更好一些。
主要影響整體架構性能的是傳輸方式和序列化，在資料傳輸方面一般會選擇TCP。就序列化而言，比如protobuf,hession
jackson 等都是很優秀的序列化方式，用來代替java自帶的序列化方式，進而提供更高效的性能。
為了支援高并發，普通的BIO顯然會嚴重的影響性能，是以我們需要使用NIO，但是底層的NIO API使用起來需要熟悉的技術點
太多，需要結合各種多線程知識，是以我們使用netty架構來屏蔽掉底層的操作。
我們同時需要将服務部署在分布式的環境中，通過服務注冊的方式，讓用戶端發現目前可用的服務，并調用這些服務，這裡
就需要用到一種服務注冊的元件，讓它來注冊所有分布式環境下服務的位址。此外為了防止出現單點故障，需要部署叢集環境。
綜上所述，技術選型如下
1:spring
2.netty
3.protostuff
4.zookeeper
5.動态代理
轉載于:https://www.cnblogs.com/wscit/p/6040445.html