讲座《微信之道：至简》总结

前言：下面的观点来自个人对本次讲座的理解，有不当之处，望大家指正。本次讲座很多技术我都是第一次听说，总结的同时有很多的疑问，如遇高手闲暇之余能为我解惑，倍感荣幸。愿意指点一二的前辈，也可以阅读文章最后我留下来的疑问。

3月27号，提前一个小时下班，前往中山大学参加腾讯大讲堂《微信之道：至简》讲座。大厅内人山人海，主讲人微信技术总监周颢（harvey zhou）也甚是激动，夸赞大家的学习热情。周颢讲到微信的成功可归结为三点：产品的精准，项目的敏捷，技术的支撑。

要素一：产品的精准
从对国外应用Kik敏感的嗅觉，到微信从无到有的建设，实用的功能，简单的操作，是微信成功的关键。微信一直以来秉承着“用简单的规则构造复杂的产品”的理念，才有了今天小小的成功。这句话道理简单，但道路艰难。


要素二：项目的敏捷
敏捷开发主要借助一种技巧Scrum，它不同于那种一次制定几年开发计划的方式，取而代之的方法是建立不同的发布版本，持续不断的改进软件系统。将大目标分解成简单的小目标，通过几天地冲刺完成一个小目标，通过完成几个小目标进而完成一个大目标。

科技蓬勃发展的今天，人们的注意力会被更加新奇的东西吸引。巨人柯达都倒下了，如果你还想踏着他的尸体继续前进，那你就需要更多努力、更多尝试。只有在同样的时间比别人做更多地尝试，你才有更大的概率成功。也就是说一要有多尝试决心；二要有多尝试的能力。

敏捷就是一种态度，你需要允许发布前十分钟需求做变更，给予产品决策的最大自由度；同时敏捷也是试错法，他可以帮助你在更短的时间，做更多的尝试，走正确的道路。

当然想要在更短时间比别人做的更多，并不意味着要不断地加班，如果有强大的技术支持，那就会事半功倍。


要素三：技术的支撑
技术支撑其宗旨在于剥离复杂，让剩下的更简单。也就是将复杂的东西封装起来或拆分开来，让其变得更加简单易用，同时具备一定的灵活性。如果一个东西本来挺简单，将其抽象化后变得晦涩难懂，那就说明这个抽象是有问题的。微信的技术要点可概括为：
1、大系统小做
2、让一切可扩展
3、提供基础组件
4、轻松的上线

技术•大系统小做
将系统分离成几个独立的模块设计，并且分开部署。但物理上的分离越细，其维护的成本就越高。所以我们可以采用折中方案，适当地分离，然后将不同的模块混搭在一起。

技术•让一切可扩展
1、网络协议可扩展。
2、数据存储可扩展。采用key¬-value的形式存储数据，提供类似SQL的操作方式。

技术•基础组件
1、针对网络协议的Client/Server代码自动生成工具。
2、逻辑容器。
3、监控报表组件，可以做到5分钟添加一个报表，1分钟出监控数据。
4、存储组件，主要用于容灾。

技术•轻松的上线
灰度发布，即每次更新一部分服务器。监控其运行状况，然后调整，再发布，再监控……直到稳定，才更新所有的服务器。及时的监控加上灰度发布，让用户还没有感觉到异常，就将其消灭。

以上提及的这些技术，其复杂点在于：
1、协议
2、容灾
3、前轻后重
4、监控

复杂点•协议（不太懂）
1、CMWAP vs CMNET
CMNET、CMWAP都是上网使用的接入点的名称。通过CMNET可以获得完全的Internet访问权，通过CMWAP只能访问WAP网站，不过 CMWAP使用HTTP代理协议和WAP网关协议可以访问到Internet，而CMNET则适用于所有协议，它是标准的TCP/IP协议。
2、在线 vs 离线
在线和离线的含义越来越模糊，用户可能同时开启多个应用，而一个时间只能激活一个应用，其他应用则在后台运行，用户可以在任何时候切换到其他应用（比如：微信），这时要求用户在该应用上还是处于登录状态。个人认为，应用在后台运行时，可认为用户是发呆状态。
3、资费敏感
这就要求用户请求/服务器回传的数据应该尽量的小。
4、连接不稳定
5、高延时

已有的协议标准（XMPP, SIP/SIMPLE）简单，但占用流量大，消息不可靠。因此微信采用了自主研发的SYNC协议，他通过“握手”来同步消息，采用Server通知/Client主动获取的交互方式。其优点包括：简化交互方式、增量传输数据、可靠有序传输、消息重传控制。

