原文:https://blog.csdn.net/libaineu2004/article/details/80554870

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

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框架。

与流行开源框架对比

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/tech_meizu/article/details/51487793

【转】libgo的更多相关文章

  1. libgo 2.0发布

    libgo 是一个使用 C++ 编写的协作式调度的stackful协程库, 同时也是一个强大的并行编程库. 设计之初是为高并发分布式Linux服务端程序开发提供底层框架支持,可以让链接进程序的同步的第 ...

  2. libgo协程库:网络性能完爆ASIO异步模型(-O3测试)

    在purecpp社区的github组织中有一个协程库:https://github.com/yyzybb537/libgo 近日有用户找到我,想要了解一下libgo库在网络方面的性能,于是选取已入选标 ...

  3. Stackful 协程库 libgo(单机100万协程)

    libgo 是一个使用 C++ 编写的协作式调度的stackful协程库, 同时也是一个强大的并行编程库. 设计之初是为高并发分布式Linux服务端程序开发提供底层框架支持,可以让链接进程序的同步的第 ...

  4. 跨平台网络通信与服务器框架 acl 3.2.0 发布

    acl 3.2.0 版本发布了,acl 是 one advanced C/C++ library 的简称,主要包括网络通信库以及服务器框架库等功能,支持 Linux/Windows/Solaris/F ...

  5. CLion之C++框架篇-安装工具,基础框架的搭建(一)

      背景   日常学习C++,也就是看看书.在vim里写写代码.在日常项目开发中,也是边看书(一是系统性理解.二是找找有什么更好的代码编写方式)边写代码,会顺带看看别人的代码怎么写的?     日常学 ...

  6. 并发运算lib

    最近对类似于erlang或者golang的并发运算很感兴趣.以下是看到的相关资料. libgo c++,技术:协程,多线程.这是俺发现的用法最漂亮的c++库,用法参考golang CAF 全称c++ ...

  7. ucontext-人人都可以实现的简单协程库

    ucontext的介绍 http://blog.csdn.net/qq910894904/article/details/41911175 协程的介绍 https://en.wikipedia.org ...

  8. GoAhead4.1.0 开发总结二(自定义使用)

    环境 官方文档:https://www.embedthis.com/goahead/doc/ 源码下载: goahead-4.1.0-src.tgz 系统平台:Ubuntu 12.04.4 gcc v ...

  9. GoAhead4.1.0 开发总结一(移植)

    环境 官方文档:https://www.embedthis.com/goahead/doc/ 源码下载: goahead-4.1.0-src.tgz 系统平台:Ubuntu 12.04.4 gcc v ...

随机推荐

  1. mysql 开启日志服务

    mysql 版本:mysql-5.7 1.在/etc/my.cnf 中添加如下内容: #错误日志: -log-err log-error=/usr/local/mysql--linux-glibc2. ...

  2. 小甲鱼汇编语言学习笔记——day03

    手动编译并执行第一个汇编程序过程: 1.用notepad++写一个简单的汇编程序(文件命名为:1.asm): assume cs:abc abc segment mov ax, 2 add ax, a ...

  3. adb 常用命令汇总

    adb 常用命令: adb –help 查看帮助手册 adb devices 检测连接到电脑的安卓设备或安卓模拟器设备 adb pull  <手机路径>  <本机路径>  从手 ...

  4. 如何理解JavaScript的原型和原型链

    在现在的业务开发中,应该很少人在写原生JavaScript了,大家都一股脑地扑在各个框架上.本来,这些框架对于业务和开发者来说是一种福音,减少了各种各样的开发痛点,但是带来的负面问题就是对于开发者来说 ...

  5. 将笔记本无线网卡链接wifi通过有线网卡共享给路由器

    1.背景 背景这个就说来长了,在公司宿舍住着,只给了一个账号,每次登录网页都特别麻烦(需要账号认证那种).然后每个账号只支持一个设备在线,这就很尴尬了,那我笔记本.手机.Ipad怎么办? 当然,这时候 ...

  6. Linux 6 修改ssh默认远程端口号

    linux 默认的ssh远程端口是22,有时默认端口会遭到别有用心的人们扫描或攻击,为了时我们的系统更加安全那就需要修改远程端口号 操作步骤:1.修改ssh_config配置文件 vim /etc/s ...

  7. EgretWing链接微信开发工具调试问题

    EgretWing链接微信开发工具调试问题 EgretWing 编译器支持持三种调试模式,Node.js .Chrome .EgretWing 扩展开发. 开发过程中会遇到工具配置错误. 这就需要在E ...

  8. iOS - FlexBox 布局之 YogaKit

    由于刚开始的项目主要用的H5.javaScript技术为主原生开发为辅的手段开发的项目,UI主要是还是H5,如今翻原生.为了方便同时维护两端.才找到这个很不错的库. FlexBox?听起来像是一门H5 ...

  9. 【openshift】OC命令部署Openshift

    OC命令部署Openshift # install openshift wget -c https://github.com/openshift/origin/releases/download/v3 ...

  10. this指向详解及改变它的指向的方法

    一.this指向详解(彻底理解js中this的指向,不必硬背) 首先必须要说的是,this的指向在函数定义的时候是确定不了的,只有函数执行的时候才能确定this到底指向谁,实际上this的最终指向的是 ...