微信可能是国内最早一批做微服务架构体系的，毕竟微服务的理念与腾讯一直倡导的“大系统小做”有很多相通之处，当然微信的功能有很多，衣食住行都能找到入口。我们今天单说它的原生功能：即时通信。
    这块内容本座想分两部分来讲，第一部分是点到点聊天，第二部分是群组聊天。这两种聊天模式有共同点，比如说已读信息不会在服务端保留，因此换新手机是找不到历史消息的。也有不同点，比如服务端的架构和数据流等等。
    先说点到点聊天，手机端通过打开微信软件建立了到腾讯云的微信网关，当然考虑到就近访问与负载平衡，不同客户端可能连到不同的网关。当A用户通过网关B发送微信给在线用户B时，会话微服务会记录当前所有用户的连入信息，维护如下的用户-网关表：

用户 网关
A B
B C
C C

    如果对端用户不在线，则会记录上次连接的网关，如果从来没在线过则随机分配网关。这张表虽然有高达10亿的记录（微信用户数量），但好在只是一张二维表而且可做冷热分离，因此存储量并不大，然后各个网关上会有热数据的分布式缓存。
    为什么要这样做呢，因为我们知道让一台网关服务器来维持每一个客户端的TCP连接是非常消耗内存的，鉴于微信用户的数量，一般硬件的性能是无法达到的，因此通过会话微服务来记录这些信息可以很好地为网关减负。

   接下来当消息进入到会话微服务找到B对应的网关，然后通过该网关将消息传递给B用户。
    等等，什么，网关在没有用户请求的情况下还能直接给用户发消息，这是我认识的CS架构么？当然通过长轮询（Long Polling）可以定期从服务端拉数据，但这就影响了消息的实时性了。传统的HTTP看似无法实现了，我们想到的办法是WebSocket（WSS）。WSS是通过单个TCP连接提供全双工（双向通信）通信信道的计算机通信协议。它允许用户和服务器之间的流连接，并允许即时信息交换。
    Ok，消息传递到在线用户B了，B用户回复给服务器“已收到”的回执（不论已读还是未读），会话服务器再以WSS形式将回执转发给A。当然如果B用户离线，消息会存放在消息数据库中直到过期（三天？）。因此点对点聊天在服务器上并不消耗太多的存储资源。

    接下去我们说说群组消息，当会话微服务识别到消息的接收方是一个群组时，会去调用群组微服务，群组微服务的表结构是一张一对多的分布式数据表：

群组ID 用户
XXX A
XXX B
XXX C
YYY C
YYY D
YYY E

    得到目标群的用户列表后，会话微服务再查询自己的会话数据库找到用户对应的网关，通过WebSocket的形式发送给该群组的所有成员。

   当然就像新浪在李晨发“我们”，鹿晗发“官宣”，中国国家男子足球队发“对不起”的时候会发生服务器宕机现象，新浪的处理方式是将粉丝群切片，分批次发给不同子群。微信也会在成员过多的群通过异步的消息队列进行批量组播，但即便如此，与点到点微信不同的是，网关的负担会大很多，因此除了将会话微服务从网关上拆解，还需要进一步将验证服务、语义分析服务（各种网络协议的解包）从网关服务器上拆解下来，由此就形成了微信的群族消息的数据流。