【IT168 评论】20年间，应用架构不断发生变化。从两层架构到多层架构，从集中式应用到分布式应用，应用架构的日趋复杂也带来了使用、开发维护方面的诸多问题……接下来，笔者将以亲身经历带你回顾20年来业务应用的变迁历史，从中找到破局之法。

　　2B应用架构日趋复杂：从两层到多层，从集中式到分布式

　　从两层架构到多层架构

　　回想20年前，笔者从事应用软件开发工作时，主要使用的是VB、PB、Delphi这类提供强大集成开发环境(IDE)的语言，主要以Client/Server架构为主。前端是应用程序，后端是数据库，主要用于开发MIS和ERP系统。客户端的工作相对简单，通过拖拉拽的方式完成界面设计实现展现和交互，通过各种事件完成前端的控制逻辑，后端则依托数据库写存储过程来完成复杂的业务处理。

　　那个时代的系统没有太大的用户量和并发量，一切以快速、低成本实现业务需求为第一目标。经常是几个开发人员组成一个项目组，在客户现场埋头苦干几个月，干完收工走人。记忆中，整个项目的大多数时间用在了与用户沟通业务现状，处理各种业务异常，开发方面相对容易简单。同时，在强大的IDE的帮助下，开发的效率极高，一个程序员承担好几个模块没问题。

　　2000年初，Browser/Server架构逐步兴起，事情逐渐变得复杂。

　　由于这种架构不再有单独的客户端程序，必须依托浏览器来实现前端交互，因此，html/CSS/JavaScript就成为了前端的主要开发语言，中间增加了服务器端处理语言，即当时诞生的asp(active server page)、php(Hypertext Preprocessor)等新技术规范和语言，后端是数据库。

　　整个系统不再是两层架构，而是演变成了三层架构。应用程序员们的精力开始从业务端向技术端转移，他们需要学习前端语言、服务端的脚本语言，并且还要实现前端和服务端的交互和通信。

　　然而，这也许还不是最困难的，直到Java开始兴盛。

　　虽然不明白Java是怎么火起来的，但是它确实兴盛起来了。我最早接触到的是Java的Servlet，通过out.print拼写HTML语句做展现输出。当时觉得一大片的字符串连接做起来实在是难以忍受，后面使用更为笨重的EJB，也感觉不太实用。直到开源界开发出了更轻量的框架来代替Java的企业级框架，从struts到Spring，从EJB到mybatis……技术栈不断更新，各种新技术被引入，如redis、memcache、kafka、activemq等。

　　最后我发现，大多数程序员的时间都被这些新技术、新框架占据了，能理解和吃透客户业务的程序员越来越少。干一个项目也不是之前的几个开发人员就能搞定，项目职责分工更为细化，做需求的、做架构的、做测试的，人多了还需要一个专业做管理的。沟通成本相较以前提高了，开发难度越来越大，但是客户的满意度在竞争激烈的今天却越来越低。

　　于是，我在想，我们做的这些事情给客户的业务带来价值了吗?带来了多少价值?

　　从集中式应用到分布式应用

　　我做ERP/MIS的年代还没出现架构师这个职位，B/S多层架构的兴起让架构师们走上了历史舞台。随着互联网应用的不断发展，应用架构也在日益变得复杂和难以理解。以SOA(面向服务架构)为代表的分布式应用引发了新一波热潮。

　　以往的集中式应用，所有的模块在一个容器中运行，整个过程可以被单一程序员掌控;而分布式应用的这项工作被分配给了多名程序员，一个调用会涉及到多个服务，容易发生问题，这类情况不在少数。于是，时而会引发问题是由谁导致的这种争端。同时，应用程序员们开始疑惑：由于分布式应用下必须考虑分布式事务的实现，怎么能在满足性能要求的同时实现一致性呢?这些工作以前是由数据库来承担的啊。

