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最终将这些散落的配置、代码组成一个完成可运