欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

(七):C++分布式实时应用框架 2.0

程序员文章站 2022-07-04 23:11:23
C++分布式实时应用框架 2.0 技术交流合作QQ群:436466587 欢迎讨论交流 上一篇:(六):大型项目容器化改造 版权声明:本文版权及所用技术归属smartguys团队所有,对于抄袭,非经同意转载等行为保留法律追究的权利! 在C++分布式实时应用框架(CDRAF)1.0版本发布后,我们对整 ......

C++分布式实时应用框架 2.0

技术交流合作QQ群:436466587 欢迎讨论交流

 

上一篇:(六):大型项目容器化改造

版权声明:本文版权及所用技术归属smartguys团队所有,对于抄袭,非经同意转载等行为保留法律追究的权利!

 

  在C++分布式实时应用框架(CDRAF)1.0版本发布后,我们对整个框架做了大量的改进。在架构层面支持微服务架构、微服务编排。进一步厘清了CDRAF与业务代码的耦合,所有的分布式功能均不再需要业务侧关心,而统一由CDRFA内部实现。极致简化了业务侧的配置文件,也许下一步是做一个代码自动生成功能,根据配置生成相应的业务代码框架。重新实现如节点时延统计(CDRFA自动实现每个包的时延统计,业务无需关心),单号码日志跟踪(改成消息包染色的方案,CDRFA遇到染色包自动打印日志),应用命令功能(通过系统管理模块的RESTful接口给节点内的应用程序下达指令)等等。提供接口全面展示集群的节点实时拓扑图,并支持对集群节点微服务进行实时编排。增加了新的日志框架功能,提供高性能、多场景的日志输出能力。应对这些改进同步增加了相应的单元测试。由此C++分布式实时应用框架2.0版本也应运而生!

 

  一、集群实时拓扑图

  实时拓扑图展示了集群的每个节点(容器实例),连线代表通讯方向,孤立的节点表示未并网的节点。界面实时展示TPS(流量),RTT(时延)两个数据,点开节点可以进入容器节点的管理界面,做更多容器节点的管理工作。

  (七):C++分布式实时应用框架 2.0

  

  二、微服务编排

   按第五篇《微服务架构的演进》的方案,我们增加了图形界面支持微服务架构的编排。每个大圈表示一个类型的节点,小圈代表一个微服务端口。编排的时候从一个节点连线到另一个节点,并且选择两个节点要对接的微服务,即可完成编排。可以实时在集群运行过程中进行编排,完成编排后,集群状态也会实时显示在上面的拓扑图当中。当然可以根据业务自身需要,增加新类型的节点,或者为节点增加新的微服务端口。可以看到每个节点都独立非耦合,节点间的交互完全是通过微服务端口来进行,并且这些端口生效与否是通过微服务编排来进行控制的。

(七):C++分布式实时应用框架 2.0

 

 

  三、时延统计功能

   时延统计功能是分布式框架的核心数据之一,用于实时检测节点的性能,并依此采取相应的解决策略。原来这个功能是在业务侧实现的,CDRAF2.0中,我们将这个功能提到框架中,可以计算所有节点的时延数据,并且业务无需关心(业务无需做任何事情即可获得这个功能)。

  CDRAF2.0中我们统一了节点的通讯模型,所有的节点均由Dis(数据分发)和业务处理进程组成。在一个业务包到达Dis后,框架会在这个包的包头打进当刻时间,在业务进程处理完消息回到Dis后,Dis会计算两个时间差得到时延数据。并将每个包的数据进行平均计算,上报状态中心,并且可以在实时拓扑图中展现出来。所有这些工作都由框架来完成。

(七):C++分布式实时应用框架 2.0

 

  

  四、单号码日志跟踪(包染色方案)

  原来的日志跟踪方案在收到号码跟踪命令后,会通知所有节点的所有进程都来关注这个号码,遇到这个号码的包后就把日志跟踪打开。这个方案有几大缺点:

  a) 所有的业务进程都需要实现一份号码检测、开日志跟踪的功能,代码会无比冗余。

  b) 当打开这个功能的时候,集群所有的节点,节点中所有的进程,都会处理监测是否有这个号码的状态中。整个集群处于一个十分不稳定状态中。

  c) 业务上可能不支持同时跟踪多个号码。

  为此我们调整了单号码日志跟踪的方案,采用包染色的方案。在消息入口的位置检测号码,一旦符合条件就将这个消息包进行包头染色,后面的处理环节框架收到包后会先于业务检测包头,如果发现包头被染色,就会将日志跟踪打开,这个包处理完毕后再关闭。每个环节往下传的时候,框架都会自动为下传的包再次进行染色,以保证处理流程上的每个环节接收到的都是经过染色的包。新方案的优点如下:

  a) 业务上不再需要为这个功能实现相应的代码,只要在入口位置进行一次号码监测,如果符合就调用框架进行染色,后续所有操作都由框架来完成。

  b) 打开这个功能的时候集群不再处理不稳定状态,业务层面甚至感觉不到这个功能的存在,框架处理了所有的问题。

  c) 当有新的业务节点加进来的时候,会自动获得这个功能,而无需做任何改造。

  d) 除了单号码日志跟踪功能,这个方案还可以应用于其它的业务场景。

(七):C++分布式实时应用框架 2.0

  

  五、通用指令传递方案

  在CDRAF中,如果外界要给集群中某个节点的某个进程下达一个指令,会通过系统管理模块的RESTful接口,然后通过状态中心,通讯平台最终传递到相应的进程。但在我们之前的方案中,每增加一个这样的命令都需要给每个模块(系统管理、状态中心、通讯平台)增加相应的代码来进行支持。

  新的方案中,我们设计了通用的消息通路,用来传递指令。

  通讯框架自动给SmartAgent 进程增加MonitorMsgInterface 端点,无需配置;SmartAgent 将业务控制消息从自身的MonitorMsgInterface 端点发出, SmartMonitor 从自身的MonitorMsgInterface 端点接收并处理;

  统一的命令格式

message MONITOR_MSG
{
    string dest = 1;
    bytes msg = 2;
}

  其中, dest 为控制消息想要发送的目的地,填具体目的地进程的进程名,如"OLCProxy","OCPro", "OCDis"等;如果需要将命令发送至所有进程,则dest 填成字符串all 。msg字段为具体的控制命令文本。

  框架自身提供了若干公共的控制命令,枚举如下:
调整日志级别
格式: log 日志级别
其中, 日志级别包含off , critical , err , warn , info , debug , trace
例子: log debug
停线程
格式: stop
重载通讯链路信息
格式: reload
  除了以上框架提供的公共控制命令外, SmartMonitor 也可以接收任意消息并传递给指定进程,其不关心消息内容,消息内容完全由业务进程负责解析处理。 原则上SmartAgent 在填写该字段值的时候,应该直接从ZK读取;ZK上应该有该控制命令的文本。

 

   从上面这些调整可以看到,CDRAF2.0致力于将分布式相关功能和业务彻底解耦。在我们的设计与实现中,业务和框架之间有一条明显的分界线。所有可以在框架侧做到的功能,业务侧一行代码也不用写,便可自动获得。我想这便是CDRAF2.0向通用型框架迈出的一大步!