中控服务器对公众号上下文的维护的拆分，带来的问题当然是应用层怎么样才能找到指定公众号所需的上下文数据在哪台服务器上呢？偷懒的方案是在公众号对接时直接定死，但是这个方案很容易造成运维阶段的成本浪费，因为公众号的活跃度是不同的，有很多公众号在对接后可能长时间处于不活动状态。而且定死的话你虽然能通过横向扩展增加服务的承载能力，但是没有办法通过增加单台服务器的配置提高既有服务器的承载能力。所以在我们的具体实现中，中控服务器对于公众号上下文的加载和维护都是懒加载的，单台可加载数量可以根据运维期的服务器配置进行调整。

如何使应用层的服务器找到指定公众号上下文在哪台服务器上？其实很简单，增加一个中控服务器路由即可，这个路由服务器必须知道公众号上下文和中控服务器的对应关系，知道它在哪里。是不是每次请求中控服务器都需要经过路由服务器去定位哪？并不需要这样做，只需要在应用层服务器初次定位时到路由服务器上查询即可，后续的通信直接与中控服务器进行。

客厅级的加强版，对所有中控服务器进行一对一的冗余，以防单台故障Out Of Service。

其实这里有一个技术点是要注意的，AccessToken的同步问题，这个问题在上文的门厅级方案中也是一样存在的，冗余的服务器之间如何确保AccessToken是同步的，当然不能各自去调用微信API刷新，后刷新的就把先刷新的冲掉了，所以需要把刷新AccessToken的工作放到中控服务器对外代理中，在其中实现一个队列来处理这件事，并在得到新的AccessToken后，分发到中控服务器。

生活不只是眼前的苟且，还有远方的苟且等着你，慢慢来……

中控服务器的设计实现可以采取不断演进的方式进行，可以随着运维规模的扩大适时迭代，但是必须在前期规划设计时考虑到这些问题，特别是横向扩展的能力。

====

本章节结束。

写一篇文章，加上排版校对大约要用掉六小时左右的时间，你的支持是我最大的动力，对你有帮助的话请点击右下角“推荐”，谢谢。  ：）

欢迎加我QQ交流探讨，共同学习：279060597，另外我在南京，有南京的朋友吗？