学海无涯，行者无疆

首先简单聊下背景，大概是几年前，工作中遇到这么一个复杂的应用场景，大型企业中的物流系统，需要跟众多的内外部系统交互，对接的系统达到十几个，接口数量在50个左右，并且后续还会大量增加新的对接方，并且很多对接方是类似的，例如跟汽运物流厂商的运输管理系统TMS，进行运输委托、运力反馈、运费结算、签收回传等交互。API服务：物流接口平台对外提供统一的数据接口服务，其他应用系统通过调用API服务，一方面，可以查询权限范围内的物流数据，另一方面，可以将自身系统产生的数据推送至物流系统。

API服务是通用接口平台的主体部分，对外暴露Restful风格的数据接口，其他应用系统通过调用API服务，一方面，可以查询权限范围内的物流数据，另一方面，可以将自身系统产生的数据推送至物流系统。API服务的技术实现相对消息服务而言，难度较低，注意事项也比较少，这里先放一个整体设计，细节后面在消息服务后面再展开介绍。总体设计API服务分为服务技术框架和具体业务功能接口两部分，技术框架部分负责统一调度、数据验证、身份认证、安全控制、日志记录等职责，具体业务功能接口负责实际的业务接口功能处理，总体处理流程如

先来回顾下API服务的整体设计。API服务是通用接口平台的主体部分，对外暴露Restful风格的数据接口，其他应用系统通过调用API服务，一方面，可以查询权限范围内的业务数据，另一方面，可以将自身系统产生的数据推送至接口平台。

上篇介绍了使用职责链模式实现了API服务的框架设计与实现，并定义了一个简单的数据验证过滤器ValidateDataFilter来做测试，今天我们把数据验证功能给实现了。。为保证系统的稳定可靠运行，必须对输入的数据进行严格验证，防止一些非法的异常数据引发系统后续处理流程出错甚至崩溃。同时，对于验证失败的情况，需要输出明确的、友好的错误信息，以便对接方开发和调试，以及上线后运行异常排查。数据验证实际分为两大类工作，一类是基本的数据验证，主要是验证输入参数是否为空等；

前面说完了数据验证，接下来就进入的关键的业务处理环节，这里我们同样定义了一个业务处理的过滤器，通过API服务对象的处理器属性，通过反射方式实例化，调用处理，获取返回。这里同样使用了Hibernate框架的Validator组件，对业务请求数据进行数据验证。

接口开放平台关于API服务部分，采用Restful接口，技术实现使用SpringMVC，没什么可多说的。而消息服务这块，则面临着使用什么样的技术实现。

对于消息通知的处理，我们设计的是发布-订阅者模式，消息中心在消息的生产者和消费者之间充当经纪人角色，负责二者的解耦，对于生产者来说，不需要知道会被哪些消费者消费，对于消费者来说，也不需要知道消息是怎么产生的，由消息中心进行逻辑处理和调度，包括消息的解析、复制、转发等。消息服务实际是一个独立的系统，性质上又分为两类，一类是消息服务端，我们称之为消息服务中心；另外一类是消息客户端，并且这个消息客户端，有可能是消息的生产者，也可能是消息的消费者，甚至是两种角色兼而有之。

接口平台通过消息服务来通知对接系统数据的变化，避免轮询，这些消息，本质上是业务事件。例如，对于物流这个业务场景下的交货单，在单据创建、委托下达、车辆进厂、车辆离厂、客户签收等事件产生时，给相关系统推送一条消息，简要通知事件信息，如单据的新增、修改、作废，只需要消息中携带单号和类型即可。

错误编码错误信息S001消息ID不能为空S002消息主题不能为空S003消息发布者不能为空S004发布时间不能为空S005发布时间格式不正确S006消息签名不能为空S101消息主题不存在S102消息主题不可用S201应用标识无效S202应用被停用S301应用无权限S401发布时间超出合理范围S501签名无效S999未定义错误+具体异常信息业务级错误定义参见各具体的消息服务。

netty的标准启动模式，实例化两个EventLoopGroup，bossGroup用于接受客户端连接，workerGroup用于实际业务处理。使用nio消息通道NioServerSocketChannel。监听的端口通过读取配置文件实现。启动、捕获异常，最后进行优雅的关闭。同时附加了一个消息重发的定时器任务。

同时我们覆写了channelInactive事件，当通道失效时，从全局的已连接的客户端列表中移除保存的客户端连接对象，实际上及时清理无效的客户端连接，算是一种冗余处理，避免一些异常情况，客户端和服务端的通道仍存在，但实际已失效的情况。我们将消息设计为两大类，请求消息和响应消息，这里通过自己实现的一个处理器，将客户端传来的文本帧，通过消息类型属性反序列化成请求消息对象或响应消息对象，然后继续往下传递。我们的心跳策略是客户端来发送心跳，服务端响应心跳，客户端发现服务端未及时响应心跳时，认为通道异常，进行重连。

