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業務應用要繼續發展，就應當將非業務需求拋出業務應用的范疇，專注于打磨應用本身；而數據庫想要更好地支撐應用發展，就應當承接所有的非業務需求，在原有數據庫的基礎上實現能力的豐富與外延。

愿上帝的歸上帝，凱撒的歸凱撒。希望業務應用和數據庫都能在這個充滿變化的時代中持續前進，不斷為客戶創造更多價值！