为大量用户服务的服务端网络架构设计(负载均衡相关)

由来：
因为打算自己开发一个类似于即时通讯的服务端，为了以后的发展，需要先规划好框架，其中最主要的客户端连接服务端的方案。因为随着客户的增多（比如说100万），客户的同时上下线（比如说1万），对系统都将是一个很大的压力。而且还要考虑服务器的负载均衡。

思路：
通过学习MSN面对用户数量不断增大时所不断改进的后台负载方案（google "亿万用户网站MySpace的成功秘密"），可以让我们有个前车之鉴。在软件设计时将对这些预期的问题的解决思路考虑进去，在以后真正面对这个问题时，也方便改进。
通过学习QQ的登录方式，可以让我们对用户的上下线压力有所准备。

通过学习，得到两个方案：
方案一：由客户端主要探测各通讯服务器的连接响应速度，然后连接响应速度最快的服务器。
方案二：由客户端主动探测各负载均衡服务器（简称“均衡机”），然后连接响应速度最快的均衡机。再由此均衡机将它所管理区域内，负载最小的通讯服务器分配给客户。最后由客户主动连接分配到的通讯服务器。

分析：
方案一分析：
优点：客户端总能连接到对客户而言响应最快的服务器。
缺点：需要探测所有通讯服务器才能找到响应最快的一个。
客户端连接到响应最快的一个服务器，对它的主要业务――通讯能带来什么优势呢？文本通讯一般只有1、2K的大小，音、视频一般可以通过“打洞”的方式进行P2P的通讯。而且，就某个使用区域（比如大陆、港台）而言，服务器响应也慢不到哪里去。所以，服务器速度的响应快慢，对它的主要业务的影响不大。
优点不优，反而缺点会在使用过程中带来很大的问题，特别是当需要增加服务器时。首先，客户端需要探测所有的通讯服务器。当用户数量不多时，用户的同时上下线对各服务器响应速度的探测不会对各服务器进行什么压力。但考虑到后期的发展，用户数量很大，甚至是巨大时，像现在的QQ，同时上下线的都会达到10万的数量线。如果仍然采用探测的方式，将会给各服务器很大的负载压力和网络压力。而且每台服务器的这种压力都是相同的，这种框架下，你不可能有方法去消除这种压力。而你新增的服务器，刚上线，就有一部分的资源消费在了这个压力上。很不值的。而且，客户端还必须拥有最新的通讯服务器列表。随着通讯服务器增加，客户端也将会受到影响。这种缺点会将整个发展带入一个恶性循环。
通过分析，方案一不适合这种后期用户越来越多的业务系统。

方案二分析：
优点：负载均衡服务器（简称“均衡机”），充分利用服务器资源，可方便增加新的服务器，而对客户端是透明的。
缺点：客户端可能会连接到负载小，但对客户而言，响应速度不太快的服务器上。
此方案的优点正是方案一中的解决方法。升级对客户端透明。当负载压力大时，可以通过增加新的通讯服务器来分担压力。只需要新增的服务器注册到某个均衡机即可。均衡机的功能单一，事务简单，吞吐量可以很大。增加均衡机的机率较小，这样，客户端需要探测的地址基本不变。为了增加可扩展性，也可在设计均衡机与客户端的协议时，将协议设计为可进行多次探测的。即探测机返回的地址即可为通讯服务器地址，也可均衡机地址。如此，可扩展性将更加强大，对客户端也可以做到完全无影响。
而且，client对均衡机的探测，也可以让客户找到响应速度最快的网络区域。
至于缺点，它的对立面是方案一的优点。既然方案一的优点算不上优势，这个缺点自然也就不算是劣势。可以忽略。

负载均衡功能需求：
1、 对client的探测进行响应；
2、 对连接上的client返回所负责服务器中负载最小的服务器地址；
3、 对仍使用旧负载服务器表的client升级旧负载服务器表（可选）。
说明：第3点可选。因为均衡机功能单一，事务简单，吞吐量可以很大。而且还可以进行二次探测。再加上如果一开始，就在客户端预留一些探测地址（早期均指向同一个均衡机IP），然后在后期转成其它扩展的真实均衡机IP，这基本上可以完全不用为均衡机的增加对客户端的影响而担心了。

思路扩展：
1、防止DDOS攻击。DDOS攻击，将导致部分均衡机无法响应client的探测，大量的client连接到未受攻击的均衡机。因为每台均衡机只负责自己管理的服务器（一般为同一网络区域），这将导致该区域的通讯服务器负载大增，网络也将非常繁忙。而受攻击的均衡机无法再处理新的用户请求，则它所管理的通讯服务器也将不再有新增的客户端压力，它们的负载和网络压力将基本不变。这样就进行了忙的忙死，闲的闲死。为了防止这种情况发生，可以扩展一下均衡机的功能，当均衡所管理区域内的负载压力或网络压力过大（达到某个阀值）时，与其它均衡机通讯，相互调剂资源。

(2009/01/09)
补充：
 上面的假设环境是所有的通讯服务器都有独立IP，都暴露在因特网上。因为只有在因特网上，客户端才能主动连接上来。
 实际应用中，这种可能性很小，基础上都是对外只暴露几个固定的IP，然后，在内网增加服务器。其实，就算是这样，这种均衡机制也还是有用的。因为为了保障服务不间断，一定是需要异地分布服务器的，这样，即使你每个区域对外只有一个IP，这种均衡机制也是有用的。首先是可能通过均衡机之间的通信来实现区域间的负载均衡，再就是担负了客户的探测压力。而且，如果后期有什么框架上的改动，多这么一层，一切都好办一些。

思路有限，欢迎讨论！