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远程服务。这种架构就是由于一个系统中不一样层次由于使用了彻底不一样的技术而须要使用分布式的状况。