(五):C++分布式实时应用框架——微服务架构的演进

本文涉及的产品
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
云原生网关 MSE Higress,422元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: C++分布式实时应用框架——微服务架构的演进 技术交流合作QQ群:436466587 欢迎讨论交流上一篇:(四):C++分布式实时应用框架——状态中心模块 版权声明:本文版权及所用技术归属smartguys团队所有,对于抄袭,非经同意转载等行为保留法律追究的权利!   OCS(online charging system,在线计费系统)在进行云化改造的过程中,从实用主义角度出发,微服务架构并不是我们的目标。

C++分布式实时应用框架——微服务架构的演进

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

上一篇:(四):C++分布式实时应用框架——状态中心模块

 

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

 

  OCS(online charging system,在线计费系统)在进行云化改造的过程中,从实用主义角度出发,微服务架构并不是我们的目标。虽然我们也对系统进行了容器化改造(Docker),并根据业务进程的功能将系统分成了好几类的容器,但这一切多是出于对系统中的某些处理节点进行动态扩缩容的需要,跟微服务半点关系没有。随着系统改造 的深入,系统的通讯关系复杂程度开始超过我们之前的估计。如果说数量众多的功能节点还有人可以勉强掌握,这些节点间错综复杂的通讯关系连线已超过程序员可以驾驭的范畴。在讨论如何简化程序员实现整个系统各类节点的通讯关系的配置过程中,节点微服务化的理念渐渐进入我们的脑海之中……

  下面先给大家介绍下我们所面临的困境,下面的图是我们系统一部分节点的通讯关系总图(注意,只是其中一部分):

 

  还记得第二篇《基于ZeroMQ的实时通讯平台》中那个我们引以为傲的通讯配置文件吗,就是程序中所有的通讯连接关系不再是写死在代码中,而是通过AppInit.json配置文件进行配置,程序启动的时候再由CDRAF进行实时加载。当初酷炫的功能,现在却成我们的恶梦。此时AppInit.json这个文件已到达1700多行,你没看错,一个配置文件1700多行,并且还不是全部,还会继续变大。

 