　　总的来说，以SOA为代表的分布式应用没有给业务带来明显的增值，但是却很大程度上加大了开发和维护的复杂度、难度及成本。因此，严格意义上说，SOA架构并没有大面积流行起来，继而诞生了一种新架构：微服务。

　　微服务可以看作是SOA架构的一种进化，核心思想是将系统拆解分散，通过专业化分工提升整个系统的效率。从管理角度而言，专业化分工的确是提升整体系统效率最有效的手段，但前提是系统本身相对稳定，一旦系统本身快速、剧烈变化，分工的基础就会被打破，各个独立的微服务就无法完成变更和协同。

　　而我们当前正处于一个充满不确定的时代。对企业而言，市场和业务快速变化，随之也会要求与之相匹配的IT系统快速变化。而快速变化的前提是需要一个轻量灵活、统一设计、统一管理的系统，而不能是各自独立、纵横交错的复杂体系。

　　回顾了应用开发近20年的演变，笔者一直在反思一个问题：为什么应用开发中技术所占据的分量越来越重，这些投入客户并不能有效感知。另一方面，客户能够直接感知到的业务价值没有得到明显的体现和提升。客户认为自己的投入没有转化为足够的业务价值，对软件供应商未免不满和无奈。

　　2B应用架构的复杂化带来了哪些问题?

　　1、学习和使用难度不断增大

　　20年前的开发人员只需要掌握一种集成开发环境和SQL语言就能完成系统开发，不需要学习spring、javascript、vue、bootstrap等各种技术语言和集群、负载均衡的管理和维护。开发人员更多的是专注业务本身，思考如何将业务更好地通过IT技术进行固化。

　　20年前的新人，师傅带1个月基本就能开始做简单的模块开发。现在的Java是一种工业设计语言，涉及到的技术和点太多，Java工程师至少需要1年以上的练习才能把整个模块稳定地做出来。

　　另外，架构的日趋复杂让开发人员要学习的东西越来越多，也增大了学习和使用难度。

　　2、开发和维护成本不断提升

　　在实际项目中，需求是最难控制的事情，需求变更是常有的事。有可能甲方一句话，整体系统都要面临调整，时间紧，任务重。但架构的日益复杂及技术种类的增多使变更的难度和成本不断增加;同时，分工的细化也促使沟通和协作的成本在不断提升。

　　过去可以由一个人完成的模块现在切分成了多个人，因此，在系统维护阶段一旦出现问题，问题定位和改造的难度增大。普通的售后维护人员无法定位和解决问题，需调动原有的多名资深研发人员共同定位和排查问题，发生凌晨两三点给三四个人逐一打电话，从东南西北奔向客户现场的情况也就屡见不鲜了。

　　3、技术的复杂度阻碍了业务的持续发展

　　为了实现对技术的有效掌控，公司逐步加大在技术方面的投入，花费高成本招募技术高手解决各类技术问题，在业务理解和应用方面则用一些相对初级的开发人员做业务应用开发，减少投入。

　　由此导致的问题是，业务应用与需求的匹配度逐步下降，开发过程多次反复，项目质量难以提升，结果软件企业没赚到钱，客户的满意度也不高。

　　破局之法：重构数据库和应用边界

　　业务应用的最大价值是帮助客户高效、低成本地解决业务问题，客户并不关心内在架构，应用开发商如果真的以客户为中心，就应该把精力转移到业务问题上。

　　那么，非功能性问题、性能问题、分布式事务问题由能去解决呢?20年前是应用程序+数据库解决所有问题，今天，数据库是不是也能往外迈一大步，接手应用程序面对的这些非业务问题呢?

　　设想一：数据库与缓存、消息引擎的一体化

　　目前，大量应用程序使用了redis、memcache这类开源缓存，程序员们需要投入较多的精力才能深度掌握。而使用缓存的目的主要是为了缓存数据库中的常用基础数据或查询数据，再由应用来维护这些缓存数据的状态更新。一旦应用出错，缓存数据就有可能与数据库的数据不一样，导致业务逻辑出错。

