设为首页 加入收藏

TOP

(五):C++分布式实时应用框架——微服务架构的演进(二)
2019-09-17 19:05:35 】 浏览:67
Tags:++分布式 实时 应用 框架 服务 架构 演进
行的系统才是我们现在亟需解决的问题。相信这也是每个系统架构师所面临的问题,当一个系统的复杂度超过单个人可承受能力范围,就要对这个系统进行适当分层,分模块。让每个人去管理一小部分复杂点,并且大家只需实现好自己的模块,无需去关心别的模块的实现细节。通过事先设计好的接口,各个模块可以相互协作,整体系统是可以依此完美地运行的。这里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"}
    }
  }
}

  想像一下,对于每一个业务节点,开发人员仅需考虑节点内的业务实现逻辑,并为本节点对外所提供的服务起个名字,而不再需要关心这个服务到底是提供给谁,更不用操心谁会来连我的进程,怎么连。这是多么精妙的事情!我们不仅是从架

首页 上一页 1 2 3 下一页 尾页 2/3/3
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇副本机制与副本同步------《Desig.. 下一篇OLAP与数据仓库------《Designing..

最新文章

热门文章

Hot 文章

Python

C 语言

C++基础

大数据基础

linux编程基础

C/C++面试题目