本发明涉及通讯技术领域，尤其涉及通讯地址发现机制技术领域，具体是指一种基于第三方数据库实现业务节点通讯地址发现的方法。
背景技术：
在传统的bras(broadbandremoteaccessserver，宽带远程接入服务器)设备中，控制面、转发面都是专有定制化单板，单板之间都是通过机架的背板进行数据交换的。整个机架环境都是固定的、稳定的、整体的，所以单板间或者单板内的业务进程进行数据交互时，可以采用固定的逻辑地址，譬如，采用tipc作为底层通讯机制时，可以根据机架号、槽位号、cpu号、业务编号等等信息来编制固定不变的逻辑地址。这样各个业务进程启动后，可以直接向其它业务进程发送数据。
但是，在vbras设备中，控制面、转发面都是普通的服务器，甚至是虚拟机或者docker(一种开源的应用容器引擎)实例。服务器、虚拟机可能是跨操作系统的，甚至服务器都部署在不同的地址位置上。那么控制面与转发面之间的业务进程需要进行数据通讯时，就无法使用固定的逻辑地址了，而需要采用物理地址进行通讯。
技术实现要素：
本发明的目的是克服了上述现有技术的缺点，提供了一种能够基于第三方数据库实现业务节点通讯地址发现的方法。
为了实现上述目的，本发明具有如下构成：
该基于第三方数据库实现业务节点通讯地址发现的方法，包括链接建立处理操作和保活状态维持处理操作，所述的链接建立处理操作，包括以下步骤：
(1)创建第一业务进程、第二业务进程和第三业务进程，将所述的第一业务进程、第二业务进程、第三业务进程链接zookeeper的动态库，并启动zookeeper服务端；
(2)启动所述的第一业务进程、第二业务进程、第三业务进程，所述的第一业务进程、第二业务进程、第三业务进程分别创建对应的zookeeper客户端，各个所述的zookeeper客户端均向所述的zookeeper服务端进行注册；
(3)所述的第一业务进程、第二业务进程、第三业务进程根据预设的通讯模型，向所述的zookeeper客户端创建不同树形的zookeeper数据库节点；
(4)所述的第一业务进程、第二业务进程、第三业务进程分别观察所述的第一业务进程、第二业务进程、第三业务进程对应的对端业务进程的数据库节点；
(5)所述的第一业务进程、第二业务进程、第三业务进程在所述的对应的对端业务进程上线并获取到所述的对应的对端业务进程的通讯地址之后，与所述的对应的对端业务进程建立tcp(transmissioncontrolprotocol，传输控制协议)链接，并发送业务数据；
所述的保活状态维持处理操作，具体如下：
在所述的zookeeper服务端与所述的zookeeper客户端以及所述的第一业务进程、第二业务进程、第三业务进程之间进行周期性的保活检测。较佳地，所述的步骤(3)具体包括以下步骤：
(3-1)所述的第一业务进程向zookeeper客户端创建数据库节点“/业务名1/server”，并向“server”节点中写入所述的第一业务进程的通讯地址；
(3-2)所述的第二业务进程和所述的第三业务进程分别向zookeeper客户端创建数据库节点“/业务名1/clients/业务名2”和“/业务名1/clients/业务名3”，并向“业务名2”节点和“业务名3”节点中对应写入所述的第二业务进程和所述的第三业务进程的通讯地址。
在一种更佳的实施方式中，所述的步骤(3-2)中在向对端业务进程发布通讯地址时，同时发布两类地址：unix地址和inet地址，其中，a).unix地址(便于host内节点连接)；b).inet地址(便于不同host上节点连接)。
在一种较佳的实施方式中，所述的第一业务进程为数据服务端、所述的第二业务进程与所述的第三业务进程为数据客户端，所述的步骤(4)具体包括以下步骤：
(4-1)所述的第一业务进程创建完成数据库节点后，所述的第一业务进程观察其相关联的数据客户端所创建的数据库节点的父节点“/业务名1/clients”，判断是否存在多个客户端在线，如果是，则继续步骤(4-2)；
(4-2)所述的第一业务进程从数据库节点“/业务名1/clients/业务名2”和“/业务名1/clients/业务名3”中读取所述的第二业务进程和所述的第三业务进程的通讯地址；
(4-3)所述的第二业务进程和所述的第三业务进程创建完成数据库节点后，判断数据库节点“/业务名1/server”是否存在，如果是，则读取所述的第一业务进程的通讯地址。
在一种较佳的实施方式中，其特征在于，所述的保活状态维持处理操作具体包括维持保活状态的第三方数据库处理子过程和维持保活状态的业务进程自身处理子过程。
在一种较佳的实施方式中，维持保活状态的第三方数据库处理子过程，包括以下步骤：
(5-1-1)所述的zookeeper服务端判断是否存在所述的zookeeper客户端保活超时，如果是，则删除该zookeeper客户端曾经创建的数据库节点，并且通知观察该删除节点的zookeeper客户端；
(5-1-2)当所述的zookeeper客户端通知所述的第一业务进程、所述的第二业务进程和所述的第三业务进程各自的观察节点的删除事件时，关闭tcp链接；
(5-1-3)当所述的zookeeper客户端通知所述的第一业务进程、第二业务进程、第三业务进程各自的观察节点的添加事件时，所述的第一业务进程检查对应的对端业务进程的当前状态，所述的第二业务进程检查对应的对端业务进程的当前状态、所述的第三业务进程检查对应的对端业务进程的当前状态；
在一种较佳的实施方式中，维持保活状态的业务进程自身处理子过程，包括以下步骤：
(5-2-1)在所述的第一业务进程、第二业务进程、第三业务进程之间建立两条链路；
(5-2-2)在所述的第一业务进程、第二业务进程、第三业务进程内部创建新的线程。
在一种较佳的实施方式中，所述的步骤(5-1-3)中，所述的第一业务进程、第二业务进程、第三业务进程分别检查对应的对端业务进程的当前状态具体包括以下步骤：
(5-1-3-1)如果所述的第一业务进程、第二业务进程、第三业务进程对应的对端业务进程的当前状态是下线状态，则继续步骤(5-1-3-2)，否则，继续步骤(5-1-3-3)；
(5-1-3-2)开始上线流程；
(5-1-3-3)所述的第一业务进程、第二业务进程、第三业务进程获取该观察节点中所述的对应的对端业务进程的通讯地址，并判断有无发生变化，如果发生变化，则继续步骤(5-1-3-3-1)，否则，继续步骤(5-1-3-3-2)；
(5-1-3-3-1)所述的第一业务进程、第二业务进程、第三业务进程关闭之前所述的tcp链接，并根据新地址建立新的tcp链接，同时判断双方业务进程是否处于同一个host内，如果所述的双方业务进程处于同一个host内，则使用unix地址同时建立两个链接；如果所述的双方业务进程在不同的host，则使用inet地址同时建立两个链接；
(5-1-3-3-2)所述的第一业务进程、第二业务进程、第三业务进程过滤此次所述的第一业务进程、第二业务进程、第三业务进程对应的对端业务上线事件。
在一种较佳的实施方式中，在步骤(5-2-2)创建新的线程中，所述的新的线程处理保活状态的维持过程，具体包括：
(5-2-2-1)保活报文的周期性发送；
(5-2-2-2)epoll所述的第一业务进程、第二业务进程、第三业务进程对应的对端业务进程间保活报文的接收。
在一种较佳的实施方式中，其特征在于，在所述的步骤(5-1-3-3-1)中，建立新的tcp链接中，需要设置md5选项。
在一种较佳的实施方式中，其特征在于，所述的两条链路进行保活检测和业务数据传输的负荷分担。
在一种较佳的实施方式中，其特征在于，进行保活检测时具体包括以下步骤：(9-1)所述的两条链路分别检测所述的第一业务进程、第二业务进程、第三业务进程对应的对端业务进程是否下线，如果是，则继续步骤(9-1-1)，否则，继续步骤(9-1-2)；
(9-1-1)确认所述的对应的对端业务进程真正下线；
(9-1-2)确认所述的对应的对端业务进程没有下线。
采用了该发明中的基于第三方数据库实现业务节点通讯地址发现的方法，在vbras环境中，业务进程可以动态的发现通讯对端的上下线事件；同时，还能够获取对端的通讯地址，并具有双重的保活机制，极大的提高业务进程间下线事件的判断准确率。避免由于错误的判断对端下线事件，而导致业务进程间发送不必要的重复性的大量数据，从而提高vbras环境中整体业务进程的稳定性，具有广泛的应用范围。
附图说明
图1为本发明的基于第三方数据库实现业务节点通讯地址发现的方法的示意图。
具体实施方式
为了能够更清楚地描述本发明的技术内容，下面结合具体实施例来进行进一步的描述。
该基于第三方数据库实现业务节点通讯地址发现的方法，包括链接建立处理操作和保活状态维持处理操作，所述的链接建立处理操作，包括以下步骤：
(1)创建第一业务进程、第二业务进程和第三业务进程，将所有业务进程链接zookeeper的动态库，并启动zookeeper服务端；
(2)启动所有业务进程，向zookeeper进行注册，并创建zookeeper客户端；
(3)所有业务进程根据预设的通讯模型，向所述的zookeeper客户端创建不同树形的zookeeper数据库节点；
(4)观察对端业务进程的数据库节点；
(5)在对端上线并获取对端的通讯地址之后，与对端建立tcp链接，并发送业务数据；
所述的保活状态维持处理操作，具体如下：
在所述的zookeeper服务端与所述的zookeeper客户端之间进行周期性的保活检测。
在一种较佳的实施方式中，所述的步骤(3)具体包括以下步骤：
(3-1)所述的第一业务进程向zookeeper客户端创建数据库节点“/业务名1/server”，并向“server”节点中写入所述的第一业务进程的通讯地址；
(3-2)所述的第二业务进程和所述的第三业务进程分别向zookeeper客户端创建数据库节点“/业务名1/clients/业务名2”和“/业务名1/clients/业务名3”，并向“业务名2”节点和“业务名3”节点中对应写入所述的第二业务进程和所述的第三业务进程的通讯地址。
在一种更佳的实施方式中，所述的步骤(3-2)中在向对端业务进程发布通讯地址时，同时发布两类地址：unix地址和inet地址，其中，a).unix地址(便于host内节点连接)；b).inet地址(便于不同host上节点连接)。
在一种较佳的实施方式中，所述的第一业务进程为数据服务端、所述的第二业务进程与所述的第三业务进程为数据客户端，所述的步骤(4)具体包括以下步骤：
(4-1)所述的第一业务进程创建完成数据库节点后，所述的第一业务进程观察其相关联的数据客户端所创建的数据库节点的父节点“/业务名1/clients”，判断是否存在多个客户端在线，如果是，则继续步骤(4-2)；
(4-2)所述的第一业务进程从数据库节点“/业务名1/clients/业务名2”和“/业务名1/clients/业务名3”中读取所述的第二业务进程和所述的第三业务进程的通讯地址；
(4-3)所述的第二业务进程和所述的第三业务进程创建完成数据库节点后，判断数据库节点“/业务名1/server”是否存在，如果是，则读取所述的第一业务进程的通讯地址。
在一种较佳的实施方式中，其特征在于，所述的保活状态维持处理操作具体包括维持保活状态的第三方数据库处理子过程和维持保活状态的业务进程自身处理子过程。
在一种较佳的实施方式中，维持保活状态的第三方数据库处理子过程，包括以下步骤：
(5-1-1)所述的zookeeper服务端判断是否存在所述的zookeeper客户端保活超时，如果是，则删除该zookeeper客户端曾经创建的数据库节点，并且通知观察该删除节点的zookeeper客户端；
(5-1-2)当所述的zookeeper客户端通知所述的第一业务进程、所述的第二业务进程和所述的第三业务进程各自的观察节点的删除事件时，关闭tcp链接；
(5-1-3)当所述的zookeeper客户端通知所述的第一业务进程、第二业务进程、第三业务进程各自的观察节点的添加事件时，所述的第一业务进程检查对应的对端业务进程的当前状态，所述的第二业务进程检查对应的对端业务进程的当前状态、所述的第三业务进程检查对应的对端业务进程的当前状态；
在一种较佳的实施方式中，维持保活状态的业务进程自身处理子过程，包括以下步骤：
(5-2-1)在所述的第一业务进程、第二业务进程、第三业务进程之间建立两条链路；
(5-2-2)在所述的第一业务进程、第二业务进程、第三业务进程内部创建新的线程。
在一种较佳的实施方式中，所述的步骤(5-1-3)中，所述的第一业务进程、第二业务进程、第三业务进程分别检查对应的对端业务进程的当前状态具体包括以下步骤：
(5-1-3-1)如果所述的第一业务进程、第二业务进程、第三业务进程对应的对端业务进程的当前状态是下线状态，则继续步骤(5-1-3-2)，否则，继续步骤(5-1-3-3)；
(5-1-3-2)开始上线流程；
(5-1-3-3)所述的第一业务进程、第二业务进程、第三业务进程获取该观察节点中所述的对应的对端业务进程的通讯地址，并判断有无发生变化，如果发生变化，则继续步骤(5-1-3-3-1)，否则，继续步骤(5-1-3-3-2)；
(5-1-3-3-1)所述的第一业务进程、第二业务进程、第三业务进程关闭之前所述的tcp链接，并根据新地址建立新的tcp链接，同时判断双方业务进程是否处于同一个host内，如果所述的双方业务进程处于同一个host内，则使用unix地址同时建立两个链接；如果所述的双方业务进程在不同的host，则使用inet地址同时建立两个链接；
(5-1-3-3-2)所述的第一业务进程、第二业务进程、第三业务进程过滤此次所述的第一业务进程、第二业务进程、第三业务进程对应的对端业务上线事件。
在一种较佳的实施方式中，在步骤(5-2-2)创建新的线程中，所述的新的线程处理保活状态的维持过程，具体包括：
(5-2-2-1)保活报文的周期性发送；
(5-2-2-2)epoll所述的第一业务进程、第二业务进程、第三业务进程对应的对端业务进程间保活报文的接收，epoll是linux进程最基础的消息守护流程，其包括一套函数调用。
在一种较佳的实施方式中，其特征在于，在所述的步骤(5-1-3-3-1)中，建立新的tcp链接中，需要设置md5选项。
在一种较佳的实施方式中，其特征在于，所述的两条链路进行保活检测和业务数据传输的负荷分担。
在一种较佳的实施方式中，其特征在于，进行保活检测时具体包括以下步骤：
(9-1)所述的两条链路分别检测所述的第一业务进程、第二业务进程、第三业务进程对应的对端业务进程是否下线，如果是，则继续步骤(9-1-1)，否则，继续步骤(9-1-2)；
(9-1-1)确认所述的对应的对端业务进程真正下线；
(9-1-2)确认所述的对应的对端业务进程没有下线。
在一种具体的实施方式中，其步骤如下：
1、每个业务进程都需要链接zookeeper的动态库；
2、优先启动zookeeper服务端；
3、业务进程1、2、3启动后，向zookeeper进行注册，创建zookeeper的客户端；
4、业务进程1、2、3根据设计好的通讯模型，向zookeeper客户端创建不同的树形zookeeper数据库节点。比如，业务进程1是数据服务端，而业务进程2、3是数据客户端，接收业务进程1发送业务数据，具体为：
业务进程1向zookeeper客户端创建数据库节点：“/业务名1/server”，同时向“server”节点中写入自己的通讯地址，比如，服务器ip地址:监听端口号；
业务进程2、3分别向zookeeper客户端创建数据库节点“/业务名1/clients/业务名2”和“/业务名1/clients/业务名3”，同时业务进程2、3分别向“业务名2”和“业务名3”节点中写入对应的通讯地址，比如，业务所在服务器的ip地址:指定的端口号，第一类地址：unix地址(便于host内业务进程建立链接)；第二类地址：inet地址(便于不同host上业务进程建立链接)，并且每一种类地址写入两个，便于在第一业务进程与第二业务进程之间，和第一业务进程与第三业务进程之间，建立两条链路。
通过第三方数据库时，除了直接通过数据库的客户端与与服务器提供的方法，来决定业务点up/down外，再在业务节点之间直接增加保活机制，来判断业务节点的up/down，一旦业务节点链接成功后，就算数据库服务端down，也不会影响业务节点之间的链路，所以大大提高业务节点之间的可靠性，其中up指对端业务进程上线，down指对端业务下线；
5、业务进程1在创建完成自己的数据库节点之后，需要观察客户端的数据库节点。比如，观察数据库节点父节点“/业务名1/clients”。如果有多个客户端在线，那么zookeeper数据库节点就会存在：“/业务名1/clients/业务名2”和“/业务名1/clients/业务名3”。业务进程1就从这两个数据库节点中读取出业务进程2、3的通讯地址。这样，业务进程1就动态地发现了业务进程2、3，并且同时获取到了它们的通讯地址；
6、业务进程2、3在创建完成自己的数据库节点之后，需要观察服务端的数据库节点。比如，观察数据库节点“/业务名1/server”。如果该数据库节点存在，则读取出业务进程1的通讯地址。这样，业务进程2或者3就动态地发现了业务进程1，并且同时获取到了服务端通讯地址；
7、在动态发现对端上线，并且获取到对端的通讯地址之后，就可以与对端建立tcp链接，并且发送业务数据；
8、zookeeper服务端与客户端之间会进行周期性的保活检测。zookeeper服务端发现某个客户端保活超时，则删除其曾经创建的数据库节点。并且通知观察该删除节点的zookeeper客户端。当zookeeper客户端通知业务进程1、2、3其观察节点的删除事件时，业务进程就动态地发现对端业务进程已经下线，这时候需要关闭tcp链接，从而不再向对端发送业务数据。
由于zookeeper服务端与客户端之间，是通过tcp链接进行的保活，并且它们可能在不同的物理位置上。那么它们之间很容易受到网络拥塞的影响而出现保活震荡。但是，进行数据通讯的业务进程之间的网络可能并没有发生拥塞，并没有发生tcp断链。那么，此时如果根据zookeeper客户端通知的数据库节点删除事件而立即判断对端下线，必然会发生误判。由于业务进程之间的通讯数据量可能非常大，比如，100万bgp路由，并且数据服务端在发现数据客户端重新上线后，需要再次把所有的数据全量发送到对端。这样的误判必然会导致业务进程之间的系统繁忙抢占cpu等资源，从而影响系统中的其它业务进程的正常运行。
具体的改进实施步骤如下：
9.1、业务进程在动态地发现对端上线并且建立tcp链接后，不仅发送正常的业务数据，同时还周期性的发送保活报文。并且开启保活检测定时器；
9.2业务进程接收到对端的正常业务数据，或者保活报文后，都需要重置保活检测定时器；
9.3、当zookeeper客户端通知业务进程其观察节点的删除事件时，业务进程检查与对端的保活检测定时器是否超时，如果没有超时，则认为对端并没有下线，继续进行数据发送；
9.4、当业务进程发现与对端的保活检测定时器超时，则无论zookeeper客户端是否通知过其观察节点的删除事件，都认为对端已经下线，此时关闭tcp链接；
9.5、当zookeeper客户端通知业务进程其观察节点的创建事件时，业务进程检查与对端当前状态：
若当前对端是下线状态，那么按照上述流程走正常上线流程；
若当前对端已经是上线状态，那么获取该观察节点中的对端通讯地址，如果没有发生变化，则过滤此时通知事件；如果有变化，则关闭之前的tcp链接，然后根据新地址重新建立tcp链接；
业务节点在向第三方数据库写入本节点的通讯地址时，加入一些链路安全的措施，比如md5、公钥等，这样能够保证业务节点之间的链路安全性，避免被攻击；
建立新的tcp链接时，需要设置md5选项。接收方收到tcp报文时，必须根据报文的信息以及自己的密钥来计算md5摘要，并与报文中的摘要进行比较。如果比较失败则丢弃报文。这样就能够极大的提高链路的安全性。
采用了该发明中的基于第三方数据库实现业务节点通讯地址发现的方法，在vbras环境中，业务进程可以动态的发现通讯对端的上下线事件；同时，还能够获取对端的通讯地址，并具有双重的保活机制，极大的提高业务进程间下线事件的判断准确率。避免由于错误的判断对端下线事件，而导致业务进程间发送不必要的重复性的大量数据，从而提高vbras环境中整体业务进程的稳定性，具有广泛的应用范围。
在此说明书中，本发明已参照其特定的实施例作了描述。但是，很显然仍可以作出各种修改和变换而不背离本发明的精神和范围。因此，说明书和附图应被认为是说明性的而非限制性的。