微信架构推测

原文：http://wenku.baidu.com/view/b996a827af45b307e9719700.html

从互联网上分析推论的微信架构,不一定翔实准确。做研究之用。

 

      微信从2011年1月发布以来，在一年之内实现了上亿用户，千万级在线，在苹果中国区App Store月下载量排行第一。 

      腾讯把微信的成功总结为“三位一体”，即产品的精准，项目的敏捷，以及技术的支撑。 敏捷就是试错法，用最快的迭代速度不断追求卓越。敏捷是一种态度，允许发布前十分钟的变更，并给予产品决策以最大的自由度。 

      微信使用的同步协议叫做SYNC，参考了微软的ActiveSync  SYNchronous Communication：同步通信 没有数据发送时，传输线处于MARK状态。为了表示数据传输的开始，发送方先发送一个或两个特殊字符，该字符称为同步字符。当发送方和接收方达到同步后，就可以一个字符接一个字符地发送一大块数据，而不再需要用起始位和停止位了，这样可以明显地提高数据的传输速率。采用同步方式传送数据时，在发送过程中，收发双方还必须用一个时钟进行协调，用于确定串行传输中每一位的位置。接收数据时，接收方可利用同步字符将内部时钟与发送方保持同步，然后将同步字符后面的数据逐位移入，并转换成并行格式，供CPU读取，直至收到结束符为止。用一个Key来实现状态同步。这样一种协议在后台实现上比业界通用方案要复杂许多，但是能把客户端的实现大大简化，同时在很大程度上能够满足iPhone，安卓，塞班等多个操作系统的不同需求。 

      微信秉承“重后台轻客户端”的思路，因为客户端安装在用户手机上，变更成本很高；而后台则可以实现迅速的变更，在不发新版本的情况下实现新功能。以下是一个例子：微信的最初版本是不支持群聊的，第二个版本支持了群聊，但第一版客户端仍然可以在后台的变更处理之下参与群聊，只是不能够发起群聊而已。 

      其服务器端目前获知的几部分分别是三网专用网关服务器、登陆服务器组、负载均衡服务器组，主动推送服务器组、后台数据转换服务器组、存储阵列等几部分。由于目前没有任何能够直接从客户端保存至服务器端的功能，推测其服务方并没有用于数据记录的数据库服务器，而是在登陆服务器组中集成了用户数据库，用来记录用户授权。根据其数据吞吐量推算，服务器总规模应分布在三网不同的机房，总数6640台左右。 

----------------------------

以下引用自： http://blog.csdn.net/chief1985/article/details/7902016

 

下面是个人研究微信android 4.2版本的一些结果，不一定正确。

1. 微信android使用的是amr编码；iphone未知，估计是aac，转码会在微信服务器上完成。android上使用了speex这个库，估计是为了达到边录边发。在服务器做格式转换确实比客户端方便多了，用ffmpeg就可以搞定了，也是瘦客户端的一种思路，而且可以依此延伸很多扩展业务。

 

2. 微信android最新版的数据库依然是sqlite，但文件做了加密，用的是http://sqlcipher.net/

 

3. 微信发送地理位置用的是google地图，网页地址在assets\map\map_cn.html

 

4. 微信的视频通信不是在QQ的基础上做的，而是自己实现的一套，基于speex，webrtc, voip等库。微信和QQ的视频通信和skype相差太远了，特别是网络好的情况下。看来视频通信还是有技术壁垒的，现在只能希望Google将webrtc做成熟一点了。

 

5. 微信使用了一些jni：
    libImgProcess.so 用于gif处理，特别是抠背景。这个微信在一个讲座里面还专门提过。
    libvprotocal.so 用于视频录制，不过这个库效率也不高。录制一分钟的视频，等待压缩要半分钟。干嘛不像Instagram放在后头偷偷去做，或者边做边录。
    libMMProtocalJni.so  用于pcm转amr，不用android系统自带的是因为可以边录边发，这个库也做了插件相关的一些处理
    libvoipMain.so 视频通话
    libvoice.so 视频通话语音处理，用了speex
    libSync.so 用于通讯录同步
    libImgFilter.so 用于图片处理的滤镜
    libmmcrypto.so 数据库加密，其实就是sqlcipher

 

6.  我原先以为微信会在QQ的基础上做视频通话，但实际上它没有，可能是因为这样可以比较独立，不用遵循QQ的协议。不过QQ的协议为了兼容，有了很重的历史包袱，已不太适合新潮流了。微信的视频通话用了两个服务器：punch.weixin.qq.com和voip.weixin.qq.com。这两个服务器主要是为了打洞和握手。

 

7. 从http://timyang.net/architecture/notes-weixin/和腾讯大讲堂的一些资料，谈的比较多的是类Sync协议。从张小龙做邮箱的背景来看，我原本以为会是这样一种协议：每个消息相当于一条邮件，而微信的各个界面相当于邮箱的各个文件夹，例如收件箱，发件箱，垃圾邮件，自定义文件夹等，客户端和服务器端要做的就是做这些文件夹同步，就像rsync一样。但从后面的了解来看，实际上并没有这样做。我觉得用邮件来理解IM系统是最直观的方式，发一条消息相当于发一封邮件，邮件体系里面已经很好地做到了转发，分布式，邮件组，邮件状态等功能，客户端要做的就是同步邮件和联系人等。

 

8. 从微信的发展来看，微信后面应该是朝着平台方向发展，也就是它提供推送和消息发送平台，让其他厂商依此开发应用，发布信息，做活动等。现实中的一句话：要致富，先修路。互联网的路就是互通，就是交流。QQ就是站住了这个先机，所以后面可以做很多其他的事情来赚钱。

 

9. 从现在互联网的发展而言，IM和视频（包括IM里面视频通话）是一个方向，这些都应该成为互联网的基础设施，就像浏览器一样。现在IM还没有一个很好的解决方案，XMPP并不能很好地做到业务逻辑独立开来。从IM的本质来看，IM其实就是将一条消息从一个地方传输到另外一个地方，这个和TCP很像，为什么不实现一个高级点的TCP协议了，只是将TCP/IP里面的IP地址换成了一个类似XMPP的唯一ID而已，其他的很多细节都可以照搬TCP协议。有了这个协议之后，将业务逻辑在现有HTTP server的基础上做，例如发送语音和图片就相当于上传一个文件，服务器在处理完这个文件后就发一条特殊的IM消息。客户端收到这个IM消息后，按照IM消息里面url去HTTP server取语音文件和图片文件。将HTTP server和IM server打通之后，可以做很多事情。但将这个两个server合并在一块并不是一个好事，不然腾讯也不会有2005年的战略转型了。从现在的情况来看，应用除了游戏，都没怎么赚钱，现在能够承载赚钱业务的还是以web为主。IM不可以赚钱，但没有却是不行的，就像一个地方要致富，不修路是不行的道理一样。