信创产品从选型到投入生产，各个环节都需要经过严格的测试和实践，技术社群的这篇文章《信创中间件落地的9个实践经验》给我们讲解了一些和信创中间件产品落地相关的实践经验，值得了解学习。
信创相关的历史文章，
背景
目前面向企业市场的信创中间件品牌众多，在POC阶段应该如何确认需要选择哪些品牌进行测试，缩小POC的范围？在笔者看来建议从以下几个方面进行参考。
（1）市场占有率。市场占有率高的产品未必是最好的产品，但是至少说明通过市场的检验，用户的认可度较高，同时占有率高的产品遇到的问题也相对多些，产品优化迭代更加高效；
（2）技术栈类型。根据实践调研，目前市面上主流的一些中间件厂商，其产品的技术栈是有相似的也有完全不同的，那么在确认POC范围的时候建议兼顾多种技术栈类型的中间件进行测试；
（3）功能性需求。根据实践经验，由于信创中间件的推广与使用也就是近几年开始的，其功能相比于非信创中间件而言还是存在一些缺失。目前常用的中间件涉及java容器、web负载、缓存、消息队列、数据同步等，种类较多。因此，在进行功能性验证的时候，建议针对不同的信创中间件参考对应的非信创中间件形成常用的功能性需求清单，在测试阶段逐项进行打分测评。例如可以从以下几个方面进行：缓存中间件的清理策略可选性；中间件的并发连接数/吞吐量/响应时间；中间件与现有开发框架的兼容性；数据同步中间件在同步数据时可选的数据校验方式较少或者不支持等；消息中间件存在消息丢失的情况等；
（4）非功能性需求。根据实践经验，信创中间件在非功能性需求满足上也存在不少问题，建议梳理非功能性需求清单进行测试验证，可以从以下几个方面进行：中间件的安全与认证；中间件的安装流程与启动停止是否可自动化；中间件的日志是否会自动轮转；中间件与公司现有的平台能否集成；中间件是否具备监控能力等；中间件启动后占用的资源情况等；
（5）厂商响应情况。一般而言，在交流沟通阶段都多多少少存在一些问题，这些问题也会反馈给相应的厂商，有些厂商在接到反馈的问题后会及时进行反馈，有些厂商对反馈的问题响应较差，这也可以从一定维度反映出厂商对本次交流客户的重视程度。
应用程序在进行信创中间件适配成本评估建议从以下几个方面进行参考。
（1）应用程序包与配置分离的配置方式是否简明清晰。目前应用程序的部署一般都是采用应用程序包与配置分离的方式或者使用配置中心的方式来管理配置，并且一般都会与自动化流水线绑定，符合原先的管理要求和标准的配置分离方式在降低开发人员适配成本的同时也可以尽可能复用原先的自动化流水线提升应用部署效率；
（2）部署说明文档是否清晰。根据实践经验，有些信创中间件产品在部署文档描述方面十分清晰，同时会将常见的一些问题与解决方案进行说明，便于开发人员快速完成部署，并且能够基于清晰的说明文档进行参数的设置与调优，有些部署文档逻辑性较差，重点不突出，属于功能点的罗列，开发人员阅读和使用成本较高；
信创中间件在高可用方面要分两类产品架构形态，一类是基于分布式架构的信创中间件，另外一类是基于传统双节点架构的主备或者双活形态。
第一类是基于分布式架构的信创中间件，其高可用实现主要是基于分布式的Paxos、Raft等协议实现。Paxos协议是用于分布式系统中实现一致性的协议，其主要目的是保证系统在出现故障或网络分区的情况下仍能保持数据的一致性，该协议主要是通过多数派决策和日志复制实现分布式系统的高可用。Raft协议通过选主机制、日志复制、心跳机制和集群成员变更等技术手段来保证分布式系统在故障和网络分区的情况下依然能够保持数据的一致性和高可用性。结合分布式架构中间件的高可用原理，设计如下测试验证场景，以三节点的分布式中间件高可用为例，（1）停止一个节点上的任意一个服务进程；（2）停止一个节点上的所有进程；（3）在一个节点上重复启动服务进程；（4）停止master节点；（5）停止证书所在节点。
根据笔者经验，在以上4个场景中，（1）和（4）是企业基本都会测试的场景，（2）、（3）和（5）是比较容易被忽略的测试场景，但实际上这三个场景是非常重要的，有的分布式信创中间件高可用只支持单守护进程异常时服务的高可用，这种情况在（2）场景中就可以测试出来；有的分布式信创中间件没有处理好进程重复加载的情况，这种情况在（3）场景中就可以测试出来；信创中间件和非信创中间件一个重大的区别是需要配置证书，因此就需要测试停止证书所在节点与停止非证书所在节点对高可用的不同影响，这种情况在（5）场景中就可以测试出来，如下表：
根据笔者的测试，目前信创中间件绝大多数都提供了控制台的能力。控制台的优点是：
（1）易用性。中间件控制台提供了一个直观的图形化界面，使得用户可以轻松地管理和监控中间件组件，而无需具备深厚的技术背景；
（2）集中管理。中间件控制台可以集中管理企业的多个中间件实例，方便用户统一进行配置、监控和故障排查；
（3）实时监控。中间件控制台可以实时展示系统的运行状况，包括性能指标、资源使用情况。
但是使用控制台也会带来一些缺点：
（1）性能开销。控制台在运行过程中一般需要额外消耗主机资源，带来性能方面的开销。
（2）安全问题。控制台一般也是由java程序编写，这就有可能会引入一些java程序或者依赖框架带来的安全问题，处理由于控制台带来的安全问题也是对人力资源的一笔不小的开销。
（3）不利于深入了解中间件。控制台通过封装的方式将一些配置和功能以更加友好的方式展示出来，但是与此同时就是不便于开发和运维人员了解中间件运行底层使用的配置文件和相关脚本，一方面不理解开发和运维人员的深度使用和运维；另一方面在遇到故障需要处理时也会降低问题的处理效率。
有些类型的信创中间件在市面上可选的范围较少，可能只有2家左右，并且价格高、性能差。针对这种类型的信创中间件，笔者的建议是如果不是必须进行适配改造，可以先暂缓，如果这种类型的信创中间件确实需求较大，那么市场上大概率出会出现更多的同类产品供选择。如果确实是需要进行适配改造，建议先少量采购，并且在一些非核心系统上使用，总结各种使用经验，企业也需要与厂商的技术支持明确服务SLA，以便在出现问题时能够及时得到支持。
以上这些是选型、测试、使用和运维信创中间件时的一些实践经验和注意事项，总体来说，信创中间件相比于非信创中间件是存在一些问题，但是整体在可接受的范围内，需要大家一起努力共建良好的信创中间件生态。
