分布式服务心里路程

16年4月开始做即时通讯到现在，把所学所用粗略记录一下。已经做了差不多2年的im，从刚刚进入公司的框架搭建到整个框架的稳定与稳定运行，用了不少努力，现在已经完成了整个框架，记录一下那逝去的青春。

Q1：服务器间如何保证服务器高可用
A1：服务器高可用为系统某个服务器出现问题时，不会因该服务器出现问题而导致系统不可用。因此需要服务器节点在系统中可动态进行增加与删除。从而达到系统中一直存在可服务的服务器进行消息处理。而本系统针对服务器发现方式为通过命令字进行注册，服务器在心跳时，进行命令字注册至proxy，保证了服务器的动态增加与删除。
以下为服务器注意点：
服务器负载均衡：
当用户过大，则需要考虑服务器的负载均衡，本系统中的服务器处理性能建议配置如下(以6w同时在线数量并发为例)：
1、1台access_server服务器服务人数为2W，简单逻辑处理服务器服务人数2W，与redis操作相关服务器服务器人数1.5W。聊天服务器1w，聊天记录数据层：1w，proxy服务器服务人数6w。
系统中完整的服务器配置为：3台access，3台相同类型逻辑层服务器，4台数据层服务器，1台逻辑层proxy，1台数据层proxy，1台聊天proxy。

2、服务器内部，负责均衡只要依靠一致性哈希及动态注册注销就可达到。
3、用户的负责均衡，用户登录前，需要进行服务器选服，选服可动态分配用户链接到不同的access服务器，而经过access链接后，消息进入系统中，服务器已经实现负载均衡，进而完成用户的负载均衡。此时，该负载均衡为同一数据库的负载均衡。
4、数据库也是有限制的，需要引入集群概念，因此视具体业务需求而定义一个集群的用户数量，操作数据库不是太频繁的，可为100w用户1个集群。当用户量达到了100w，则使用不同的数据库，此时会涉及跨集群通讯。此时选服也要根据集群进行选服不同的access服务器。(跨集群概念可映射为跨国通讯，1个国家1(N)个集群,实现全球系统数据互通业务。此时跨集群业务数据较小，基本都是当地国家的用户进行服务即可。不会因国际网络影响用户体验。)，国内通讯的跨集群也是如此，可以设计为不同区域根据ip进行用户区分为不同的集群。

选服服务器的服务器发现及选服规则：
server长链接至选服服务器，并根据心跳附带服务器信息至选服服务器。信息包含：集群号，服务器类型，服务器实例号，服务器所在ip，服务器监听port，服务器最大可链接数量，服务器当前可链接数量，服务器版本号。
选服服务器根据上报的服务器信息为用户选择适当的接入服务器。

服务器启停：
1、相同类型的服务器且实例序号不能完全相同，如果完全相同，则以最后启动的实例为有效实例。
2、proxy查询服务器是根据command->svr_type，所以新增命令字时，proxy根据command查询至对应的server，并转发相应消息。因此，相同命令字不可以在不同类型的服务器中注册，否则消息会可能转发错误。
服务器热升级：
为了避免消息丢失，服务器升级时，首先触发热升级信号，则server主动上报proxy使proxy不会再把请求消息转发至该server中，当server根据请求消息已经处理完毕(buffer已经全部释放)，则主动退出程序，保证了server所有请求消息处理的完整性。因服务器间为一致性哈希方式，所以并不会影响用户的消息处理。
用户与系统服务器解耦：
在服务器服务过程中，如果想临时升级某个服务器，而希望系统进行平滑升级，该如何实现，如果系统服务器间联系太过紧密，服务器的启停会影响用户使用，用户体验会非常不好，因此，系统设计为，接入服务器保持与用户进行长连接，并且服务器中记录用户信息与该服务器信息，而用户登录完成后，如果不操作，则只有与接入服务器access进行心跳保持连接，而其他的服务器无论如何变化，都不会影响该服务器，系统中服务器也是使用一致性哈希方式进行服务器发现，所以可以进行平滑升级。而针对用户在线状态服务器，对用户在线情况关系比较密切，为了避免用户状态有误，因此需要增加校验用户状态流程：1、用户主动触发上下线后，上报用户状态。2、access服务器定时上报本服务器链接用户的状态至用户状态服务器，如果用户状态发生变化，则更新用户状态信息，并写入redis中。进行同步用户状态。
服务器链接：
启动一个proxy，实现了服务器间的单通道通讯模式，链接2个以上的proxy可以实现多通道通讯模式。
1、为了保证服务器高可用，最好每个服务器连接的proxy为2个，而多个prox为多个连接池的概念，当其中一个链接断开后，会使用正常链接的链路，保证了只有1个链路的而导致消息有可能不可被处理的问题。
2、proxy升级：
A、当我们只连接一个proxy，如果我们要升级proxy，则会导致升级proxy时，服务器会暂时停止服务。
B、如果连接2个以上proxy，则可以进行proxy平滑升级，例如我们存在proxy1，proxy2，而我们要进行proxy升级，而不影响server的服务，我们可以先关闭proxy1，而proxy2还在正常处理，从而替换了服务器后，重新启动proxy1，目前设计为服务器检测到proxy断开后10s进行重连，因此，启动proxy1后，建议至少10s后进行proxy2进行升级。从而实现proxy的平滑升级。而系统中相同proxy数量越多，则高可用更稳定。
3、server升级：
A、升级通用型服务器(除接入层对客户端进行长连接的服务器：access_server.)，不同类型的服务器类型，建议开启2个实例以上。当要进行server升级时，先发送信号，使其通知proxy，消息不再分发至该server，当升级server消息处理结束后，则server平滑退出，而后进行server文件替换进行server升级。依次进行其他服务器升级，proxy根据命令字处理方式，支持可动态进行server节点的新增与删除。
B、升级access_server，因为access_server为针对客户端的长链接，暂不支持热升级。整个系统只有该服务器面对用户，因此要升级该server，建议通知客户，服务器进行整体服务器升级时进行升级。