从 GitHub 上可以看出，到目前为止，由腾讯微信团队发起的开源项目已经有 6 个，并且这其中大部分都是在 2016 年开源的，领域涉及移动、数据库、基础类库、框架。中国大公司的开源曾经给社区留下不好的印象，比如有人就这么说，大公司的开源，开源也就意味着结束。也有人说，大公司的开源大部分都是 KPI 项目，开源与业务不能相得益彰，所以根本无法持续投入。
相比来说，Facebook 就是互联网公司里的开源大户，目前他们的开源项目已经有近 300 个。对于为什么要发布开源项目，Facebook 开源项目负责人也曾经解释过，总结起来说有三点，一是开源能够帮助他人更快地开发软件，促进世界创新，主要是社会价值层面的考虑。二是开源能够倒逼 Facebook 的工程师写出更好的代码。三是开源能够更有效利用社区的力量，帮助 Facebook 一起解决难题。
那微信是如何理解开源这件事，以及他们未来准备通过哪种机制保证开源项目的健康发展，带着这些问题，InfoQ 记者采访了微信终端团队的负责人赵原。
赵原认为开源不仅是一种态度，更是一种能力，微信希望通过开源打通内部团队和外部社区，一方面可以把微信的顶级技术输出给了社区，另一方面也可以把外部的优秀的思想传递到内部团队。对于开源的理解，赵原这样解释：
第一个关键词价值。微信团队通过将内部的研究成功优化、整合，并输出，以帮助更多的开发者更方便地构建他们的软件。工程师之间最好的交流媒介就是代码，通过代码，微信团队可以将他们的技术思想传递到社区，并影响更多的人。
第二个关键词优势。微信最大的优势是有海量的用户，很多外界开发者根本没有发现或者遇到过的复杂问题，微信团队都早已经解决掉了，比如在移动开发领域的系统兼容性、用户多样化的网络环境等问题。通过开源，微信不仅可以授之以鱼，还可以授之以渔。
第三个关键词活力，微信开源的项目必须来自微信，最后必须在微信落地。开源项目最怕没人维护，通过产品迭代，这些开源的项目持续的更新，给他们一个心跳的机制，使他们依然有活力。
第四个关键词易用。一个优秀程序员可以花上很多的时间研究微信开放的技术源码的技术思想和设计。但对于不是很有技术实力的开发人员，是否能从微信的开源项目中依然获益呢？答案是肯定的。他可以将微信开源的项目引入在自己的 APP 中，将微信很多的能力运用在自己的 APP 中。
而对于项目开源之后的运营问题，赵原也做了思考：
活力，不得不提起一个尖锐的问题，在大公司里面做开源项目，开源通常意味着这个项目的结束。优秀的开源项目意味着开始，和大公司里的开源项目做法天生有一些冲突。
第一大公司里面做开源项目其实是有一些短期 KPI 导向的短期项目，开源项目需要持续的人力投入在其中。第二个问题，每一个团队里面员工开发的精力是有限的，做技术研究的时候，需要花很多时间在供应商的开发，这是从员工方面看开发精力的冲突。第三大公司内通常有完备的开发体系，而这些开发是封闭的，很难说和外部的开源体系对接起来。
今天看这个问题，微信也想过很暴力、很简单的想法，比如说团队 10 个人，这 10 个人可以做功能开发，如果为了解决这个问题，再招 10 个员工砸在开源项目上，大公司可能最不缺的就是人力，问题是在大公司里面看上去是可以解决的，但放在微信上面却觉得行不通，微信讲究小团队作战，讲究精兵策略，不浪费一兵一卒。
为了解决这个问题，微信在开发 Tinker 项目的过程中，大概用了快一年的时间解决，其实解决问题的方法很简单。简而言之，就是将微信的开发团队改造成一个开源化的开发模式。
微信通过对内部系统的改造，使内部的开发和外部的开发模式基本没什么不同。一份代码，既可以在微信中使用，也可以在外部的开发者中使用，这科技减少额外的人力投入。
另外微信还收获了很多价值。比如外部的开发者还可以提供一些微信团队没有发现的问题，对于微信来说是一个很好的优化 bug 的渠道。通过与外部社区的深入交流，团队的学习能力也能得到很大提升。
下面是 InfoQ 编辑整理的微信现有的比较活跃的开源项目列表，欢迎交流讨论。
C/C 协程库 Libco
Libco 是微信后台大规模使用的C/C 协程库，2013 年至今稳定运行在微信后台的数万台机器上。Libco 提供了完善的协程编程接口、常用的 Socket 族函数 Hook 等，使得业务可用同步编程模型快速迭代开发。
早期微信后台因为业务需求复杂多变、产品要求快速迭代等需求，大部分模块都采用了半同步半异步模型。接入层为异步模型，业务逻辑层则是同步的多进程或多线程模型，业务逻辑的并发能力只有几十到几百。随着微信业务的增长，系统规模变得越来越庞大，每个模块很容易受到后端服务/网络抖动的影响。基于这样的背景，微信开发了 Libco，实现了对业务逻辑非侵入的异步化改造。
GitHub 地址：https://github.com/tencent/libco
Star 数量：1043
生产级 paxos 类库 PhxPaxos
PhxPaxos 是微信后台团队自主研发的一套基于 Paxos 协议的多机状态拷贝类库。它以库函数的方式嵌入到开发者的代码当中，使得一些单机状态服务可以扩展到多机器，从而获得强一致性的多副本以及自动容灾的特性。PhxPaxos 在微信服务里面经过一系列的工程验证和大量的恶劣环境下的测试，在一致性的保证上极为健壮。
PhxPaxos 的特性包括使用基于消息传递机制的纯异步工程架构、每次写盘使用 fsync 严格保证正确性、支持 Checkpoint 以及对 PaxosLog 的自动清理、使用点对点流式协议进行快速学习、支持跨机器的 Checkpoint 自动拉取、内置 Master 选举功能、自适应的过载保护等。
GitHub 地址：https://github.com/tencent-wechat/phxpaxos
Star 数量：970
高可用、强一致的 MySQL 集群：PhxSQL
PhxSQL 是一个兼容 MySQL、服务高可用、数据强一致的关系型数据库集群。PhxSQL 以单 Master 多 Slave 方式部署，在集群内超过一半机器存活的情况下、即可提供服务，并且自身实现自动 Master 切换、保证数据一致性。PhxSQL 不依赖于 ZooKeeper 等任何第三方做存活检测及选主。PhxSQL 基于 MySQL 的一个分支 Percona 5.6 开发，功能和实现与 MySQL 基本一致。
MySQL 主备在主机上支持完整 SQL、全局事务、以 repeatable read 和 serializable 级别的事务隔离，在金融、帐号等关键业务中有巨大的价值。但是 MySQL 传统主备方案也有其缺点。最明显的就是主机故障后的自动换主和新旧主数据一致性，即所谓的一致性和可用性。为了解决这个问题，并同时完全兼容 MySQL，微信在 MySQL 的基础上应用 Paxos，设计和开发了 PhxSQL。
GitHub 地址：https://github.com/tencent-wechat/phxsql
Star 数量：1485
RPC 框架：PhxRPC
PhxRPC 是微信后台团队推出的一个简洁小巧的 RPC 框架，编译生成的库只有 450K（编译只依赖第三方库 Protobuf）。PhxRPC 的特性如下：
- 使用 Protobuf 作为 IDL 用于描述 RPC 接口以及通信数据结构。
- 基于 Protobuf 文件自动生成 Client 以及 Server 接口，用于 Client 的构建，以及 Server 的实现。
- 半同步半异步模式，采用独立多 IO 线程，通过 Epoll 管理请求的接入以及读写，工作线程采用固定线程池。IO 线程与工作线程通过内存队列进行交互。
- 提供完善的过载保护，无需配置阈值，支持动态自适应拒绝请求。
- 提供简易的 Client/Server 配置读入方式。
- 基于 lambda 函数实现并发访问 Server，可以非常方便地实现 Google 提出的 Backup Requests 模式。
GitHub 地址：https://github.com/tencent-wechat/phxrpc
Star 数量：467
终端跨平台网络组件：Mars
Mars 是微信官方的终端基础组件，是一个结合移动应用所设计的基于 Socket 层的解决方案，在网络调优方面有更好的可控性，采用 C 开发。目前已接入微信 Android、iOS、Mac、Windows、WP 等客户端。
在微信中，任何网络实现的 bug 都可能导致重大事故。例如微信的容灾实现，如果因为版本的实现差异，导致某些版本上无法进行容灾恢复，将会严重的影响用户体验。微信研发了统一的跨平台的网络基础库 Mars 来满足发展的需要，一方面，基础组件可以提高研发效率，另外一方面，也可以提高系统的稳健性。
在设计上，Mars 以跨平台、跨业务为前提，遵从高可用，高性能，负载均衡的设计原则。以网络的可用性为例，移动互联网有着丢包率高、带宽受限、延迟波动、第三方影响等特点，使得网络的可用性，尤其是弱网络下的可用性变得尤为关键。Mars 的 STN 组件作为基于 socket 层的网络解决方案，在很多细节设计上会充分考虑弱网络下的可用性。
GitHub 地址：https://github.com/Tencent/mars
Star 数量：5895
热补丁技术 Tinker
Tinker 是微信官方的 Android 热补丁解决方案，它支持动态下发代码、So 库以及资源，让应用能够在不需要重新安装的情况下实现更新。
当前市面的热补丁方案有很多，其中比较出名的有阿里的 AndFix、美团的 Robust 以及 QZone 的超级补丁方案，但它们都存在无法解决的问题，所以微信研发了自己的解决方案。总的来说，AndFix 作为 native 解决方案，首先面临的是稳定性与兼容性问题，更重要的是它无法实现类替换，它是需要大量额外的开发成本的。而 Robust 兼容性与成功率较高，但是它与 AndFix 一样，无法新增变量与类只能用做的 bugFix 方案。Qzone 方案可以做到发布产品功能，但是它主要问题是插桩带来 Dalvik 的性能问题，以及为了解决 Art 下内存地址问题而导致补丁包急速增大的。
Tinker 的具体设计目标如下：
- 开发透明：开发者无需关心是否在补丁版本，他可以随意修改，不由框架限制。
- 性能无影响：补丁框架不能对应用带来性能损耗。
- 完整支持：支持代码，So 库以及资源的修复，可以发布功能。
- 补丁大小较小： 补丁大小应该尽量的小，提高升级率。
- 稳定，兼容性好：保证微信的数亿用户的使用，尽量减少反射。
GitHub 地址：https://github.com/Tencent/tinker
Star 数量：6707