魅族C++协程框架(Kiev)技术内幕

Posted 2022-11-28 魅族技术

Kiev框架简介

kiev是魅族科技推送平台目前使用的Linux-C++后台开发框架。从2012年立项起，先后由多位魅族资深架构师、资深C++工程师倾力打造，到本文写就的时间为止，已经在推送平台这个千万用户级的大型分布式系统上经历了近5年的考验。如今Kiev在魅族推送平台中，每天为上百个服务完成数百亿次RPC调用。

kiev作为一套完整的开发框架，是专为大型分布式系统后台打造的C++开发框架，由以下几个组件组成：

• RPC框架(TCP/UDP)
• FastCGI框架
• redis客户端(基于hiredis封装)
• mysql客户端(基于mysqlclient封装)
• mongodb客户端
• 配置中心客户端(Http协议, 基于curl实现)
• 基于zookeeper的分布式组件(服务发现、负载均衡)
• 日志模块
• 状态监控模块
• 核心模块是一个开源的`CSP并发模型`协程库(libgo)

并发模型

Kiev采用了很先进的CSP开发模型的一个变种(golang就是这种模型)，这一模型是继承自libgo的。 选择这种模型的主要原因是这种模型的开发效率远高于异步回调模型，同时不需要在性能上做出任何妥协，在文中会对常见的几种模型做详细的对比。

CSP模型

CSP(Communicating Sequential Process)模型是一种目前非常流行的并发模型，golang语言所采用的并发模型就是CSP模型。 在CSP模型中，协程与协程间不直接通信，也不像Actor模型那样直接向目标协程投递信息，而是通过一个Channel来交换数据。

这样设计的好处是通过Channel这个中间层减少协程间交互的耦合性，同时又保证了灵活性，非常适合开发并发程序。

RPC框架

RPC（Remote Procedure Call）是一种远程调用协议，简单地说就是能使应用像调用本地方法一样的调用远程的过程或服务，可以应用在分布式服务、分布式计算、远程服务调用等许多场景。说起 RPC 大家并不陌生，业界有很多开源的优秀 RPC 框架，例如 Dubbo、Thrift、gRPC、Hprose 等等。 RPC框架的出现是为了简化后台内部各服务间的网络通讯，让开发人员可以专注于业务逻辑，而不必与复杂的网络通讯打交道。 在我们看来，RPC框架绝不仅仅是封装一下网络通讯就可以了的，要想应对数以百计的不同服务、数千万用户、百亿级PV的业务量挑战，RPC框架还必须在高可用、负载均衡、过载保护、通信协议向后兼容、优雅降级、超时处理、无序启动几个维度都做到足够完善才行。

服务发现

Kiev使用zookeeper做服务发现，每个kiev服务开放时会在zookeeper上注册一个节点，包含地址和协议信息。水平扩展时，同质化服务会注册到同一个路径下，产生多个节点。 依赖的服务调用时，从zookeeper上查询当前有哪些节点可以使用，依照负载均衡的策略择一连接并调用。

负载均衡

内置两种负载均衡策略：robin和conhash，并且根据实际业务场景可以定制。

过载保护

Kiev内置了一个过载保护队列，分为10个优先级。每个请求到达时先进入过载保护队列，而后由工作协程(work-coroutine)取出请求进行处理。 如果工作协程的处理速度低于请求到达的速度，过载保护队列就会堆积、甚至堆积满。 当过载保护队列堆满时，新请求到达后会在队列中删除一个更低优先级的请求，腾出一个空位，塞入新请求。 同时，队列中的请求也是有时效性的，过长时间未能被处理的请求会被丢弃掉，以此避免处理已超时的请求。 这种机制保证了当系统过载时尽量将有限的资源提供给关键业务使用。

通信协议向后兼容

由于微服务架构经常需要部分发布，所以选择一个支持向后兼容的通信协议是很必要的一个特性。 Kiev选取protobuf作为通信协议。

与第三方库协同工作

最早期的Kiev是基于异步回调模型的，但是很多第三方库只提供了同步模型的版本，很难搭配使用。 当前的Kiev是CSP并发模型，配合libgo提供的Hook机制，可以将同步模型的第三方库中阻塞等待的CPU时间充分利用起来执行其他逻辑，自动转化成了CSP并发模型；异步回调模型的第三方库也可以使用CSP模型中的Channel来等待回调触发；从而完美地与第三方库协同工作。

kiev功能组件结构图

Kiev发展史与技术选型

2012年，魅族的推送业务刚刚有一点从传统架构向微服务架构转型的意识萌芽，为了在拆分系统的同时提高开发效率，我们决定做一个C++开发框架，这就是最早期Kiev的由来.

