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

  二、配置文件的简化

  通讯格局统一后,我们对通讯配置文件进行了五回较大的简化,从原先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对微服务架构提供的最直接、最好的支撑了,帮忙工作程序员从观念的支付情势转变,进而适应微服务的盘算情势。

图片 1

 

MSDN Windows Phone
7论坛(英文)

  三、节点间的报道关系安排

  下边我们关系配置文件只定义了节点的劳务名,那么如此多的微服务节点是咋样结合起来工作的?一个作业应用体系会由许多的微服务一起手拉手提供劳务,这多少个劳动对于每个不同的现场恐怕效果是不相同的,或者说微服务汇集是不雷同的。那么,对这多少个微服务的整合的历程就像一个“编排”的长河。通过“编排”,采用适宜的微服务举行铺垫组合提供劳务,而编辑的进程就是大家报道建立的经过。下边大家就来看一下CDRAF是如何做到“编排”效率的。

  图片 2

图片 3

  下边的率先张表,描述了具有的微服务列表,所有节点服务要向外通讯都无法不到那张表中增添对应的服务名,这里的服务名是与眼前配置文件中的服务名相对应的。第二张表描述了这多少个微服务名以内的通讯关系,比如第二条记下表明的是OCDis程序的OCDis2CDRDis到CDRDis的OCDis2CDRDis之间会有一个报道关系。只要通过这些简单的配备,就可以成功几个节点间的通讯关系的树立。这样的设计会带动多少个便宜。

  1、对于一个犬牙交错的系统,可能有几十类微服务节点,运行实例可能有广大个,如若有上边的表二,就可以容器的从地点的数据中画出整个集群的实时拓扑图,这一个对于系统的监控是很是首要的。

  2、集群通讯关系的计划性上升了一个阶段,业务程序员只需要遵照模块接口设计提供相应的微服务节点,而不需要关注与此外微服务是什么协调工作的。而这多少个微服务怎样“编排”提高到了架构师的办事范围的层级。这显明是对复杂度举办分层隔离很好的一个范例。

  3、运维或者管理人士,通过表二的安排可以很容易地操作集群里的某个微服务下线或者上线。在一个宏大的集群里面,假如某类微服务出故障,而CDARF提供了如此一种手段可以去让这类故障微服务下线,将给系统的平静带来巨大的可靠保证。

  4.、原来集群拥有的通讯都配备在一个文本中,在分布式系统中就涉嫌文件的大局一致性的题材。解决的方案或者是,假设要上线一个新类型的安排文件(新增节点、删除节点、通讯关系转移等等),就要去革新具有在网节点的布局文件。但此刻假使新的布置文件有bug,那么可能引致整个集群的故障,并且为了提高某个意义去提升总体集群拥有节点的部署也是极不合理的。在新的方案中,节点的布局只定义节点内的简报和对外提供的微服务名。那么只要要新增某系列型的微服务,不再需要去立异任何节点的配备,只需要将新节点上线,然后在下面的表一新增微服务名,表二扩张连接关系就足以了。真正形成了增量升级!

 

  未完待续……

 

正文将Windows Phone 7常用的资源举行了整理,方便大家利用。

  一、节点间通讯模式的碰面

  原来节点内的应用程序都是通讯全能应用程序,所谓全能是指应用程序既可以跟节点内的经过展开报道也能够跟节点外的擅自进程展开报道。这样乍看起来没啥问题,但只要节点数和过程数变多后,通讯关系将是一个指数级增长的进程。如下图,假设再追加一个CDR节点,或者OCS节点,连接数都将加码很是多。

  图片 4

  大家的解决办法是统一节点的简报情势,每个节点内都有一个Dis进程,统一对外承担跟其余节点举行报道。在接收外部发给节点的音信后,按照效益和负载转发给内部工作处理过程。业务经过尽管有音信需要发往其余节点,就一直发放Dis进程,由它进行转发。统一通讯形式带来的功利除了在节点和经过增多后,通讯关系不会变得太复杂以外。由于形式统一,
CDARF可以替业务程序员完成很多工作,间接的利益就是事情程序员不再需要安排很多与事务无关的配置。最大化的将报道模块的复杂度留给CDRAF去处理,业务程序员将进而在意于我的工作逻辑。下边的图中其实系统起先已经有微服务的样板,但大家期望完成的不仅是从系统架构上是微服务架构,在程序员开发顺序的时候,也应有是带着微服务思维的,我们的CDRAF应该提供这么一种力量来支撑那种支付形式。

  图片 5

 

Windows Phone 7 –
CodeProject

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

 技术交换合作QQ群:436466587 欢迎啄磨互换

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

 

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

 

  OCS(online charging
system,在线计费系统)在展开云化改造的历程中,从实用主义角度出发,微服务架构并不是我们的对象。尽管我们也对系统举行了容器化改造(Docker),并依照作业过程的法力将系统分为了一些类的容器,但这一体多是出于对系统中的某些处理节点举办动态扩缩容的内需,跟微服务半点关系尚未。随着系统改造
的记忆犹新,系统的报导关系复杂程度开首超越我们前面的估摸。尽管说数量过多的职能节点还有人可以勉强了解,那多少个节点间错综复杂的简报关系连线已超越程序员可以掌握的层面。在谈论哪些简化程序员实现全类别统各项节点的通讯关系的布局过程中,节点微服务化的见地日益进入我们的脑海之中……

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

图片 6

 

  还记得第二篇《基于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正是起这样一个见仁见智模块的大桥(接口)的功用。

以身作则代码.aspx)

延续我将会时常更新其中的资源,我们只要有好的资源请留言,我好编辑到本文中。

微软Windows Phone
Portal

Windows Phone
7粤语开发焦点

Microsoft Silverlight 4
在线协理文档(MSDN)(简体闽南语)
.aspx)

Windows Phone 7
开发者训练包

Windows Phone
Newsroom

Inside Windows
Phone视频教程(英文)

CSDN Windows Mobile论坛

微软Windows Phone
Home

Windows Phone开发者网站

Windows Phone 7
开发者训练包(闽南语版)

!fanr Live

WPMind论坛

智机网

Windows Phone 7 Jump
Start录像教程(英文)

MSDN Windows
移动设备论坛(普通话)

2.微软官方资料

3.论坛

MSDN在线协理文档.aspx)

1.工具下载



WP7爱好者

MSDN Windows
Phone首页

Codeplex Windows Phone
7

4.WP7常用站点

WPMind

Silverlight for Windows
Phone

Expression Blend 4 for Windows
Phone

Windows Phoen团队博客

离线安装包(推荐)

Microsoft Silverlight 4
脱机文档(简体中文)

开发工具包更新(2010.10)

在线安装包