"OLC" : {
      "AUTO_START" : "YES",
      "ENDPOINTS" : [
         {  // 用于与SmartMonitor建立心跳
            "name" : "MonitorSUB",   
            "zmq_socket_action" : "CONNECT",  // ZMQ的连接模式
            "zmq_socket_type" : "ZMQ_SUB"     // ZMQ的通讯模式
         },
         { // 下发消息给OCDis,这边存在转发功能,支持业务实现按条件转发
            "downstream" : [ "OCDis2OLC"],
            "name" : "NE2OLC",                // 根据这个名字在业务代码中实现转发
            "zmq_socket_action" : "BIND",
            "zmq_socket_type" : "ZMQ_STREAM" 
         },
         { // OLC到OCDis的链路
            "name" : "OCDis2OLC",
            "statistics_on" : true,
            "zmq_socket_action" : "CONNECT",
            "zmq_socket_type" : "ZMQ_DEALER"
         },
         { // OCDis回OLC的链路,之所以来去分开,主要用于实现优雅启停功能(启停节点保证不丢消息)
            "name" : "OCDis2OLC_Backway",
            "statistics_on" : true,
            "zmq_socket_action" : "CONNECT",
            "zmq_socket_type" : "ZMQ_DEALER",
            "backway_pair" : "OCDis2OLC"
         },
         {  // 用于与SmartMonitor的命令消息链路
            "name" : "OLC2Monitor",
            "zmq_socket_action" : "CONNECT",
            "zmq_socket_type" : "ZMQ_DEALER"
         },
      ],
      "ENDPOINT_TO_MONITOR" : "OLC2Monitor",
      "INSTANCE_GROUP" : [
         {
            "instance_endpoints_address" : [
               {
                  "endpoint_name" : "NE2OLC",
                  "zmq_socket_address" : "tcp://*:6701"
               },
               {
                  "endpoint_name" : "OCDis2OLC",
                  "zmq_socket_address" : [
                     "tcp://127.0.0.1:7201"   // 跨机的IP地址与端口,配合状态中心可实现自动管理,无需人工参与配置
                  ]
               },
               {
                  "endpoint_name" : "OCDis2OLC_Backway",
                  "zmq_socket_address" : [
                     "tcp://127.0.0.1:7202"
                  ]
               },
               {
                  "endpoint_name" : "OLC2Monitor",
                  "zmq_socket_address" : "ipc://Monitor2Business_IPC"
               },
               {
                  "endpoint_name" : "MonitorSUB",
                  "zmq_socket_address" : "ipc://MonitorPUB"
               }
            ],
            "instance_group_name" : "1"
         }
      ]
   },

 

  一个业务程序员如果要调整系统中某个程序的通讯连接,一定得盯着上面那副图研究半天,并且要搞明白“CONNECT”、“BIND"、”ZMQ_ROUTER"、“ZMQ_DEALER"等等这些zeromq专业词汇的含义,才可能进行准确配置,我们隐隐感到这已是一个mission impossible。如何简化这个配置文件,如何对系统的复杂度进行分层,让不同层级的人员仅仅只需关注自身层级情况,再通过我们的CDRAF最终将这些散落的配置、代码组成一个完成可运行的系统才是我们现在亟需解决的问题。相信这也是每个系统架构师所面临的问题,当一个系统的复杂度超过单个人可承受能力范围,就要对这个系统进行适当分层,分模块。让每个人去管理一小部分复杂点,并且大家只需实现好自己的模块,无需去关心别的模块的实现细节。通过事先设计好的接口,各个模块可以相互协作,整体系统是可以依此完美地运行的。这里CDARF正是起这么一个不同模块的桥梁(接口)的作用。

  一、节点间通讯模式的统一

  原来节点内的应用程序都是通讯全能应用程序,所谓全能是指应用程序既可以跟节点内的进程进行通讯也可以跟节点外的任意进程进行通讯。这样乍看起来没啥问题,但一旦节点数和进程数变多后,通讯关系将是一个指数级增长的过程。如下图,如果再增加一个CDR节点,或者OCS节点,连接数都将增加非常多。

  

  我们的解决办法是统一节点的通讯模式,每个节点内都有一个Dis进程,统一对外负责跟其他节点进行通讯。在收到外部发给节点的消息后,根据功能和负载转发给内部业务处理进程。业务进程如果有消息需要发往别的节点,就直接发给Dis进程,由它进行转发。统一通讯模式带来的好处除了在节点和进程增多后,通讯关系不会变得太复杂以外。由于模式统一, CDARF可以替业务程序员完成很多工作,直接的好处就是业务程序员不再需要配置很多与业务无关的配置。最大化的将通讯模块的复杂度留给CDRAF去处理,业务程序员将更加专注于自身的业务逻辑。下面的图中其实系统开始已经有微服务的样子,但我们希望做到的不仅是从系统架构上是微服务架构,在程序员开发程序的时候,也应该是带着微服务思维的,我们的CDRAF应该提供这么一种能力来支持这种开发模式。

  

 

  二、配置文件的简化

  通讯模式统一后,我们对通讯配置文件进行了一次较大的简化,从原来1700行减少到了200行左右。这当中省去了很多冗余的配置项,通讯配置文件不再是对系统通讯简单直接的对应,而更多的是对节点通讯能力的一种表述。

  应用程序分为Dis和非Dis两类,Dis类程序主要承担节点间的通讯和节点内的消息转发,非Dis类程序就是普通的业务处理进程。从下面的文件中可以看到“OCDis”进程中分为“InterContainerEndpoints”和“InnerContainerEndpoints”两大类,分别表示节点间的通讯和节点内的通讯。对于节点间的通讯,每个服务端口只要写上相应的“服务名字”就可以以了,配置中的“OCDisCDRDis”表示OCSDis与CDRDis的通讯,“OLCDisOLCProxy”、“OCDis_SyDis_SNR”也是类似。当业务侧程序需要对外提供一个服务(或者说与外部进行通讯),只需要写一个服务名字,而如:端口、机器的IP地址、服务端还是客户端、通讯模式等等都完全不需要去关心,这是多大一种便利。配置中的注释部分是不需要业务程序员去填的,而是由CDRAF的状态中心,根据集群节点的实时情况自动生成,并进行连接和维护。

  

