ENode 1.0 - 框架的物理部署思路

開源地址：https://github.com/tangxuehua/enode

上一篇文章，介紹了enode框架的整體目標，以及如何實現高吞吐、低延遲、高可用、無單點問題的實現思路。本篇文章，咱們再分析一下其餘一些須要考慮的問題。我發現寫文章挺累的，費時費腦經，但我會堅持下去。本文主要分析一下enode框架的物理部署：

物理部署思路：集羣的web站點+分佈式緩存和存儲

集羣的概念：多臺機器作相同的業務，對外如一臺機器在作事情同樣，集羣中任意一臺機器掛了沒有影響，由於其餘機器還在工做；集羣的機器要訪問的數據的設計，我以爲通常有兩種思路：

1. 集羣中每臺機器都用本身的數據。數據一致性是經過每臺機器之間的數據同步來實現，這樣作的主要難題是數據同步的延遲帶來的數據不一致的問題；可是好處是，由於沒有任何共享數據，因此一臺機器掛了徹底對整個系統沒有任何影響。由於這樣的設計至關因而徹底同時由不少獨立的且沒有共享任何數據的機器在同時工做，固然是最能容災的了；
2. 有一臺機器存放數據的共享數據，集羣中每臺機器都訪問這些共享數據。這種設計的好處是數據不用同步了，沒有數據延遲帶來數據不一致的問題；可是壞處是，有單點問題，萬一共享數據的服務器掛了不是麻煩了。幸虧，如今有不少開源的成熟的分佈式緩存和分佈式存儲的產品，如memcached, redis這些都是分佈式的緩存，能夠有效的避免單點故障的問題，雖然掛了的單臺memcached服務器會影響一部分數據的讀取和寫入，可是至少不會給整個系統帶來掛掉的後果；一樣分佈式存儲如mongodb，也能作到這樣的效果。這兩種產品，在分佈式部署方面我尚未任何實際經驗，平時工做中也未曾遇到過，因此從此還須要好好的學習和實踐。

分佈式的概念：一個業務在不一樣的物理點上作，好比web服務器（處理UI邏輯）、應用服務器（處理業務邏輯），這兩個節點分開部署在不一樣的機器上，共同完成一個業務；分佈式的特色是，每一個節點都不能掛，不然這個業務就不能完成了；固然，咱們能夠給分佈式中的每一個節點都作集羣處理，這樣能夠下降分佈式系統的單節點故障； 可是由於分佈式要完成一個業務，內部要誇網絡通訊如調用遠程服務，因此性能確定比沒有調用遠程服務的設計要低。通常咱們不會採用分佈式，用分佈式都是被逼的，好比如下狀況下，咱們可能會採用分佈式的設計：

1. 一個系統，有幾大塊業務，相互比較獨立，爲了讓每塊業務都能獨立設計和發展，咱們會把這些不一樣的業務模塊分開設計與實現；好比一個電子商務網站的交易中心和商品中心，能夠獨立分開設計；
2. 數據量太大，沒辦法存放在一個點，因此只能分開存儲；這種狀況咱們通常會把數據分區，不一樣分區的數據放在不一樣的點；如數據庫的分庫分表，還有一些分佈式緩存如memcached、redis，還有如mongodb這樣的支持分佈式存儲的文檔型數據庫；
3. 一個系統，不一樣的層次使用徹底不一樣的技術實現，好比因爲歷史緣由，咱們要對一個系統改造，可是這個系統的業務邏輯很複雜，並且都是用c++寫的，咱們不敢隨便動；可是咱們但願能夠在UI上給這個系統從新設計以帶來更好的用戶體驗，好比原來是用c++寫的界面，如今但願經過WPF這種更高級更炫開發維護成本更炫的技術來實現。那麼咱們就會在同一個系統使用不一樣的語言和技術來實現。這種狀況下，咱們可能須要將c++實現的業務邏輯經過遠程服務暴露出來，好比經過WCF暴露，WCF遠程服務自己能夠由c#編寫，而後c#調用managed c++，而後managed c++調用unmanaged c++。從而實現業務邏輯的遠程服務暴露；而在UI層，咱們可使用c#+WPF的方式來實現，而後UI層調用WCF遠程服務。這種架構就是由於一個系統中不一樣層次由於使用了徹底不一樣的技術而須要使用分佈式的狀況。