ENode 1.0 - 架構的實體部署思路實體部署思路：叢集的web站點+分布式緩存和存儲

叢集的概念：多台機器做相同的業務，對外如一台機器在做事情一樣，叢集中任意一台機器挂了沒有影響，因為其他機器還在工作；叢集的機器要通路的資料的設計，我覺得一般有兩種思路：

叢集中每台機器都用自己的資料。資料一緻性是通過每台機器之間的資料同步來實作，這樣做的主要難題是資料同步的延遲帶來的資料不一緻的問題；但是好處是，因為沒有任何共享資料，是以一台機器挂了完全對整個系統沒有任何影響。因為這樣的設計相當于是完全同時由很多獨立的且沒有共享任何資料的機器在同時工作，當然是最能容災的了；

有一台機器存放資料的共享資料，叢集中每台機器都通路這些共享資料。這種設計的好處是資料不用同步了，沒有資料延遲帶來資料不一緻的問題；但是壞處是，有單點問題，萬一共享資料的伺服器挂了不是麻煩了。幸好，現在有很多開源的成熟的分布式緩存和分布式存儲的産品，如memcached, redis這些都是分布式的緩存，可以有效的避免單點故障的問題，雖然挂了的單台memcached伺服器會影響一部分資料的讀取和寫入，但是至少不會給整個系統帶來挂掉的後果；同樣分布式存儲如mongodb，也能做到這樣的效果。這兩種産品，在分布式部署方面我還沒有任何實際經驗，平時工作中也不曾遇到過，是以今後還需要好好的學習和實踐。

分布式的概念：一個業務在不同的實體點上做，比如web伺服器（處理ui邏輯）、應用伺服器（處理業務邏輯），這兩個節點分開部署在不同的機器上，共同完成一個業務；分布式的特點是，每個節點都不能挂，否則這個業務就不能完成了；當然，我們可以給分布式中的每個節點都做叢集處理，這樣可以降低分布式系統的單節點故障； 但是因為分布式要完成一個業務，内部要誇網絡通信如調用遠端服務，是以性能肯定比沒有調用遠端服務的設計要低。一般我們不會采用分布式，用分布式都是被逼的，比如以下情況下，我們可能會采用分布式的設計：

一個系統，有幾大塊業務，互相比較獨立，為了讓每塊業務都能獨立設計和發展，我們會把這些不同的業務子產品分開設計與實作；比如一個電子商務網站的交易中心和商品中心，可以獨立分開設計；

資料量太大，沒辦法存放在一個點，是以隻能分開存儲；這種情況我們一般會把資料分區，不同分區的資料放在不同的點；如資料庫的分庫分表，還有一些分布式緩存如memcached、redis，還有如mongodb這樣的支援分布式存儲的文檔型資料庫；

一個系統，不同的層次使用完全不同的技術實作，比如由于曆史原因，我們要對一個系統改造，但是這個系統的業務邏輯很複雜，而且都是用c++寫的，我們不敢随便動；但是我們希望可以在ui上給這個系統重新設計以帶來更好的使用者體驗，比如原來是用c++寫的界面，現在希望通過wpf這種更進階更炫開發維護成本更炫的技術來實作。那麼我們就會在同一個系統使用不同的語言和技術來實作。這種情況下，我們可能需要将c++實作的業務邏輯通過遠端服務暴露出來，比如通過wcf暴露，wcf遠端服務本身可以由c#編寫，然後c#調用managed c++，然後managed c++調用unmanaged c++。進而實作業務邏輯的遠端服務暴露；而在ui層，我們可以使用c#+wpf的方式來實作，然後ui層調用wcf遠端服務。這種架構就是因為一個系統中不同層次因為使用了完全不同的技術而需要使用分布式的情況。