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

2018-06-17 20:41:08来源:未知 阅读 ()

新老客户大回馈,云服务器低至5折

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

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

 

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

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

 

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

 

  一、集群实时拓扑图

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

  

  

  二、微服务编排

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

 

 

  三、时延统计功能

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

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

 

  

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

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

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

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

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

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

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

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

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

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

  

  五、通用指令传递方案

  在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向通用型框架迈出的一大步!

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:底层文件I/O操作中read()函数的缓存问题

下一篇:静态链接库和动态链接库