企业信创中间件落地的 9 个实践经验：从选型测试到使用和运维

背景

随着各个行业对IT系统建设自主可控要求的提升，各个企业对信创中间件的使用范围也越来越广、深度越来越深。与此同时，信创中间件涉及的产品和种类也是多种多样，对于一个企业而言要从哪些维度来评估信创中间件，从而选择适合自己的信创中间件产品，以及在使用信创中间件过程中有哪些注意事项？笔者将基于一些实践（本文实践主要是针对Java程序的开发与部署实践，其他语言程序不在本次讨论范围内），从POC阶段到上线运行以及运维的全生命周期进行总结分析，希望通过本文的相关分享为行业信创中间件的发展和使用做出贡献。另外，为避免倾向性，本文所讨论的中间件选型与落地实践都不会涉及具体品牌，重点会围绕9个大方面进行：选型、测试、使用和运维信创中间件时的一些实践经验和注意事项讲解。

一、POC产品范围确定

目前面向企业市场的信创中间件品牌众多，在POC阶段应该如何确认需要选择哪些品牌进行测试，缩小POC的范围？在笔者看来建议从以下几个方面进行参考。

（1）市场占有率。市场占有率高的产品未必是最好的产品，但是至少说明通过市场的检验，用户的认可度较高，同时占有率高的产品遇到的问题也相对多些，产品优化迭代更加高效；

（2）技术栈类型。根据笔者实践调研，目前市面上主流的一些中间件厂商，其产品的技术栈是有相似的也有完全不同的，那么在确认POC范围的时候建议兼顾多种技术栈类型的中间件进行测试；

（3）功能性需求。根据笔者的经验，由于信创中间件的推广与使用也就是近几年开始的，其功能相比于非信创中间件而言还是存在一些缺失。目前常用的中间件涉及java容器、web负载、缓存、消息队列、数据同步等，种类较多。因此，在进行功能性验证的时候，建议针对不同的信创中间件参考对应的非信创中间件形成常用的功能性需求清单，在测试阶段逐项进行打分测评。例如可以从以下几个方面进行：缓存中间件的清理策略可选性；中间件的并发连接数/吞吐量/响应时间；中间件与现有开发框架的兼容性；数据同步中间件在同步数据时可选的数据校验方式较少或者不支持等；消息中间件存在消息丢失的情况等；

（4）非功能性需求。根据笔者的经验，信创中间件在非功能性需求满足上也存在不少问题，建议梳理非功能性需求清单进行测试验证，可以从以下几个方面进行：中间件的安全与认证；中间件的安装流程与启动停止是否可自动化；中间件的日志是否会自动轮转；中间件与公司现有的平台能否集成；中间件是否具备监控能力等；中间件启动后占用的资源情况等；

（5）厂商响应情况。一般而言，在交流沟通阶段都多多少少存在一些问题，这些问题也会反馈给相应的厂商，有些厂商在接到反馈的问题后会及时进行反馈，有些厂商对反馈的问题响应较差，这也可以从一定维度反应出厂商对本次交流客户的重视程度。

因此，笔者认为在POC范围确定阶段，可以根据自身实际情况并结合以上五点进行。

二、应用程序适配改造成本评估

应用程序在进行信创中间件适配成本评估建议从以下几个方面进行参考。

（1）应用程序包与配置分离的配置方式是否简明清晰。目前应用程序的部署一般都是采用应用程序包与配置分离的方式或者使用配置中心的方式来管理配置，并且一般都会与自动化流水线绑定，符合原先的管理要求和标准的配置分离方式在降低开发人员适配成本的同时也可以尽可能复用原先的自动化流水线提升应用部署效率；

（2）部署说明文档是否清晰。根据笔者的经验，有些信创中间件产品在部署文档描述方面十分清晰，同时会将常见的一些问题与解决方案进行说明，便于开发人员快速完成部署，并且能够基于清晰的说明文档进行参数的设置与调优，有些部署文档逻辑性较差，重点不突出，属于功能点的罗列，开发人员阅读和使用成本较高；

