微信平台的建设 第1篇
微信在过去十年中的飞速崛起，从一个简单的即时通讯应用发展成为一个全方位的数字宇宙，让许多人对它的未来轨迹充满了好奇。站在2024年的门槛上，让我们深入探讨塑造微信发展道路的趋势以及未来一年的预测。
微信的生态体系将继续向着视频化和智能化的方向发展。微信已经加快了智能化和视频化的步伐，推出了视频号、小程序直播购物车等创新功能。未来，我们可以期待微信生态进一步整合视频和智能技术，为用户和商家提供更丰富、更智能的交互体验。例如，通过AI技术实现更精准的内容推荐，通过视频直播实现更真实的商品展示和互动。
微信的商业化探索将不断深化。微信已经展现了其强大的商业化潜力，从微信支付到小程序电商，再到视频号的商业变现，微信正在不断拓宽其商业化道路。未来，我们可以预见到微信生态将进一步深化商业化探索，为广告主、商家和从业者提供更多的赚钱机会。另外，微信的技术创新也将是推动其未来发展的重要动力。微信视频号行业在技术创新方面不断取得突破，如人工智能、大数据等技术的应用，提升了内容推荐精准度和用户体验。这些技术创新不仅将提升微信的功能和性能，还将为用户和商家带来更加便捷、高效的服务。
微信也将继续加强其全球扩张的步伐。随着微信在国内市场的成功，它已经开始将目光投向全球市场。未来，我们可以期待微信在全球市场的表现更加出色，为全球用户提供更加优质的服务和体验。
微信的发展也将受到一些挑战和限制。例如，随着网络安全和隐私保护问题的日益突出，微信需要更加注重用户数据的安全和隐私保护。同时，随着全球监管环境的变化，微信也需要遵守更加严格的监管规定和法律法规。
预测的2024年微信增长领域或功能
微信平台的建设 第2篇
多主系统收益很大，可以分为几个点。 一是7×24小时的可用性，它可以应对有计划和无计划的停机维护。不再有封尘已久的切换流程，由于多主可用，类似快照与数据对齐等行为，已经在在线核心逻辑中充分体现。其次是变更发布，因为这些系统写出来并非一直不变，最大的可用性需求是来自于我们的程序版本发布。 第二点是资源调度，当系统变多主之后，相当于有了多台随时都可以用的机器，它们的模式都是一样的，为了回避弱的节点去使用更多计算资源，只要切流量就可以了。所以切存储跟切逻辑是一样的，统称为切流量。 最后一点是成本，多主系统的预留冗余成本是相对低的，因为所有的机器都可以服务用户，所以在多主系统方面我们只需预留1/3的成本即可。 设计与实践
微信的设计主要分为三大块： 第一，实现同步复制，在数据分区内部实现完整ACID语义，维护细粒度的海量数据分区，且每一次数据读写都基于非租约的Paxos交互实现，每分钟超过百亿次。 第二，存储引擎方面，针对微信丰富的业务场景，设计多种高性能的存储模型，其次，我们还支持单表过亿行的二维表格/FIFO队列/key-value等数据结构。 第三，负载均衡方面，我们希望存储系统可以动态切换计算资源，数据节点动态计算负载能力尽力服务，超过服务能力部分自动转移到其他复制节点。 实际成果
目前微信的实际成果，核心数据存储服务可用性达6个9。整个系统有一个创新的技术点，具体细节我们发表在： 论文相关示例代码开源：。 早期大家对Paxos算法都是认为很难实现的，近两年逐渐有一些公司开始对这方面有一些分享。上面提到的这个论文是微信PaxosStore的一点创新，贡献出了一些简洁的算法实现流程，大家可以很轻松的去理解和实现。 PaxosStore广泛支持微信在线应用
这些数据的应用基本都是PaxosStore在支持。 PaxosStore整体架构
下面，简单介绍下PaxosStore的整体架构。 分成几个园区，园区必须有独立的网络和电力。 举个例子，假设有些机房实际上共享了一套电力甚至交换机的话，只要单点故障一样会挂掉。 所以，园区只是一个概念，至少要满足网络和电力独立，然后在考虑跨层或跨省的问题，PaxosStore实际上也有跨华东，华南，华北三个遥远距离的服务。 中间我们会把PaxosStore共识层和计算层、存储层分离起来，PaxosStore其实是一整套框架，它可以容纳不同的共识算法和存储。 下面是一个存储引擎。微信的存储引擎包括很多种，最早是Bitcask模型，现在广泛使用的是LSM，它可以支持比较多的业务。 最下面是迁移系统、备份系统、路由中心。 PaxosStore支持类SQL的filter，format，limit，groupby等能力，单表可以支持亿行记录。下一步，我们可能会根据业务的需求去开展。 PaxosStore：数据分布与复制
这一套分布式，其实是延伸了之前老系统的分布方式，数据会分成两层，它会按一致性hash划分到不同的节点。每个节点都有六个节点，它们交叉实现了复制的逻辑，可以达到一个比较好的负载均衡。 基于PaxosStore的在线基础组件
2017年之后，将整个微信90%的存储切完后，继续往下发展。随着业务的发展，我们把很多的立体图连起来。有了PaxosStore框架之后，很多系统都相对容易实现，像比较典型的zookeeper、hdfs、hbase等。 除了基本的数据系统之外，我们还有很多特殊的场景，例如远距离跨省常量存储。如，微信支付订单等场景，都有强烈的数据库需求，而且需要跨省容灾。 什么是远距离？考虑到故障的实际影响范围以及专线的物理情况，在地点的选择上，是有一定要求的，因此，在选点的选择上，一般选在整个中国跨越比较远的一些地方，如，上海、深圳、天津，构成了一个三角，相互间距大概2000公里左右。但有个实际问题，如果跨省，必须给它大概三四十毫秒左右的延迟。另外，像深圳跟汕头，上海跟天津，这些都不算远距离跨省。如果上海挂了，杭州的线也一定会出现问题，因为它俩距离比较近。 常量存储有什么特点？它的写需要有跨越三四十毫秒的跨城通信过程，但读是本地的。 另外，我们还针对微信支付复杂业务定制了事务容器以及针对搜索推荐业务的高性能特征存储。 微信chubby
Chubby是Google一个论文提到的系统，我们也延伸了这样一个逻辑，基本上跟它的接口是一样的。 当时，我们有一个很奇怪的发现，不管是Google Chubby论文提到的代码量还是zookeeper的实际代码量都很大，但有了PaxosStore之后，根本不需要那么多的代码，所以接下来我们的处理也可能会考虑开源。 然后，我们基于PaxosStore也实现了分布式文件存储。 微信分布式文件系统
微信分布式文件系统Namenode 基于PaxosStore，DataNode基于Raft协议。Raft是基于租约机制的完美实现。基于Raft我们可以做到DataNode的强一致写。另外，它支持文件AppendWrite和随机读以及文件回收等功能。 分布式表格：架构图
这个其实对应的是hbase。我们也基于PaxosStore去做了它的核心部分，然后把整套实现起来。 微服务框架
我们数据存储跟微服务架构是两大块。微服务包含了服务定义、服务发现、错误重试、监控容灾、灰度发布等一系列面向服务的高级特性的统一框架。中间有一个配置管理和下发的过程，这一块也是PaxosStore实现的，它可以完全控制代码的安全性。 下面是一个发布的过程，因为微信有很多台服务器，之前我们也有一个资源化系统，有可能一个服务会横跨几千台机器，这时候，发布一个二进制，只能在几百兆时间内，所以，内部也是一套BT协议。 然后，我们有一些监控处理，最后我们会有过载保护保护，在系统里面过载保护是很关键的一块。因为在后台，当一个请求过来的时候，某些节点产生了一个慢延迟和性能差，就会影响整条链路，所以我们会有一个整套的过载保护的实现。 业务逻辑Worker模型选择
一般开源的东西就是在对标谁的性能高，但是在实际的后台服务当中，你的可用性要求都会很高。 所以我们会分成两种不同的服务，PaxosStore是比较重要的核心服务，使用多线程。但是在大量的应用开发中，我们始终是多进程的服务，而且多进程框架是可以定时重启的。 多进程的一个重点就在于内存泄漏与coredump容忍度很高，在快速开发特性时候尤其重要。 最后，不管是多进程还是多线程，都类似一个协程的处理，可以把我们的并发能力提得很高。 Libco背景
协程是在2013、2014年开始构建的。2013年，开始运行在微信的后台。基于2013年的那一次故障， 我们开始整体优化微信后台的过载保护能力，也促使我们去提升整个微信后台的高并发能力。 思考了几个月后，总结两个方法，一个是把整个代码逐步重构成一个异步模型，但这个工程量巨大。第二个是，去探索协程解决方案，少量修改代码达到同步编码，异步执行效果。但当时采取这个方案的案例不太多，所以，我们也很担心。 举个例子，如果把Leveldb的本地文件切换为远程文件系统，那么异步代码如何实现？协程如何实现？ 异步服务与协程服务的对比
传统基于事件驱动的异步网络服务优势高、性能高、CPU利用率高，但编写困难，需要业务层维护状态机，业务逻辑被异步编码拆分得支离破碎。Future/promise等技术，趋近于同步编程，但仍然繁琐，并且并发任务难以编写与维护。 协程服务，同步编程、异步执行，由于不需要自己设计各种状态保存数据结构，临时状态/变量在一片连续的栈中分配，性能比手写异步通常要高，重要的一点是编写并发任务很方便。 协程定义
协程到底是什么？可以说它是微线程，也可以说它是用户态线程。协程切换流程其实不复杂，它主要任务是把上下文保存起来。上下文只有两个部分，第一部分是内存和寄存器，第二部分是栈的状态。
微信平台的建设 第3篇
这是主要的代码。协程本身并不复杂，一个是因为基于上述的原理只要一些汇编代码可以了，它主要保存了一些寄存器，并把一些状态存起来，然后只处理一些寄存器的状态就可以。但只有这一部分是不够的，因为如果我们提供了一个协程，用户还是要做很多代码。 Libco框架
一个纯粹的协程必须跟网络框架结合在一起才能实现它的价值。 我们对协程做了最基本的源语，因为我们并不想发明更多的概念出来。协程的源语包括co_create/co_resume/co_yield，协程间同步cond/signal。 同时我们还提供了一个轻量级网络事件库。基于同样的考虑，这个库是基于epoll的事件回调以及基于时间轮盘的定时器设计。 另外Socket族函数hook，我们实现网络读写api hook，支持mysqlclient/gethostbyname，支持aio读磁盘，支持cgi(getenv/setenv)。 经过这套设计之后，我们就开始对微信的后台进行改造，目前基本上改造完成。 线程内协程切换图
这是一些具体的情况。我们可以看到，我们必须实现一个主的EventLoop去处理后发出的所有事件，在事件被触发的时候，可以保证为通。 用一个标准的线程，基于网络事件切换协程。如果异步处理才能把逻辑分成很多分片，然后在事件触发过程中用回调来完成你的逻辑，但是反过来在协程里面就简单很多。 Libco下编程需要注意的点
现在Libco栈大小默认设置为128K，它可以支持一个共享执行，支持单机千万协程，那需要注意什么呢？有两点： 首先需要用poll代替sleep，其次对于计算较重的服务，需要分离计算线程与网络线程，避免互相影响。 在实践的过程中，遇到的问题还有很多，只要把所有的情况都考虑进去，就可能有很好的提升。这些年，有了这两大基础组件的支撑，微信现在进入比较稳定的时期。
许家滔，微信技术架构部后台总监，专家工程师，多年来伴随QQ邮箱和微信后台成长，历经系统从0到10亿级用户的过程。目前负责微信后台工作，包括消息，资料与关系链，后台基础设施等内容。