第一个版本的Kiev使用了多线程同步模型，业务逻辑顺序编写，非常简单。 但是由于os对线程数的支持有限，随着线程数量的增长，调度消耗的增长是非线性的，因此不能支持过高的请求并发。

随着用户量的增长，我们需要支持更高的并发请求，由于当年协程还不像现在这样流行，所以我们决定使用异步回调模型编写Kiev。早期的业务形态非常简单，使用异步回调模型也勉强可以应付开发任务。

在其后几年中，我们使用异步回调模型的Kiev开发了大量的服务，在使用中我们慢慢发现逻辑碎片化的问题越来越多，更可怕的是，有些时候长长的回调链还要和有限状态机纠缠在一起，代码越来越难以维护。常常出现类似于下面这样的代码片段：

针对这样的问题，我们引入了腾讯开源的协程库libco，在协程中执行同步的代码逻辑；同时使用Hook技术，将阻塞式IO请求中等待的时间片利用起来，切换cpu执行其他协程，等到IO事件触发再切换回来继续执行逻辑。类似于上述的碎片化代码就变成了连续性的业务逻辑，也不再需要手动维护上下文数据，临时数据直接置于栈上即可，代码变成如下的样子：

然而，libco仅仅提供了协程和HOOK两个功能，协程切换需要我们自己做，为了实现简单，RPC框架进化成了连接池的模式，每次发起RPC调用时从连接池中取一条连接来发送请求，等待回复，然后释放回连接池。 每条连接同一时刻只能跑一个请求，rpc协议退化成了半双工模式。此时为保证性能，不得不在每两个有依赖关系的服务之间建立数以百计的TCP连接，这样在依赖了水平扩展为很多进程的服务上，就会与这些进程分别建立数百连接，TCP连接高达数千，甚至上万，对服务器造成了很大的压力。连接请求如下图所示，其中每条连接线都代表数以百计的TCP连接。

相应地，我们也更新了kiev中的redis、mysql、fastcgi模块，都改为了协程模型的。

在最初的几个月中，这种方式很好地帮我们提升了开发效率，同时也有着还算不错的性能（Rpc请求差不多有20K左右的QPS）。随着时间的流逝，我们的用户越来越多，请求量也越来越大，终于在某次新品发布后，我们的一个非关键性业务出现了故障。

出现故障的这个业务是一个接受手机端订阅请求的业务，手机端在订阅请求超时后（大概30s），会重新尝试发起请求。由于当时系统过载，处理速度慢于请求速度，大量请求积压在队列中，随着时间的推移，服务处理请求的响应速度越来越慢，最终导致很多请求还没处理完手机端就认为超时了，重新发起了第二次请求，形成雪崩效应。当时紧急增加了一些服务器，恢复了故障，事后总结下来发现，事件的主因还是因为我们没有做好过载保护机制。于是我们决定在Kiev中内置过载保护功能，增加一个分为10个优先级的过载保护队列。每个请求到达时先进入过载保护队列，而后由工作协程(work-coroutine)取出请求进行处理。当过载保护队列堆满时，队列中删除一个最低优先级的请求，腾出一个空位。同时，队列中的请求也是有时效性的，过长时间未能被处理的请求会被丢弃掉，以此避免处理已超时的请求。如下图所示：

随着机器越来越多，以及后续出现了一些超长链路请求的业务形态（这里解释一下长链路请求的问题，长链路请求是指一个请求要流经很多服务处理，在处理流程中，前面的服务一定要等到后面的服务全部处理完成或超时，才会释放其占用的TCP连接，这样的模式会极大地影响整个系统的请求并发数），TCP连接数方面的压力越来越大，最终不得不考虑改为单连接上使用全双工模式。然而当时使用的libco功能过于简单，很难基于此开发全双工模式的RPC框架，恰好当时有一位同事在github上做了一个叫libgo的开源项目，是一个和golang语言一样的CSP并发模型的协程库，于是我们做了一段时间的技术预研，看看能否替换掉现有的libco. 下面的表格是两个项目在我们比较关心的一些维度上的对比:

通过调研，最终我们决定使用libgo替换掉libco。

基于CSP模型实现全双工通信RPC非常容易，客户端只需在每个request发出后保存id和channel并阻塞地等待相应的channel，收到response时根据id找到对应的channel并写入数据即可。这样只需一条TCP连接，就可以并发无数个request，分布式水平扩展带来的TCP连接管理方面的压力就不再是问题了。同时由于每次RPC所需的资源更少，性能也有了很大提升，Rpc请求的QPS轻松提升到了100K以上。这一性能指标目前已经超越了绝大多数开源的RPC框架。

与流行开源框架对比