分佈式系統基礎設施概覽

DB固然是第一重要，可是具體到選擇oracle/mysql/postgresql亦或是mongodb，就須要有足夠的的經驗，主要要考慮以下點：

一、提供的feature是否足夠豐富，可否知足OLTP/OLAP的需求；

二、是否支持高併發、HA機制（各優缺點、維護可否跟上、對開發有什麼額外要求），這裏又涉及到對硬件的要求，應用層有什麼特殊要求；

三、能支撐什麼數量規模的，水平拆分容易程度；

四、對於open source，還要考慮選擇mysql/percona/mariadb分支，與標準的兼容性；

五、社區活躍性、穩定性、當前可用版本有哪些關鍵特性沒法知足業務需求；

 

web/服務端容器

web容器應該來講絕大部分非國企性質都是使用tomcat。可是對於不提供web服務的服務端容器，由於通訊由rpc中間件完成了，因此做爲託管容器而言，不太適合使用tomcat/weblogic之類的web容器，主要是不只佔用額外資源，更主要的是每一個容器至少須要三個端口，外加rpc端口的話，可能一個runtime須要五六個端口，對於一個server上運行多個Instance的狀況，端口的管理和規劃很快就會成爲一個噩夢。因此其實選擇os service託管會是更好的選擇，好比java service wrapper，並且它會做爲deamon進程，jvm進程異常掛掉時會自動重啓。

 

RPC中間件。對於分佈式系統而言，一個好的RPC中間件是很是重要的，這直接決定了整個系統的擴展性、靈活性。一個好的RPC中間件至少應該知足如下條件：

1、支持在RPC本地根據規則，好比說功能號進行路由，路由的目標能夠是本地也能夠是遠程；

2、基於長鏈接，通常爲TCP；

3、再不濟，性能也不能低於HTTP；

4、支持自動負載均衡，鏈接恢復；

5、支持服務註冊中心服務自動發佈，服務註冊信息自動拉取；

6、RPC客戶端支持API依賴注入，RPC服務端支持根據註解發佈和路徑；

7、絕大部分狀況而言，應該是不須要跨語言的，根據特定語言去作說不定更合理；

RPC框架的設計與實現參考可見http://www.cnblogs.com/zhjh256/category/911531.html

選擇基於服務的設計以後，應該同時歸入考慮的就是RESTFUL API/OPEN API的規劃和管理了。

 

分佈式緩存/DB。分佈式緩存最經常使用的場景是分佈式session，客戶信息、產品信息等相對而言比較靜態的數據。固然，它遠遠不止用於這裏。

1、支持集羣；

2、TPS 50000以上；

3、支持常規之外的list/hash/set結構；

Redis 3以後就比couchbase要更加合適了。

 

消息中間件。消息中間件是重要性等同於分佈式緩存的中間件。對於大型的分佈式系統而言，一般關鍵的業務場景在同步執行時會存在着致命的瓶頸。一個好的消息中間件應該至少知足下列條件：

1、支持集羣；

2、支持持久化；

3、4C下TPS 5000以上穩穩的（還跑了不少其餘進程）；

4、支持可信發佈、訂閱；

5、有管理API可監控隊列，隊列中內容等；

6、支持廣播、點對點、主題；

rabbitmq是比較合適的，並且如今來看，穩定性是至關好的。

提到消息，不能不說起的是websocket，根據業務高度封裝websocket集成到應用框架中是很是有價值的。