　　既然缓存如此重要，和数据库关系又相当紧密，为什么不能由数据库提供一个可被应用程序访问的缓存呢?同时由数据库自动维护数据库表对应的缓存数据的状态更新，将缓存的部署、管理和数据库的管理工具整合起来，这样就节约应用程序的大量工作了。

　　同理，消息引擎也可作为数据库的功能延展出现，既能提供给应用访问，同时管理和部署又和数据库整合到了一起，消息引擎中的消息在特定语法下就能直接转化为SQL插入数据库，以此实现通过消息引擎来访问数据库。

　　如果上述假设成立，未来的数据库就能实现从底层向上解决业务应用的非架构、性能等非业务问题，让应用程序更专注于业务本身，从而更聚焦于业务价值的创新创造。

　　人大金仓的KingbaseES V9.0产品将从这一角度出发，实现数据库能力的外延和扩展，提供一个一体化的DB+缓存+消息引擎的轻量级平台。

　　设想二：从应用的分库分表转变到分布式数据库

　　大并发、大吞吐量的应用需求增多，使得应用开始采用分库分表的方法分散并发量和数据量的压力，在业务应用中加入了相当多的非业务代码，业务应用的复杂度进一步加大。一旦遇到较复杂的业务问题时，业务应用的代码加上分库分表的代码使整个系统变得难以维护。

　　从分层的思想看，应用不应让性能代码侵入业务代码，最好是从数据层想办法，实现数据层处理能力的弹性伸缩，不去干扰业务层。传统的关系型数据库没能解决这类问题，分布式交易数据库将是一个更好的选择。

　　通过对传统关系数据库进行改造和能力提升，实现多写多读的分布式数据处理能力，自动实现数据的分库分表动作，同时对应用层保持透明，在充分兼容原有SQL的情况下保持高性能及业务代码的简洁度。

　　人大金仓即将发布的分布式交易数据库产品KSOne能够在兼容Oracle/Mysql的基础上实现数据库的自动分库分表，减少对应用开发的复杂度，提升系统的并发能力和吞吐量。

　　设想三：从Hadoop到兼容sql的轻量MPP数据库

　　大数据的兴起使Hadoop成为开源界重要的大数据存储平台。但由于开源的特性，Hadoop存在笨重、易用性较差、组件繁多、性能一般等较多局限性，效果不是很理想。

　　显然，采用列式存储技术的分布式MPP数据库更适合处理结构化的大数据，尤其是完全兼容SQL这项能力最大程度地适应了传统程序员的技术积累和习惯。MPP更轻量、更易于维护的特点也使其在商业化方面更易于规模化地应用。

　　因此，采用MPP数据库后，业务程序员可以更加集中精力在分析模型的构建上，由MPP完成基础的大数据存储和处理工作，自动实现节点的弹性伸缩，解决性能问题，发挥各自最大优势。

　　作为MPP数据库中的佼佼者，人大金仓打造的KADB和KVDB产品已经广泛应用于安防、金融风控、运营分析等大数据领域，应用效果出色。

　　未来之路：数据库+AI

　　随着AI的快速发展，应用开始要求向智能化方向发展。而应用厂商的价值应当更多地放在在行业细分领域构建应用场景，将成熟的AI技术与客户需求将结合，实现商业变现。

　　作为大数据的承载者，数据库是天然的AI基础平台。将AI算法内置到数据库中，在库内完成例如计算机视觉相关、NLP相关的数据运算。应用厂商只需要调用AI算法与以图搜图、区域碰撞等应用场景相结合即可。

　　总的来说，2B业务应用要继续发展，就应当将非业务需求抛出业务应用的范畴，专注于打磨应用本身;而数据库想要更好地支撑应用发展，就应当承接所有的非业务需求，在原有数据库的基础上实现能力的丰富与外延。

　　愿上帝的归上帝，凯撒的归凯撒。希望业务应用和数据库都能在这个充满变化的时代中持续前进，不断为客户创造更多价值!