作者：一粒浮尘

1. 背景描述

从 19 到 20 年，中国发生了很多事情，世界也发生了很多事情。茶余饭后，大家谈及最多的可能就是新冠疫情后的创伤和机遇，媒体上整天有很多所谓的专家在帮大众分析新冠疫情之后的中国会面临哪些变革，企业应该如何把握机遇，大众群体应该如何把握机遇。那么作为在 IT 行业摸爬滚打的科技人员也在考虑未来的 IT 行业前景及未来的 IT 基础架构变革。很多金融行业的 IT 人士在问自己也在问别人，既然我们中国的互联网 IT 这么先进，那么我们所有的行业是不是完全有理由有可能实现同样的技术革新？我们是不是该完全国产化了？我们是不是该完全把 IT 基础架构寄托在分布式上？

2. 宏观环境

从去年到今年，伴随着宏观科技发展受制于人的大环境背景，很多企业尤其是高度依赖科技的企业都在考虑科技产业链的转型，从 IOE 脱离到云计算、大数据、 AI 技术的转型。尤其是在媒体宣传的“某某银行核心系统采用分布式架构，某某公司采用分布式架构提升了多少倍多少倍的性能”等等类似新闻的渲染之下，科技会议上、 IT 论坛上、技术探讨上出现了越来越多的“全面转型分布式，全面拥抱开源世界”等技术变革的声音；越来越多的技术人员对自己曾经自信的判断失去了信心，转而探讨大家皆呼的声音。应该说我们面临着一场前所未有的希望变革的声浪当中，科技变革情绪极其高涨。

3. 细聊 IT 基础架构

面对这个环境和现实，首先我们需要积极去参与变革，极其思考新的事物。但是在思考的同时必须客观冷静地面对现实情况并做建设性分析。为什么这么说呢？接下来让我们回到 IT 基础架构这个细分的领域内细细道来。

IT 行业高速发展了十多年，

应用上，能够支撑 WEB 互联网应用的主流中间件： Apache Tomcat 、 WebSphere 、 Weblogic ；数据库上，除了互联网行业，其他大部分行业的数据库都是： Oracle 、 DB2 、 MySQL ；存储上，除了互联网行业，大部分行业的存储还是停留在集中式存储，涉及到的大部分品牌为 Dell_EMC 、 IBM 、 HP 、 HuaWei 等；服务器上，很多年前就开始国产 X86 转型： HuaWei 、 Lenovo 、 Inspiron 。我认为关键的还是各个领域当中的软件技术。

一、关于分布式数据库

也许有人会说我们的一些国产数据库已经兴起，并且从性能上高可用上大大超越了一些商用的 Oracle 数据库，例如某某互联网公司的分布式数据库，而且还在某某银行得以印证。我在这里呢并不是想争辩什么，但是我觉得所谓一个搞 IT 很多年的老科技人来讲，当你看到媒体上或者是什么宣讲会上的所谓的高瞻远瞩，其实是应该看看技术的基本面的。

首先，有没有研究过所谓的这些分布式数据库的技术架构？如果研究的够透彻，那么你就会看清楚这些所谓的创新数据库大部分的内核还是开源的 MYSQL ，所谓的创新有几个点：

是集群的流量控制引擎上做了不少改造，让这些引擎变得相对智能，可以根据 SQL 语义去有目的进行分发，一方面可以尽量实现读写分离减轻单节点压力，一方面可以进一步提高架构的高可用。这种技术本身来讲确实是一个很好的创新，但是这种技术本身是需要和应用场景及业务特点高度集合的，是需要因地制宜的，不是一个放之四海皆准的通用架构。从根本上来讲并没有实现彻底的分布式，因为在微观上，写的操作还是集中在某一点上，只不过把读的操作分散在多个节点上，恰恰是利用了 OLTP 事物的读写 82 分布特点，这样的话可以在一定程度上解决节点资源使用过度集中的问题，也就是实例节点的热点问题。但是并没有解决表级别、行级别、字段级别的热点问题。

部分数据库操作的控制上进行了改写，比如说将关系数据库本来的一些严格提交机制或者是事务机制修改的并不那么严格，更加适合个别的特殊业务场景。这里就不一一列举了。

其次，当我们看到 “ 某某国产数据库性能在同样条件下远超商用数据库 ” 这种标题和内容的时候，当然我们内心是兴奋的开心的，因为我们是中国人。但是作为一个技术人员，本能的条件反射是要去看这种对比背后的支持逻辑是什么？性能测试的场景、条件、需求以及代价是什么。然后再去看看世界上那些先进的第三方评测机构是以什么样的方法论去做对比，然后你再去推敲这个结论究竟是为了广告效应的善意欺骗还是实实在在的技术结论。

二、关于分布式存储

很多人开始研究是否要将核心系统从运行了十几年甚至更长时间的集中式存储换下来，换成国产分布式存储。对于这个事情我觉得是一个值得庆幸的事情，我们国家的很多创新企业在这方面做了一些事情，在推进整个行业的进步。但是作为企业的科技人员同样要从技术面、业务面去客观分析。

