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

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

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

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