（3）依赖包适配性。众所周知，不同类型的java程序在运行时需要依赖的jar包是不同，在笔者看来，信创中间件对jar包依赖的通用型越强越好，这样应用程序基本无需调整jar包和相关代码就可以运行相关程序。例如，在信创缓存的适配过程中，如果应用程序原先是使用redis作为缓存，并且使用的是jedis作为jar包，那么如果信创中间件能够兼容jedis，这样应用程序就无需对jar包和代码进行调整，实现信创缓存中间件的平滑迁移。

三、性能测试方面

在性能测试方面，笔者建议的方式是先选定原先使用的中间件测试数据作为性能基线，然后分别测试不同信创品牌的其他中间件产品将测试结果进行对比。例如，使用相同的测试用例测试redis的缓存读能力，然后再测试其他同类型信创缓存产品的缓存读能力。另外在笔者看来，由于一些客观存在的情况，信创中间件的某些性能指标低于目前在用的中间件属于正常情况，性能测试时应该更加关注企业自身在使用过程中更加关注的指标项，而不是关注所有指标。例如，如果一家企业的缓存中间件主要用于缓存读，并且不做持久化操作，那么在测试阶段不必过于关注持久化的性能情况；再如，如果企业使用java容器主要用于短连接的场景，那么对于长连接的性能测试指标无需过于关注。

四、稳定性测试方面

针对信创中间件类产品，笔者建议应至少通过1个月的稳定性实践测试。针对java容器、负载均衡、缓存、消息等各种类型的信创中间件设计测试场景，使得这些中间件在测试场景中运行1个月的时间，记录这1个月内的各类型中间件的运行情况。根据笔者经验，以下场景是可能在1个月的稳定测试期间发生的。（1）内存溢出。内存溢出分为两种情况一种是应用程序代码编写有问题导致的内存溢出，这类场景与信创中间件本身无关；另外一种是信创中间件自身问题导致的内存溢出，出现这种问题的信创中间件如果厂商目前还没有修复的版本，那么该中间件基本不可用；（2）运行越久，响应越慢。这类场景其实和第一种场景类似，都是需要程序运行一段时间后才能发现并处理。

五、信创中间件高可用方面

信创中间件在高可用方面要分两类产品架构形态，一类是基于分布式架构的信创中间件，另外一类是基于传统双节点架构的主备或者双活形态。

第一类是基于分布式架构的信创中间件，其高可用实现主要是基于分布式的Paxos、Raft等协议实现。Paxos协议是用于分布式系统中实现一致性的协议，其主要目的是保证系统在出现故障或网络分区的情况下仍能保持数据的一致性，该协议主要是通过多数派决策和日志复制实现分布式系统的高可用。Raft协议通过选主机制、日志复制、心跳机制和集群成员变更等技术手段来保证分布式系统在故障和网络分区的情况下依然能够保持数据的一致性和高可用性。结合分布式架构中间件的高可用原理，设计如下测试验证场景，以三节点的分布式中间件高可用为例，（1）停止一个节点上的任意一个服务进程；（2）停止一个节点上的所有进程；（3）在一个节点上重复启动服务进程；（4）停止master节点；（5）停止证书所在节点。

根据笔者经验，在以上4个场景中，（1）和（4）是企业基本都会测试的场景，（2）、（3）和（5）是比较容易被忽略的测试场景，但实际上这三个场景是非常重要的，有的分布式信创中间件高可用只支持单守护进程异常时服务的高可用，这种情况在（2）场景中就可以测试出来；有的分布式信创中间件没有处理好进程重复加载的情况，这种情况在（3）场景中就可以测试出来；信创中间件和非信创中间件一个重大的区别是需要配置证书，因此就需要测试停止证书所在节点与停止非证书所在节点对高可用的不同影响，这种情况在（5）场景中就可以测试出来，如下表：

第二类是双节点集群架构的信创中间件，这类中间件又涉及主备和双活两种类型，其实现高可用其使用的原理基本是集群间内存复制。测试时，可以将集群中的一个节点shutdown，看负载是否能够自动的切换到另外的节点，以及业务的影响是多少时间。基于集群间内存复制的这种方式会导致消耗额外的资源从而导致中间件性能下降明显，因此，一般情况下不推荐使用，而是推荐使用在双节点前部署负载均衡的方式进行应用服务的高可用设置。

