架构设计：系统间通信（44）——自己动手设计ESB（5）

原创

已于 2024-11-24 08:15:11 修改 · 1.1k 阅读

25 ·

CC 4.0 BY-SA版权

文章标签：

#架构设计 #系统间通信 #1024程序员节

于 2024-09-28 16:59:16 首次发布

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

5-4、ESB-Client端的ActiveBrokerContext

本小节开始，我们将按照前文介绍的ESB-Client的核心步骤，一点一点的给出ESB-Client端和ESB-Broker进行交互的核心代码。为了方便在ESB-Client端进行ESB-Broker的交互，我们设计了一个ActiveBrokerContext类。读者可以将这个类理解为“ESB-Broker交互上下文”，在ESB-Client端中所有和ESB-Broker的交互过程都由在这里进行控制。我们首先看一下这个类中的主要定义：

    package esb.client;
    
    ......
    
    /**
     * 这是一个“上下文管理器”，用于为ESB-Client的客户端提供各种和ESB中间件相关的操作<br>
     * 例如，开始人员可以通过这个类获取当前为其服务的Active_Broker调用信息；
     * 还可以通过它主动通知某个Broker已经不可用了。<br>
     * @author yinwenjie
     */
    public class ActiveBrokerContext {
        /**
         * 是否已经完成初始化动作
         */
        private static Boolean IS_STARTED = false;
        /**
         * 是否正在进行初始化动作
         */
        private static Boolean IS_STARTING = false;
        /**
         * ESB-Client上唯一一个ZK客户端对象
         */
        private static CuratorFramework ZK_CLIENT;
        /**
         * uuid是这个ESB-Client的唯一编号。用来识别究竟是哪个ESB-Client变更了远程ESB-Broker的状态的
         */
        private final static String CLIENT_UUID = UUID.randomUUID().toString();
        /**
         * 日志
         */
        private final static Log LOGGER = LogFactory.getLog(ActiveBrokerContext.class);
        /**
         * 启动ESB-Client的上下文
         * @param zkConnectings 实例程序中为："192.168.61.140:2181"
         * @return
         */
        public Boolean start(String zkConnectings) {......}
        /**
         * 这个方法将从当前“active_Broker” Path Node的所有子节点中
         * 选择一个可用的节点作为为本ESB-Client服务的节点
         * @return 
         */
        public ESBBrokerInfo randomTarget() {......}
        /**
         * 该方法用于向ZK服务端报告当前ESB-Broker出现错误
         */
        public void reportTargetError() {......}
        /**
         * 向外部调用者返回当前ESB-Client的唯一编号
         * @return
         */
        public String getUUID() {......}
        /**
         * 这个私有方法才是主要的选择方法，由start()方法和randomTarget()方法重用
         * @return
         */
        private ESBBrokerInfo doRandomTarget() {......}
    }

以上代码片段中每一个重要的静态变量和公共方法的作用都已经通过相应的注解说明的比较清楚了，唯一要说明的是doRandomTarget这个私有方法。在上一小节中的图例说明中，我们可以看到“选择一个ESB-Broker”这个操作由两个事件原由：一个是“完成业务部分的启动”后进行触发，另一个是由ZK服务端产生的事件触发。不过无论是哪一种事件原由触发的其选择ESB-Broker的过程都是相同的，所以我们试图通过一个名叫doRandomTarget的私有方法重用这一部分代码。

5-5、ESB-Client选择ESB-Broker

选择的核心过程是比较简单的，既是通过一个随机数并基于当前从zk服务端查询到的所有服务器的数量进行区域操作即可。取余的结果将是这个ESB-Client所选择的ESB-Broker在整个ESB-Brokers集合中的索引位置的依据，如下图所示：

作为ESB中间件的设计和开发人员，您当然可以采用其它算法过程来计算为这个ESB-Client所服务的ESB-Broker。例如，您可以以ESB-Broker已经关联的ESB-Client的数量为权重依据，计算新的ESB-Client所关联的ESB-Broker。在这种加权计算方式中，当前较少关联ESB-Client的ESB-Broker将被有限分配给新的ESB-Client进行服务。但是真的计算方式也对已有的数据组织结构和算法过程提出了新的要求：

您要知道当前每个ESB-Broker下已经关联了哪些ESB-Client，就至少需要在zookeeper服务端的每一个ESB-Broker Path Node下记录这些ESB-Client信息，那么ESB-Broker Path Node的特性就不能是EPHEMERAL（临时节点）类型的，因为 zookeeper规定临时节点Path Node下不能创建子节点 。如果您非要这么做，那么已设计好的ESB-Broker节点的变化事件通知机制就要连带做相应的调整。
另外由于计算方式所依据的权中是当前ESB-Broker所关联的ESB-Client数量，那么为了保证这个权值依据是准确的，就需要当前同时启动的多个ESB-Client在选择“为自己服务的ESB-Broker节点”这一步骤时一个一个的进行顺序启动，否则权值数据就会不准确。这相较于“取余”的计算方式下不要求ESB-Client一个一个进行顺序启动而言，前者需要编写更多的控制代码：您需要利用zookeeper提供的EPHEMERAL_SEQUENTIAL特性来控制当前