2B运用架构日趋繁芜：从两层到多层，从集中式到分布式
l 从两层架构到多层架构
回忆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等。
末了我创造，大多数程序员的韶光都被这些新技能、新框架霸占了，能理解和吃透客户业务的程序员越来越少。干一个项目也不是之前的几个开拓职员就能搞定，项目职责分工更为细化，做需求的、做架构的、做测试的，人多了还须要一个专业做管理的。沟通成本相较以前提高了，开拓难度越来越大，但是客户的满意度在竞争激烈的本日却越来越低。
于是，我在想，我们做的这些事情给客户的业务带来代价了吗？带来了多少代价？
l 从集中式运用到分布式运用
我做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业务运用要连续发展，就应该将非业务需求抛出业务运用的范畴，专注于打磨运用本身；而数据库想要更好地支撑运用发展，就应该承接所有的非业务需求，在原有数据库的根本上实现能力的丰富与外延。
愿上帝的物化主，凯撒的归凯撒。希望业务运用和数据库都能在这个充满变革的时期中持续提高，不断为客户创造更多代价！