六、产品成熟度方向

信创中间件相比于非信创中间件产品由于使用量上的以及使用的行业的差异，还在存在一些成熟度的问题。笔者列举两个在实际使用中遇到的问题。（1）启动脚本权限。在笔者的实际测试和使用过程中发现有些信创中间件只能使用root权限启动（其在启动脚本中使用了只有root才能设置的参数或者命令），这就带来一个管理问题的挑战。对于绝大多数形成了一个管理规范的企业而言，其应用程序是不能够使用root作为启动用户的，针对这种情况，就需要对信创中间件的启动脚本进行改造，对于不能进行改造的需要反馈给相关厂商进行修复，以满足企业自身的管理规范；（2）临时文件权限。这个问题和第六个问题的本质是相同的，由于有些信创中间件在设计的时候是使用root作为启动用户，这就导致其很多情况下会把中间件启动和运行过程中使用的临时文件放在/tmp目录下，但是由于tmp目录默认是root用户才可以读写，如果此时应用程序使用的非root用户启动，就会导致应用程序无法读写/tmp目录下的文件，从而导致程序运行出现问题。针对此类问题，需要在中间件的配置文件中设置临时文件的路径，将临时文件设置到应用程序用户有权限读写的路径上。

七、控制台的使用方面

根据笔者的测试，目前信创中间件绝大多数都提供了控制台的能力。控制台的优点是：

（1）易用性。中间件控制台提供了一个直观的图形化界面，使得用户可以轻松地管理和监控中间件组件，而无需具备深厚的技术背景；

（2）集中管理。中间件控制台可以集中管理企业的多个中间件实例，方便用户统一进行配置、监控和故障排查；

（3）实时监控。中间件控制台可以实时展示系统的运行状况，包括性能指标、资源使用情况。

但是使用控制台也会带来一些缺点：

（1）性能开销。控制台在运行过程中一般需要额外消耗主机资源，带来性能方面的开销。

（2）安全问题。控制台一般也是由java程序编写，这就有可能会引入一些java程序或者依赖框架带来的安全问题，处理由于控制台带来的安全问题也是对人力资源的一笔不小的开销。

（3）不利于深入了解中间件。控制台通过封装的方式将一些配置和功能以更加友好的方式展示出来，但是与此同时就是不便于开发和运维人员了解中间件运行底层使用的配置文件和相关脚本，一方面不理解开发和运维人员的深度使用和运维；另一方面在遇到故障需要处理时也会降低问题的处理效率。

因此，综合评估，笔者是不太建议使用控制台进行中间件管理的。

八、授权证书管理

信创中间件都需要使用授权证书才能运行，从便于管理的角度出发，笔者的经验是将同一类中间件的授权证书放置到统一的标准路径下，这样一方面为中间件的自动化安装和配置提供了标准化支持，另外一方面提高了证书管理的便捷性，方便快速统计出证书的数量以及版本，为正式授权的采购提供参考依据。信创中间件的授权证书与应用程序的版本之间也存在一定的对应关系，有些情况下程序在启动的时候显示授权证书没有问题，但是在运行过程中的日志会有关于证书的报错，根据笔者遇到此类问题的经验一般是信创中间件的授权认证模块出现bug，此类报错不一定会影响程序的正常运行，但是可能存在潜在的隐患，因此，针对此类问题建议和厂商进行确认，确保授权证书与信创中间件版本的严格匹配，消除潜在隐患。

九、可选范围较少的信创中间件评估

有些类型的信创中间件在市面上可选的范围较少，可能只有2家左右，并且价格高、性能差。针对这种类型的信创中间件，笔者的建议是如果不是必须进行适配改造，可以先暂缓，如果这种类型的信创中间件确实需求较大，那么市场上大概率出会出现更多的同类产品供选择。如果确实是需要进行适配改造，笔者的建议是先少量采购，并且在一些非核心系统上使用，总结各种使用经验，企业也需要与厂商的技术支持明确服务SLA，以便在出现问题时能够及时得到支持。