大型分布式C++框架《一：框架简介》

Posted 2020-07-04 z折腾

　　首先名字要取得霸气才能吸引人气，哈哈~~

　　下面简单介绍下情况。框架是腾讯电商平台的分布式框架。虽然腾讯拍拍已经玩完了。但是这套框架还是很不错的。而且据原腾讯同事说微信也是用的这套框架。源码肯定是不能说的。但是介绍大体的思想我想应该没问题。虽然在这个框架下写了一年多的业务代码。但是平台框架的代码一直没怎么看。最近有开始看平台代码虽然没看完。但是大体的思想已经清楚。可以分享下我看的心得。具体细节我琢磨下看哪些能分享。

 

　　现在我们框架依然是用来做电商业务。框架可以分布式部署。

　　简单来说是多进程+协程   并没有用到网上一直说的多线程。

 

下面来具体介绍下框架的内容

一、框架总体介绍

框架总体分4个部分。 config_center、netio2、back_netio2、container3

config_center： 作用是 获取命令字并通知netio2、back_netio2、container3

netio2： 收取网络包  发给container3 去执行

container3：执行具体的业务

back_netio2：如果是跨机调用。则需要back_netio2来转发包

 

 

二、这里我先介绍下一个包的基本流程。

 

首先 先简单介绍一下我们框架的基本常识。后面会详细介绍

a)我们是使用的rpc接口远程调用的模式， 每个接口都有一个命令字。  

b)然后 每个container进程就是一个服务。每一个负责具体的不同业务。   一个服务里会用很多个接口。 

c)每个服务  会分为  ao  和 dao 。  ao做业务逻辑。但是是非阻塞的 ，dao 专门用来存取数据可以是阻塞的。

 

接下来我们说下包的流转过程

 

1） 前端 发送一个 调用接口的请求过来 比如调用GetShopName接口

2） netio  收到包以后。  做一些处理。比如打上时间戳等。  然后把包丢到消息队列里。  netio是一个单线程的进程。 可以起多个netio来收包。

3）container服务 在消息队列里发现有包。  就取出来处理。然后切换协程。 它会把包丢给具体的AO业务服务去处理。

4）Ao服务  发现 需要取数据。  它会生成一个请求包。把数据丢到消息队列里去。然后会切回主进程。继续监听消息队列

5）container 从消息队列里接收到了  函数A处理完的结果。  就会立马在切到服务Ao里去，继续执行。

6） 在掉到 函数B的时候  发现需要去别的进程取数据。  然后跟函数A的处理一样。这里就不说了。  

打字好累。。。

7）container处理完了所有数据。  生成一个返回包。然后把它丢到消息队列里。

8）netio  拿到返回包。 找到请求时的socket发送回去。

 

到这里一个基本的流程完了。

由于很多东西都没有介绍。所以图话的比较简陋、说明的也比较泛泛。 等后面慢慢介绍完细节。就明白了。

光看一个图。很多东西看不出来的

 

 

下面先介绍下贯穿整个框架两个比较核心的东西。

一个是消息队列还有一个是协程。

这两个东西 支持了系统的分布式部署。以及大并发的处理能力。以及无锁编程

 

三、消息队列

 

有比较才能看的更清晰

这里首先我们看下多线程编程下怎么处理包的。

（由于我没有接触过像腾讯、阿里这样大型的多线程框架所以我这里只说以前公司写的多线程处理模式。）

 

在多线程模式下。服务端会生自己成一个任务队列。然后对这个队列进行加锁操作。

然后服务每次收到一个请求包。就把请求包扔到任务队列里。 然后继续收包。仍包。   

然后线程池会去 任务队列里取任务 并处理

 

我们现在的这个框架中的消息队列。就相当于 一个任务队列。

 

1）  因为我们用系统消息队列。   然后我们限制了消息队列的大小。所以即使并发往消息队列里塞消息。顶多也就是赛不进去。对系统影响不到。 而且不用不用给队列上锁之类的操作。速度杠杠的。

2） netio 进程起来的 时候会有一个消息队列。  专门用来接收处理完的请求。然后把这些请求发送回给前端。

3）每个服务  会有两个队列。   一个叫请求队列   一个叫回包队列。  

请求队列是用来接收别的服务发送过来的请求的包。  

回包队列是服务本身请求别的服务。别的服务返回结果则放到这个回报队列里

4） 所以 ipcs -q 的时候 会看到有一堆的消息队列。

 

 

这样的话可以看到  每个服务跟每个服务是相互独立的。  

他们都有自己的任务队列。每个服务即可以是开始  也可以是结束。

 

但是 消息队列并不是最快的。如果做的复杂可以用共享内存。

但是  平台用系统自带消息队列  给人感觉很清晰。也不会那么复杂。

 

 

四、协程        

协程这个东西如果要说的话。还是有挺多东西说的。这里就细说。说些基本的东西

在我没接触协程的时候。  写多线程服务端程序的时候。觉得多线程很牛逼。后台接触了这个框架。慢慢熟悉协程，发现协程更牛逼。。。。

但其实不能说协程比线程更厉害。只是应用场景上不同。

 

多线程的好出我就不说了。这里说下多线程的缺点。

1）多线程  切换的时候 需要陷入内核。切换的成本比较大。而且线程数过多。这个切换的成本会足增

2）多线程 编写代码的时候。常常会用到锁。一来代码没写好会造成死锁，二来用锁会减慢程序执行的速度

 

而协程 刚好解决了这两个问题

1）协程 切换 是在用户空间，不需要陷入内核。有程序员手动控制。所以协程的切换成本非常低。

可以创建大量协程  而不会对系统有运行有影响

2）写协程代码  其实大体上是顺序思维。 基本上用不到锁。

所以这里其实有个很重要的问题。由与协程相当于顺序执行。所以一定不能阻塞。

 

在我们的平台中。

1）AO服务一般是一个进程。然后起50个协程。具体看业务量。如果业务量大可以起多个AO进程

2）AO由于是用协程的。所以AO服务不能阻塞。任何阻塞的动作。都不会在AO中出现。AO一把做业务处理。 就是 比如参数校验、if else 、赋值  、业务逻辑等等。

3）如果要去db或者缓存里取数据。 AO服务会调用DAO服务。

4）DAO服务  一般起10个进程。主要用来去mysql和redis、等取数据。可以阻塞

 

所以这个模型下。再加上超时处理机制。

可以处理大量并发场景。

 

拍拍虽然没有达到淘宝那样的请求量。

但也是上亿的请求并发。

so ,看完框架代码以后 才发现这个框架写的真是好。

 

但是我反而更好奇  淘宝那种。高并发的框架是什么样的。

是否用到了多线程

    

 

 

先就介绍这么多吧。还有很多细节才组成了这个框架

后面再慢慢说

争取每一个星期更新一篇吧。

努力在两个月内把框架看完