前面我们介绍了服务端的消息处理链条上各处理器的配置，这部分实际相当于技术框架，今天我们来介绍下处理具体业务消息的处理器。处理框架由几个主要的部分组成：1.消息主题：我们根据业务需求，将事件转换为消息主题，消息主题相当于是对不同类型的消息进行分类，是我们实现业务处理的基础支撑部分。2.消息处理器工厂：根据消息主题来查找对应的处理器完整类名，然后通过反射技术来创建具体的消息处理器对象。

前面我们介绍了服务端的消息处理链条上各处理器的配置，这部分实际相当于技术框架，今天我们来介绍下处理具体业务消息的处理器。处理框架由几个主要的部分组成：1.消息主题：我们根据业务需求，将事件转换为消息主题，消息主题相当于是对不同类型的消息进行分类，是我们实现业务处理的基础支撑部分。2.消息处理器工厂：根据消息主题来查找对应的处理器完整类名，然后通过反射技术来创建具体的消息处理器对象。

消息日志是监控系统正常运行及异常排查的重要依据。日志分为两部分，一部分是磁盘日志，记录收到和发出的所有消息具体内容，这部分日志以文本的形式存储在磁盘文件上，主要用于异常排查，但实际查看并不方便。为了实现系统监控的的目的，建立消息日志的库表，在消息发送与接收时，更新到库表记录中，同时，保存消息状态和发送次数等辅助信息，依据该库表和辅助信息，实现消息的重发功能。

前面我们介绍了服务端，对接收到的消息，无论是请求消息还是响应消息，我们都是将消息主题传入工厂，构建对应的处理器进行处理。同理，对于发送的消息，我们也可以采用相同的处理模式。这里面有个问题需要思考，发送器与消息的关系是什么？发送器相当于业务消息的封装，消息的参数是通过发送器属性设置，还是调用发送方法时作为方法参数处理？实际上，这两种方式都能实现我们的目的，具体分析如下：对于发送器对应的消息主题，我们希望具体的发送器直接内置固化，不能交由外部传入，否则会造成混乱，因此使用构造参数的方法来设置。

消息服务通信机制为异步，且网络连接不是100%可靠，会因为网络闪断问题丢失消息，作为企业应用，需要保证业务消息传输的可靠性，需实现以下机制：a)发送方重发机制：消息发送方对未收到响应的消息进行重发，重发时保证消息唯一性标识、消息内容不变b)接收方消息去重机制：消息接收方依据消息的唯一性标识，对收到的消息进行验证，判断是否已处理过，如已处理过则不再进行处理​今天我们来重点说一下消息服务端消息重发的设计与实现。​实现思路比较简单，通过消息日志表，来缓存待发送或发送失败的消息，然后通过定时器，来执行一

前面说完了整体处理流程，接下来的几篇，从一些专题角度做一些补充，部分地方前面提到过，但没有具体展开说，今天我们来说下消息验证。为保证系统的稳定可靠运行，必须对输入的数据进行严格验证，防止一些非法的异常数据引发系统后续处理流程出错甚至崩溃。同时，对于验证失败的情况，需要输出明确的、友好的错误信息，以便对接方开发和调试，以及上线后运行异常排查。验证工作主要包括以下内容：1.验证消息对象的属性，如是否为空、格式是否正确，属于基础验证工作。

