随着各行各业对IT系统自主可控的需求不断增强，企业对信创中间件的应用越来越广泛和深入。在以往信创试点过程中，中间件是有名录的，而截止目前国测发布的《安全可靠测评结果》也未包含信创中间件，面对种类繁多的信创中间件产品，企业需要从中间件第三方评测、实际测试选型多个维度进行评估，以选择最适合自己的产品，为避免品牌倾向，本文不涉及具体品牌讨论，围绕信创中间件的定义、分类以及中间件的选型测试实践经验和注意事项而展开。
定义与分类
为解决异构问题，提出了中间件概念，中间件是位于平台（硬件和操作系统）和应用之间的通用服务，这些服务具有标准的程序接口和协议。
针对不同的操作系统和硬件平台，有符合接口和协议规范的多种实现。可以为处于上层的应用软件提供运行与开发环境，封装不同应用系统的API接口，为应用提供统一标准接口，使应用的开发、运行与操作系统解耦，屏蔽底层的技术细节差异，确保应用的独立性。
中间件位于操作系统之上，应用软件之下，处于信息系统的中间位置，故而得名。中间件并不是一种软件，而是一类软件统称；中间件不仅仅实现互连，还要实现应用之间的互操作。它犹如一道屏障，有效屏蔽了底层操作系统所具有的复杂性，从而为上层应用软件在开发、运行以及集成等诸多环节提供了极大的便利。
产品选型测试
在信创项目上马之前，为保障项目顺利推进，当前由于面向企业市场的信创中间件品牌众多，质量参差不齐等方面原因，一般都会开展POC(验证性测试)，也是业界流行的针对客户具体应用的验证性测试，而在POC阶段应该如何选择哪些品牌，缩小POC范围呢？笔者建议从以下进行考量。
1、市场占有率：虽然市场占有率高的中间件不一定是最佳选择，但它至少表明了产品经过市场验证并得到了用户广泛认可。这些产品往往问题较多，迭代更新也更为迅速。
2、技术栈兼容性：市场上的中间件技术栈各异，建议在POC阶段测试涵盖多种技术栈类型的中间件，以确保兼容性和多样性，如消息中间件、Web中间件、分布式中间件、事务性中间件等需要按照不同类型中间件确保兼容性。
3、功能性需求：鉴于信创中间件功能相对与非信创中间件差异性，如常用的中间件涉及java容器、web负载、缓存、消息队列、数据同步等，建议根据非信创中间件形成功能性需求清单，并在测试阶段对信创中间件进行逐项评估。评估指标包括缓存策略、并发吞吐性能、与开发框架的兼容性、数据同步校验方式以及消息中间件的消息丢失问题等。
通过这种方式，企业可以更准确地评估信创中间件的性能，确保它们满足业务需求，同时优化资源投入和测试重点。
5、非功能性需求：信创中间件在满足非功能性需求方面可能存在不足，建议制定非功能性需求清单，包括安全性、自动化安装、日志管理、平台集成能力和监控功能，以及资源占用情况等。
（2）性能随时间下降：随着运行时间的延长，中间件的响应速度可能会逐渐变慢。这种情况需要在测试中观察并处理，因为它可能影响长期的系统稳定性和性能。通过这样的长期稳定性测试，可以更准确地评估信创中间件在实际应用中的可靠性和性能表现，从而为企业选择适合的中间件产品提供重要依据。
7、高可靠需求：信创中间件的高可靠性测试可分为两大类架构形态：分布式架构和传统双节点架构。以下是对这两类架构的高可用性测试的总结：
分布式架构中间件：利用Paxos和Raft等分布式协议实现高可用性，确保系统在故障或网络分区情况下数据一致性。 测试场景包括停止单个服务进程、停止所有进程、重复启动服务进程、停止master节点和停止证书所在节点。特别关注那些容易被忽略的场景，如停止所有进程、重复启动服务进程和停止证书所在节点，因为这些场景对于验证分布式中间件的高可用性至关重要。
双节点架构中间件：包括主备和双活两种类型，通常基于集群间内存复制实现高可用性。测试时，通过关闭一个节点来验证负载是否能自动切换到另一个节点，以及业务受影响的时间。由于内存复制可能导致性能下降，一般建议在双节点前部署负载均衡器，以实现应用服务的高可用性，而不是依赖于集群间内存复制。
8、厂商响应速度：在沟通过程中，厂商对问题的响应速度可以反映其对客户的重视程度。一些厂商能够及时反馈，而其他厂商可能响应较慢，这可以作为评估厂商服务水平的一个指标。
结语
由于目前信创中间件的评估，国测并没有发布，市场上信创中间件的评估很多是通过第三方评测单位开展，可选范围较多，笔者建议先少量采购，并且在一些非核心系统上使用，总结各种使用经验，以便在出现问题时能够及时得到支持。
以上总结poc测试的8个方面的考量，总体来说，信创中间件相比于非信创中间件虽然存在差异，但是整体在可接受的范围内，需要大家一起努力共建良好的信创中间件生态。
声明：部分内容，仅供学习参考，不构成任何建议，如有异议，请联系后台
最后，别忘了点“在看”