{
  "OCDis": {
    "MaxInstanceGroupNum": 3,
    "InterContainerEndpoints": 
    {
      "OCDisCDRDis": 
      {
        //"Port": [6001, 6002, 6003],
        //"Cluster": ["10.45.4.10:6001", "10.45.4.10:6001"]
      },

      "OCDisOLCProxy": 
      {
        //"Port": [6101, 6102, 6103],
        "DownStreams": ["OCDis2IN", "OCDis2PS", "OCDis2SMS", "OCDis2ISMP", "OCDis2IMS"],
        "router": true
      },
      "OCDis_SyDis_SNR": 
      { 
          //"Peer": "ZSmartSyDis.OCDis_SyDis_SNR" 
      }
    },

    "InnerContainerEndpoints": 
    {
      "OCPro_OCDis_CDR": { "DownStreams": ["OCDisCDRDis"] },
      "OCPro_OCDis_SNR": { "DownStreams": ["OCDis_SyDis_SNR"] },
    }
  },

  "OCPro": {
    "Groups": ["IN", "PS", "SMS", "IMS", "ISMP"],
    "InnerContainerEndpoints": {
      "OCPro2OCDis": {
        "PeerMap": [
          "OCDis.OCDis2IN",
          "OCDis.OCDis2PS",
          "OCDis.OCDis2SMS",
          "OCDis.OCDis2ISMP",
          "OCDis.OCDis2IMS"
        ]
      },
      "OCPro_OCDis_SNR": {"Peer": "OCDis.OCPro_OCDis_SNR"},
      "OCPro_OCDis_CDR": {"Peer": "OCDis"}
    }
  },

  "CDRDis": {
    "InterContainerEndpoints": 
    {
      "OCDisCDRDis" : 
      {
        "DownStreams": ["CDRDisCDR"],
        //"Peer": "OCDis"
      }
    }
  },

  "CDR": {
    "InnerContainerEndpoints": 
    {
      "CDRDisCDR" : {"Peer": "CDRDis"}
    }
  }
}

  想像一下,对于每一个业务节点,开发人员仅需考虑节点内的业务实现逻辑,并为本节点对外所提供的服务起个名字,而不再需要关心这个服务到底是提供给谁,更不用操心谁会来连我的进程,怎么连。这是多么精妙的事情!我们不仅是从架构上做到了微服务架构,程序员在开发业务程序的时候,不需要去关心除了自身模块以外的其它复杂信息,从此可以轻装上阵,而不再需要负重前行。这应该就是CDRAF对微服务架构提供的最直接、最好的支持了,帮助业务程序员从传统的开发模式转变,进而适应微服务的思维方式。

 

  三、节点间的通讯关系配置

  上面我们提到配置文件只定义了节点的服务名,那么这么多的微服务节点是如何组合起来工作的?一个业务应用系统会由许多的微服务一起协同提供服务,这些服务对于每个不同的现场可能功能是不一样的,或者说微服务集合是不一样的。那么,对这些微服务的组合的过程就像一个“编排”的过程。通过“编排”,选择合适的微服务进行搭配组合提供服务,而编排的过程就是我们通讯建立的过程。下面我们就来看一下CDRAF是如何做到“编排”功能的。

  

  上面的第一张表,描述了所有的微服务列表,所有节点服务要向外通讯都必须到这张表中增加相应的服务名,这里的服务名是与前面配置文件中的服务名相对应的。第二张表描述了这些微服务名之间的通讯关系,比如第二条记录表达的是OCDis程序的OCDis2CDRDis到CDRDis的OCDis2CDRDis之间会有一个通讯关系。只要通过这个简单的配置,就可以完成两个节点间的通讯关系的建立。这样的设计会带来几个好处。

  1、对于一个复杂的系统,可能有几十类微服务节点,运行实例可能有上百个,如果有上面的表二,就可以容器的从上面的数据中画出整个集群的实时拓扑图,这个对于系统的监控是十分重要的。

  2、集群通讯关系的设计上升了一个等级,业务程序员只需要根据模块接口设计提供相应的微服务节点,而不需要关心与其它微服务是如何协调工作的。而这些微服务如何“编排”提升到了架构师的工作范围的层级。这显然是对复杂度进行分层隔离很好的一个范例。

  3、运维或者管理人员,通过表二的配置可以很容易地操作集群里的某个微服务下线或者上线。在一个庞大的集群里面,如果某类微服务出故障,而CDARF提供了这么一种手段可以去让这类故障微服务下线,将给系统的稳定性带来极大的可靠保证。

  4.、原来集群所有的通讯都配置在一个文件中,在分布式系统中就涉及文件的全局一致性的问题。解决的方案可能是,如果要上线一个新类型的配置文件(新增节点、删除节点、通讯关系改变等等),就要去更新所有在网节点的配置文件。但此时如果新的配置文件有bug,那么可能导致整个集群的故障,并且为了升级某个功能去升级整个集群所有节点的配置也是极不合理的。在新的方案中,节点的配置只定义节点内的通讯和对外提供的微服务名。那么如果要新增某种类型的微服务,不再需要去更新其它节点的配置,只需要将新节点上线,然后在上面的表一新增微服务名,表二增加连接关系就可以了。真正做到了增量升级!

 

  未完待续……

 

