核酸检测系统的潜在性能问题猜想

先前，有西安的核算检测系统宕机，后来是上海，然后现在是成都和贵州。笔者没有参与这些系统的设计，这些系统中的性能问题是笔者根据自己在国内工作经验中看到的国内一些软件设计的弊病的猜想。目前，国内多用spring， mybatis/hibernete， mysql 等三层架构，笔者就目前的架构可能产生的问题做出4个猜想，作为目前系统为什么会做不到高性能的思考。

废话少说，不看代码，直接给出目前核算检测系统性能的四大弊端的猜想：

1. 持久层没有直接使用JDBC，目前的框架，不管是mybatis，还是hibernate总是带来性能减损的，这是笔者在Nokia LTE/MME 产品中做过的性能对标测试得出的结果。笔者做过的国内几家公司都使用框架来实现持久层的读写从而影响性能。其次，JDBC可以缓存preparedstatement，这是大家可能没有做的。执行完preparedstatement，然后来一句教科书般的close()，直接导致性能大大降低。

2. 没有使用客户端的负载均衡，猜想中目前的负载系统都是在后端做的，比如round robin，但客户端做负载均衡基本没有后端服务器的消耗，比后端做负载均衡要高效得多。

3. 没有区分有状态的组件和无状态的组件。有状态的组件比如居民的信息，核酸检验的次数，时间，就是这台服务器如果处理的居民小王的核算信息，下一个关于小王的信息还要用同一台后端服务器处理。有状态的组件要单独放在服务器中，和无状态的组件分开，无状态的服务器是可以横向扩展的，因为处理一个请求无所谓在哪台物理机上做，比如一个加法，3+4，可以在A机器上做，也可以在B机器上做，因为做完返回结果就行。有状态的组件是通过主从来实现高性能和高可靠性的，同时要用状态缓存，无状态可以通过横向扩展来实现高性能，高可靠的。

4. 新型数据库的使用，目前，我们还是一些传统数据库，比如mysql，但NewSQL 内存数据库的出现，技术已经完全成熟，我们重视不够。笔者推荐目前世界上最快的数据库VoltDB，Because Milliseconds Matter - Volt Active Data ， 简单商用机器上部署就能达到22万个事务每秒，所以高性能得来完全不付额外工作代价，当然要付点钱，但不贵。但如果现在都要用开源的数据库，可以考虑mysql的分库。3千万人口，分10个库，1个库就只有3百万个居民的信息，就核酸检测系统而言，mysql分库是容易承担的。 

关于参考架构图，笔者在后续会给出。

沈建军 于2022年9月4日 韩国统营