開源地址：https://github.com/tangxuehua/enode
上一篇文章，介紹了enode框架的總體目標，以及如何實現高吞吐、低延遲、高可用、無單點問題的實現思路。本篇文章，我們再分析一下其他一些需要考慮的問題。我發現寫文章挺累的，費時費腦經，但我會堅持下去。本文主要分析一下enode框架的物理部署：
物理部署思路：集群的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遠程服務。這種架構就是因為一個系統中不同層次因為使用了完全不同的技術而需要使用分布式的情況。