目录
相关文章
|
2月前
|
存储 缓存 NoSQL
分布式系统架构8:分布式缓存
本文介绍了分布式缓存的理论知识及Redis集群的应用,探讨了AP与CP的区别,Redis作为AP系统具备高性能和高可用性但不保证强一致性。文章还讲解了透明多级缓存(TMC)的概念及其优缺点,并详细分析了memcached和Redis的分布式实现方案。此外,针对缓存穿透、击穿、雪崩和污染等常见问题提供了应对策略,强调了Cache Aside模式在解决数据一致性方面的作用。最后指出,面试中关于缓存的问题多围绕Redis展开,建议深入学习相关知识点。
196 8
|
2月前
|
机器学习/深度学习 安全 算法
十大主流联邦学习框架:技术特性、架构分析与对比研究
联邦学习(FL)是保障数据隐私的分布式模型训练关键技术。业界开发了多种开源和商业框架,如TensorFlow Federated、PySyft、NVFlare、FATE、Flower等,支持模型训练、数据安全、通信协议等功能。这些框架在灵活性、易用性、安全性和扩展性方面各有特色,适用于不同应用场景。选择合适的框架需综合考虑开源与商业、数据分区支持、安全性、易用性和技术生态集成等因素。联邦学习已在医疗、金融等领域广泛应用,选择适配具体需求的框架对实现最优模型性能至关重要。
393 79
十大主流联邦学习框架:技术特性、架构分析与对比研究
|
3天前
|
人工智能 自然语言处理 并行计算
MeteoRA:多任务AI框架革新!动态切换+MoE架构,推理效率提升200%
MeteoRA 是南京大学推出的多任务嵌入框架,基于 LoRA 和 MoE 架构,支持动态任务切换与高效推理。
34 3
|
3月前
|
存储 监控 数据可视化
常见的分布式定时任务调度框架
分布式定时任务调度框架用于在分布式系统中管理和调度定时任务,确保任务按预定时间和频率执行。其核心概念包括Job(任务)、Trigger(触发器)、Executor(执行器)和Scheduler(调度器)。这类框架应具备任务管理、任务监控、良好的可扩展性和高可用性等功能。常用的Java生态中的分布式任务调度框架有Quartz Scheduler、ElasticJob和XXL-JOB。
825 66
|
2月前
|
存储 Prometheus Cloud Native
分布式系统架构6:链路追踪
本文深入探讨了分布式系统中的链路追踪理论,涵盖追踪与跨度的概念、追踪系统的模块划分及数据收集的三种方式。链路追踪旨在解决复杂分布式系统中请求流转路径不清晰的问题,帮助快速定位故障和性能瓶颈。文中介绍了基于日志、服务探针和边车代理的数据收集方法,并简述了OpenTracing、OpenCensus和OpenTelemetry等链路追踪协议的发展历程及其特点。通过理解这些概念,可以更好地掌握开源链路追踪框架的使用。
104 41
|
3天前
|
机器学习/深度学习 存储
DeepSeek进阶开发与应用4:DeepSeek中的分布式训练技术
随着深度学习模型和数据集规模的扩大,单机训练已无法满足需求,分布式训练技术应运而生。DeepSeek框架支持数据并行和模型并行两种模式,通过将计算任务分配到多个节点上并行执行,显著提高训练效率。本文介绍DeepSeek中的分布式训练技术,包括配置与启动方法,帮助用户轻松实现大规模模型训练。数据并行通过`MirroredStrategy`同步梯度,适用于大多数模型;模型并行则通过`ParameterServerStrategy`异步处理大模型。DeepSeek简化了分布式环境配置,支持单机多卡和多机多卡等场景。
|
2月前
|
数据采集 人工智能 分布式计算
MaxFrame:链接大数据与AI的高效分布式计算框架深度评测与实践!
阿里云推出的MaxFrame是链接大数据与AI的分布式Python计算框架,提供类似Pandas的操作接口和分布式处理能力。本文从部署、功能验证到实际场景全面评测MaxFrame,涵盖分布式Pandas操作、大语言模型数据预处理及企业级应用。结果显示,MaxFrame在处理大规模数据时性能显著提升,代码兼容性强,适合从数据清洗到训练数据生成的全链路场景...
104 5
MaxFrame:链接大数据与AI的高效分布式计算框架深度评测与实践!
|
2月前
|
存储 缓存 安全
分布式系统架构7:本地缓存
这是小卷关于分布式系统架构学习的第10篇文章,主要介绍本地缓存的基础理论。文章分析了引入缓存的利弊,解释了缓存对CPU和I/O压力的缓解作用,并讨论了缓存的吞吐量、命中率、淘汰策略等属性。同时,对比了几种常见的本地缓存工具(如ConcurrentHashMap、Ehcache、Guava Cache和Caffeine),详细介绍了它们的访问控制、淘汰策略及扩展功能。
86 6
|
2月前
|
人工智能 分布式计算 大数据
MaxFrame 产品评测:大数据与AI融合的Python分布式计算框架
MaxFrame是阿里云MaxCompute推出的自研Python分布式计算框架,支持大规模数据处理与AI应用。它提供类似Pandas的API,简化开发流程,并兼容多种机器学习库,加速模型训练前的数据准备。MaxFrame融合大数据和AI,提升效率、促进协作、增强创新能力。尽管初次配置稍显复杂,但其强大的功能集、性能优化及开放性使其成为现代企业与研究机构的理想选择。未来有望进一步简化使用门槛并加强社区建设。
95 7
|
2月前
|
存储 关系型数据库 分布式数据库
[PolarDB实操课] 01.PolarDB分布式版架构介绍
《PolarDB实操课》之“PolarDB分布式版架构介绍”由阿里云架构师王江颖主讲。课程涵盖PolarDB-X的分布式架构、典型业务场景(如实时交易、海量数据存储等)、分布式焦点问题(如业务连续性、一致性保障等)及技术架构详解。PolarDB-X基于Share-Nothing架构,支持HTAP能力,具备高可用性和容错性,适用于多种分布式改造和迁移场景。课程链接:[https://developer.aliyun.com/live/253957](https://developer.aliyun.com/live/253957)。更多内容可访问阿里云培训中心。
[PolarDB实操课] 01.PolarDB分布式版架构介绍