就目前的分布式存储而言，从接口层来讲可以支持块、 S3 、 NFS 等多种接口，但是从底层的核心技术上来看来自于两个派系：一个是基于对象存储技术结合分布式框架实现的分布式对象存储技术框架；另外一个是基于 HDFS 类似的分布式文件系统实现的技术框架。之所以可以支持多种接口是因为在上层做了封装。

那么对于我们的核心系统来讲，大部分的存储场景是用于关键 OLTP 数据库的支持，也就是关系型数据库的支持。关系型数据库有一个最大的要求就是数据的一致性，为了保障这个数据一致性，利用了严格的锁机制，包括表级锁、行级锁、事务级锁等。我们之所以用了很多年集中式块存储，是因为这个块儿存储机制底层的数据组织方式就是以块儿为单位的集中式管理机制，为了配合数据库应用层的数据读写一致性要求，存储也需要在其内部实现锁的机制，从效率上和性能上来讲，这样的机制与上层应用的机制最能协同一致，以块儿为基本粒度进行锁的管理，其灵活性和影响面是最佳的。

那么接着再来看看分布式技术框架。

首先从性能上论，以分布式对象为例的话，虽然上层可以实现块存储的接口，但是从接口层到底层是需要二次映射的，也就是从块儿接口层到对象层的映射，这里面就会存在一定的性能消耗。再有， OLTP 数据库业务一定会存在大量的数据修改，一个修改完成的基本思路是 “ 寻找对象、加锁、修改、放锁 ” 。对于对象存储来讲，其组织形式是 “Key-Value” 的形式，这个数据对象的大小是不规律的，因为数据管理的粒度是对象，而不是以某个值为大小的块，那么在寻找对象的过程会涉及到二次映射寻址，加锁的过程基本是以对象为粒度的，修改再存储的粒度也是对象。这个过程与块儿存储过程消耗的性能，大家可以对比得出结论。

其次我们从整体架构平衡上论，分布式这个概念从来就是与规模效应无法分离的，如果我们的数据量够大，如果我们的存储资源池够大，那么一个两个节点的变化对于整个集群规模的影响是非常小的，因为我们的数据在大规模的集群上足够平衡、足够分散，无论是一个故障节点的退出还是扩容节点的增加，数据的平衡以及架构重新平衡的过程都不会是一个剧烈的过程。而作为运行 OLTP 的核心系统来讲，我相信在线数据的规模无论如何大，也与互联网的海量非结构化数据无法比拟，就算用了分布式存储，那么节点的规模也不会太大，这样的化就会面临这样的问题：节点失效，数据再平衡，集群架构重构等动作在整个集群上的影响效应占据的比重就会非常大，难免产生意向不到的冲突。

三、关于中间件

探讨信息产业的国产化，可能大家觉得最容易替代的就是中间件，比如很多公司用的是开源的 Apache 系列软件，国产的东方通系列软件等等。尤其是在互联网公司当中， Web 软件、消息队列、缓存管理等等很多地方都是基于开源的软件进行定制化的改造实现了适合自己环境的软件。而且这种趋势随着云计算的发展不断强化，我觉得这是一个好的态势。

就软件本身的体量来讲，与 WebSphere 、 Weblogic 这一类的商用软件相比而言，我们的软件走的的小而精的路线。我们基于一个小型的基础软件针对不同类型的场景进行改造升级，虽然不能在功能上面面俱到，但是我们可以灵活适用，针对特定的业务场景去修改源代码以及相关的配置文件等，修改中间件的行为方式，解决特殊场景下的特殊问题。多余的功能在我们的业务场景上可能根本就不需要，反而运行起来耗费不必要的资源。

就我们面临的复杂的业务场景来讲，随着互联网的发展，几乎所有传统应用系统都在寻求互联网的业务接口，那么必要会面临互联网式的业务场景特点，不得不考虑并发量的问题，不得不考虑客户响应度的问题，不得不考虑产品的高频度升级变化问题。这一系列问题最终反映在前端应用支撑软件上就是一些特殊复杂问题的解决，互联网企业为我们做了示范，通过不同软件的组合利用，通过软件行为方式的改写，通过特殊的配置方式等等解决了一个又一个的难题。虽然大多数生根传统企业的 IT 部门长期依赖成熟化的商业中间件，对软件本身的改造升级能力很少具备，但是时代的变化要求我们必须向着这个方向去发展。

4. 总结展望

聊到尾声，大家可能觉得我的观点不太合乎时宜。但是我觉得作为一个合格的技术人，评价任何事物都不能带有感情色彩，需要客观理性地分析事物的各个维度。这里并非对分布式数据库或者是分布式存储的否定，任何事物都是有两面性的，有优势的地方就有劣势的地方，分布式或者类似的一些对象正因为其优势的地方适应了互联网业务的特点，所以才在互联网的带动下有了蓬勃的发展，我们传统的企业也越来越多地与互联网业务拥抱，如果能把这些技术用在最适合的互联网业务场景下，一定会发挥其应有的优势。但是我们也不能将所有事物都盲目互联网思维，把其劣势应用在其不适合的场景下，这样反而会背离事物发展的客观规律。因地制宜，物尽其优才是最终的规律。