复杂点•容灾
对微信来说用户体验是至关重要的，因此服务应该保持高度的可用性，一定要响应用户。为了降低出错的概率，我们将相同的业务分布在不同机器上，机器A坏了，可以让机器B继续处理业务。 但是由于分布式的运用，A和B可能会出现数据不一致的问题。当然可以通过同步来保证数据一致，但这样又会由于同步导致服务长时间不响应，甚至不可用，或者产生牵一发而动全身的影响（同步一般需要在单点进行，如果这个点宕掉了，整个个业务也就宕掉了）。

上面描述的其实是一个分布式的CAP理论。Brewer认为在分布式的环境下设计和部署系统时，有3个核心的系统需求，以一种特殊的关系存在。这三个核心需求是：Consistency，Availability和Partition Tolerance，而这三个需求无法同时满足。在微信的设计中，放弃了一致性Consistency，主要考虑3点：
1、防止雪崩，避免蝴蝶效应
问题发生时，用户会不断的重试，导致请求数增加，而单个服务器的性能也会大幅下降。
2、柔性可用，追求不完美
不能因为一个功能不可用，导致其他功能也不能用。应该忽略小错误，保持应用整体可用。
3、保护点前置，赢得处理空间
在接入层处理问题，比如使用GSLB(Gobal Server Load Balance)/ LVS(Linux Virtual Server) / IP Redirect/ Client Retry。

存储层容灾是相对复杂的，需要分而治之。可以下面3种方案，而微信采用的是最后一种方案。
方案一：主从模式

优点：简单
缺点：故障时不可写
场景：帐号系统

方案二：双写模式

优点：简单、故障时可写
缺点：数据会轻度丢失
场景：用户终端的记录


方案三：主从+多写模式

优点：故障时，仍有很好的概率可读可写
缺点：多服务器的维护成本
原理：R+W>N && R > W（Quorum算法），假设有一个子存储业务有10个节点（N），每次写操作时同时向5个节点写入数据（W），每次读操作同时向6个节点读取数据（R）。这样总是能保证至少一个节点读取的数据是最新的，而这种做法读取到错误数据的几率非常之小。
难点：第一，要能判断读出的哪个节点的数据是最新的；第二：每次向不同的节点随机写数据可能存在冲突；第三：节点宕掉如何恢复。
解决：当然Quorum算法均给出了相关的解决方案，但现实相对复杂，微信技术团队想出了一种Simple Quorum的实现。从harvey（主讲人周颢）的描述中，我大概猜到他是这么做的。首先有个全局的序列发生器（高度稳定、一致），保证系统每次接收用户请求或存储数据都能产生一个递增的序列号，这样通过对比数据的序列号，就知道那个节点的数据是最新的了；其次存储数据时，可以选择一次存储单个实体（比如：用户）的所有数据，而不是修改某个字段，这样就不存在冲突问题；最后，保证每个节点都只存储少量数据（比如：200K），可以通过直接拷贝数据的方式恢复。下图给出如何判断读出的哪个节点的数据是最新的。

图一，生成序列号的过程：


图二，判断最新数据的过程：


复杂点•前轻后重
客户端应该尽量的简单，而服务端承载更多的功能。这样更新功能更加容易，且客户端不容易崩溃。


复杂点•监控
监控需要将多项数据以图表的形式实时呈现，并且通过实时数据和历史平均值的对比，实现对异常的自动预警和报警。

另外，监控不等于统计，监控分析的实时的数据，而统计做的是海量数据非实时的分析。


疑问：
1、分布式系统中那么多服务器，怎么来统一维护，需要用到什么技术？
2、一个产品如果需要监控，哪些基本的数据需要做监控呢？这些数据又从哪里来？远程监控又如何做？
3、求这次演讲的PPT？本人联系方式350653546__qq.com，请把__替换成@再发送邮件。
4、如没有时间详细指点在下的话，为我指明方向也不甚感激。


后话：演讲结束后有个提问环节，有同学提到腾讯抄袭和一家独大的问题，harvey（主讲人周颢）做了很好的回应。这里我也说说，正如harvey所讲，抄袭和超越是有很大区别的，只有用心做产品的人才能把产品做强做大。腾讯的平台和用户群是有力的竞争筹码，但这也是腾讯多年来辛勤耕耘的成果，前人栽树后人乘凉，而且用户也不能否认产品结合腾讯的平台带来的便利。至于一家独大嘛，我想说柯达和诺基亚也够大，但现在呢？技术的更迭是迅速的，正所谓生于忧患，死于安乐，所以大家努力吧！最后感谢腾讯的开放，感谢harvey给我们深入浅出地讲解这么多宝贵的知识，也感谢我的大学同学孙业军为我提供这次讲座的报名信息。

评论

2 楼 jxwnhj0717 2012-04-12  

原PPT已打包成 微信之道——至简.rar

1 楼 super_thinker 2012-04-10  

我就是需要感谢的人 谢谢大家