服务端需要维护客户端的通道列表，以便在需要时可以主动向客户端推送消息，这时候我们就需要一个全局容器。​我们定义了一个线程安全的 ConcurrentMap<String, Channel>对象，当客户端身份认证成功后，加入到集合中；当通道失效时，从集合中移除，这里有两种情况，一种是服务端检测到客户端不再发送心跳，另一种是客户端主动断开连接。注意为通道添加属性是netty特定的处理方式，需要定义一个 AttributeKey对象。/** * 服务端容器 * @author wqliu

服务端部分前面已介绍完成，今天开始我们介绍客户端部分。客户端对应的模块是cip-client，本质上是独立部署和运行的，放在平台工程中仅为了方便管理。客户端部分设计与实现与服务端非常类似，甚至是公用同一个类，我们重点介绍下有差异的地方。

上篇说了，我们除了使用netty内置的处理器外，还自定义了10个处理器用于实现自己的业务处理，所有处理器清单如下：我们的心跳策略是客户端来发送心跳，服务端响应心跳，客户端发现服务端未及时响应心跳时，认为通道异常，进行重连。这个处理器实际是配合netty内置的空闲检测处理器IdleStateHandler使用的，只有满足IdleStateHandler中设置的触发条件，才会触发本处理器中的userEventTriggered方法，执行自定义的逻辑操作。客户端每隔固定时间频率向服务器端发送心跳，WebSocke

前面我们介绍了客户端的消息处理链条上各处理器的配置，这部分实际相当于技术框架，今天我们来介绍下处理具体业务消息的处理器。处理框架由几个主要的部分组成：1.消息主题：我们根据业务需求，将事件转换为消息主题，消息主题相当于是对不同类型的消息进行分类，是我们实现业务处理的基础支撑部分。2.消息处理器工厂：根据消息主题来查找对应的处理器完整类名，然后通过反射技术来创建具体的消息处理器对象。

前面我们介绍了服务端消息发送器的设计与实现，客户端非常相似，这里仅介绍有差异的地方。客户端的消息主题和消息发送器工厂实现，与服务端完全相同，仅在消息发送器方面有点差异。消息发送有两个维度，按消息类型分为请求和响应，按发送场景分为新创建和重发，组合出4种情况，但按照我们对于消息传输可靠性的设计思路，由消息发送方对消息进行重发，因此实际并不需要对响应消息重发。余下的三种情况，因为客户端只连了消息中心这一个服务端，因此，所有消息都发往消息中心即可。

作为生产者角色的消息客户端，还需要接收来自业务系统的事件，然后将其转换为请求消息，发送给服务端。这里有两种方案，方案1是业务系统与消息客户端独立部署，业务系统通过调用消息客户端暴露的rest服务来推送业务数据；方案2是消息客户端内置于业务系统中，业务系统直接调用消息客户端服务层的方法。这里我们采用方案1，做一个控制器，对外接收rest请求，业务系统传入事件（必填）与单据标识（非必填，某些事件为全局，无标识的概念）。前面提过，我们约定将事件的编码与消息主题编码保持一致。

客户端与服务端互相推送消息的前提是双方互信，也就是说，需要身份认证。身份认证同样有多种方案，这里我们采用比较常规的方式，即客户端使用账号和密钥来发送1条登录请求消息，服务端收到后进行认证，认证通过后，向客户端推送一条登录成功的响应消息，并将当前通道放到全局容器，用于后续从服务端主动向客户端推送消息；客户端收到登录成功消息后，将通道保存到全局容器，用于后续从客户端主动推送消息到服务端。

消息服务采用的发布订阅者模式，由消息生产者将消息发送到消息服务中心，由消息服务中心完成消息的复制及转发至消息消费者。从过程看，可以看成两段交互，一是生产者到消息中心，二是从消息中心到消费者。以委托单创建这一业务消息为例，我们来实现这两个过程。在前面已经实现了消息客户端接收器的情况下，我们在客户端和服务端完成登录认证的情况下，访问以下地址，

我们对于消息服务这块的整体设计是客户端连接服务端后，发起身份认证，携带应用编码和密钥，并对密钥进行了hash加密，服务端认证通过后，建立长连接。对于长连接，我们认为是安全，恶意用户无法直接往长连接通道中发送一条伪造的消息，因此没有必要对每条消息进行签名和验签，从而提升了性能。但这里还有一个小漏洞，未认证的应用是防住了，已认证的应用如果进行一些越权操作如何应对呢？

前面我们说过，心跳策略是客户端来发送心跳，服务端响应心跳，客户端发现服务端未及时响应心跳时，认为通道异常，进行重连。客户端每隔固定时间频率向服务器端发送心跳，WebSocket协议约定的PingWebSocketFrame，服务端收到后马上会回复PongWebSocketFrame，如通道失效或服务端无响应情况下，就会触发客户端读空闲。心跳机制是保障长连接有效性的重要手段，我们原先的设计，是在客户端实现一个自定义的处理器。

上篇我们对心跳的发送时机做了优化，客户端从握手成功即发送心跳，调整为在登录成功后，才启动心跳发送，从而使心跳机制起到保障客户端与服务端真正建立并保持逻辑上的业务消息通道的有效性。我们再回顾下心跳机制的策略：客户端来发送心跳，服务端响应心跳，客户端发现服务端未及时响应心跳时，认为通道异常，进行重连。

今天我们来做一个优化，即实现消息处理器的复用，注意这里的复用，不是指同一个消息处理器在消息的客户端和服务端进行复用，而是指在多个消息通道中复用。

消息服务通信机制为异步，且网络连接不是100%可靠，会因为网络闪断问题丢失消息，作为企业应用，需要保证业务消息传输的可靠性，需实现以下机制：a)发送方重发机制：消息发送方对未收到响应的消息进行重发，重发时保证消息唯一性标识、消息内容不变b)接收方消息去重机制：消息接收方依据消息的唯一性标识，对收到的消息进行验证，判断是否已处理过，如已处理过则不再进行处理。

在本系列的前面一篇博客评论中，有小伙伴指出，API服务存在线程安全问题：https://blog.csdn.net/seawaving/article/details/122905199今天来确认下，线程是否安全？如不安全，如何修复？