13518219792
根据您的个性需求进行定制 先人一步 抢占小程序红利时代
今天和大家系统性聊聊TCP的负载均衡，高可用，与扩展性架构。
专业领域包括网站设计、做网站、商城网站开发、微信营销、系统平台开发， 与其他网站设计及系统开发公司不同，成都创新互联公司的整合解决方案结合了帮做网络品牌建设经验和互联网整合营销的理念，并将策略和执行紧密结合，为客户提供全网互联网整合方案。
web-server的负载均衡，高可用，扩展性架构是怎么实施的?
互联网架构中，web-server接入一般使用nginx来做反向代理，实施负载均衡。整个架构分三层：
那整个访问过程是怎么样的?
由于http短连接，以及web应用无状态的特性，理论上任何一个http请求落在任意一台web-server都应该得到正常处理。
画外音：如果必须落在一台，说明架构可能不合理，难以水平扩展。
问题来了，tcp是有状态的连接，客户端和服务端一旦建立连接，一个client发起的请求必须落在同一台tcp-server上，此时如何做负载均衡，如何保证水平扩展呢?
方案一：单机法tcp-server
单个tcp-server显然是可以保证请求一致性：
这个方案有什么缺点?
无法保证高可用。
方案二：集群法tcp-server
可以通过搭建tcp-server集群来保证高可用，客户端来实现负载均衡：
如何保证高可用呢?
如果client发现某个tcp-server连接不上，则选择另一个。
这个方案有什么缺点?
每次连接前，需要多实施一次DNS访问：
如何解决DNS的问题?
直接将IP配置在客户端，可以解决上述两个问题，很多公司也就是这么做的，俗称“IP直通车”。
“IP直通车”有什么新问题?
将IP写死在客户端，在客户端实施负载均衡，扩展性很差：
方案三：服务端实施负载均衡
只有将复杂的策略下沉到服务端，才能根本上解决扩展性的问题。
增加一个http接口，将客户端的“IP配置”与“均衡策略”放到服务端是一个不错的方案：
这样的话，扩展性问题就解决了：
然而，新的问题又产生了，如果所有IP放在客户端，当有一个IP挂掉的时候，client可以再换一个IP连接，保证可用性，而get-tcp-ip接口只是维护静态的tcp-server集群IP，对于这些IP对应的tcp-server是否可用，是完全不知情的，怎么办呢?
方案四：tcp-server状态上报
get-tcp-ip接口怎么知道tcp-server集群中各台服务器是否可用呢，tcp-server主动上报是一个潜在方案，如果某一个tcp-server挂了，则会终止上报，对于停止上报状态的tcp-server，get-tcp-ip接口，将不返回给client相应的tcp-server的外网IP。
该设计的存在的问题?
诚然，状态上报解决了tcp-server高可用的问题，但这个设计犯了一个“反向依赖”的耦合小错误：使得tcp-server要依赖于一个与本身业务无关的web-server。
方案五：tcp-server状态拉取
更优的方案是：web-server通过“拉”的方式获取各个tcp-server的状态，而不是tcp-server通过“推”的方式上报自己的状态。
这样的话，每个tcp-server都独立与解耦，只需专注于资深的tcp业务功能即可。
高可用、负载均衡、扩展性等任务由get-tcp-ip的web-server专注来执行。
多说一句，将负载均衡实现在服务端，还有一个好处，可以实现异构tcp-server的负载均衡，以及过载保护：
总结
(1) web-server如何实施负载均衡?
利用nginx反向代理来轮询、随机、ip-hash。
(2) tcp-server怎么快速保证请求一致性?
单机。
(3) 如何保证高可用?
客户配置多个tcp-server的域名。
(4) 如何防止DNS劫持，以及加速?
IP直通车，客户端配置多个tcp-server的IP。
(5) 如何保证扩展性?
服务端提供get-tcp-ip接口，向client屏屏蔽负载均衡策略，并实施便捷扩容。
(6) 如何保证高可用?
tcp-server“推”状态给get-tcp-ip接口，
or
get-tcp-ip接口“拉”tcp-server状态。
细节重要，思路比细节更重要。
【本文为专栏作者“58沈剑”原创稿件，转载请联系原作者】
戳这里，看该作者更多好文
