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

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

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

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

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

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

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

　　未完待续……