想必CIO和CTO都有所感受，企業(yè)信息化建設(shè)走過了幾十年，如今正步入數(shù)字化的進(jìn)程。作為一種練內(nèi)功的方式，企業(yè)應(yīng)用架構(gòu)有助于業(yè)務(wù)與IT的融合，構(gòu)建業(yè)務(wù)與IT之間的橋梁，并提升數(shù)字化轉(zhuǎn)型所需的核心能力。
但隨著應(yīng)用架構(gòu)不斷發(fā)生變化，從兩層架構(gòu)到多層架構(gòu)，從集中式應(yīng)用到分布式應(yīng)用，應(yīng)用架構(gòu)的日趨復(fù)雜也帶來了使用、開發(fā)維護(hù)方面的諸多問題。這讓CIO不得不重新思考，“我該如何調(diào)整應(yīng)用架構(gòu)，以應(yīng)對(duì)這些復(fù)雜的問題呢？”
本文，筆者將以親身經(jīng)歷帶你回顧20年來業(yè)務(wù)應(yīng)用的變遷歷史，從中找到破局之法。
2B應(yīng)用架構(gòu)日趨復(fù)雜：
從兩層到多層，從集中式到分布式
從兩層架構(gòu)到多層架構(gòu)
回想20年前，筆者從事應(yīng)用軟件開發(fā)工作時(shí)，主要使用的是VB、PB、Delphi這類提供強(qiáng)大集成開發(fā)環(huán)境（IDE）的語(yǔ)言，主要以Client/Server架構(gòu)為主。
前端是應(yīng)用程序，后端是數(shù)據(jù)庫(kù)，主要用于開發(fā)MIS和ERP系統(tǒng)。客戶端的工作相對(duì)簡(jiǎn)單，通過拖拉拽的方式完成界面設(shè)計(jì)實(shí)現(xiàn)展現(xiàn)和交互，通過各種事件完成前端的控制邏輯，后端則依托數(shù)據(jù)庫(kù)寫存儲(chǔ)過程來完成復(fù)雜的業(yè)務(wù)處理。
那個(gè)時(shí)代的系統(tǒng)沒有太大的用戶量和并發(fā)量，一切以快速、低成本實(shí)現(xiàn)業(yè)務(wù)需求為第一目標(biāo)。經(jīng)常是幾個(gè)開發(fā)人員組成一個(gè)項(xiàng)目組，在客戶現(xiàn)場(chǎng)埋頭苦干幾個(gè)月，干完收工走人。
記憶中，整個(gè)項(xiàng)目的大多數(shù)時(shí)間用在了與用戶溝通業(yè)務(wù)現(xiàn)狀，處理各種業(yè)務(wù)異常，開發(fā)方面相對(duì)容易簡(jiǎn)單。同時(shí)，在強(qiáng)大的IDE的幫助下，開發(fā)的效率極高，一個(gè)程序員承擔(dān)好幾個(gè)模塊沒問題。
2000年初，Browser/Server架構(gòu)逐步興起，事情逐漸變得復(fù)雜。
由于這種架構(gòu)不再有單獨(dú)的客戶端程序，必須依托瀏覽器來實(shí)現(xiàn)前端交互，因此，html/CSS/JavaScript就成為了前端的主要開發(fā)語(yǔ)言，中間增加了服務(wù)器端處理語(yǔ)言，即當(dāng)時(shí)誕生的asp（active server page）、php（Hypertext Preprocessor）等新技術(shù)規(guī)范和語(yǔ)言，后端是數(shù)據(jù)庫(kù)。
整個(gè)系統(tǒng)不再是兩層架構(gòu)，而是演變成了三層架構(gòu)。
應(yīng)用程序員們的精力開始從業(yè)務(wù)端向技術(shù)端轉(zhuǎn)移，他們需要學(xué)習(xí)前端語(yǔ)言、服務(wù)端的腳本語(yǔ)言，并且還要實(shí)現(xiàn)前端和服務(wù)端的交互和通信。
然而，這也許還不是最困難的，直到Java開始興盛。雖然不明白Java是怎么火起來的，但是它確實(shí)興盛起來了。
我最早接觸到的是Java的Servlet，通過out.print拼寫HTML語(yǔ)句做展現(xiàn)輸出。
當(dāng)時(shí)覺得一大片的字符串連接做起來實(shí)在是難以忍受，后面使用更為笨重的EJB，也感覺不太實(shí)用。直到開源界開發(fā)出了更輕量的框架來代替Java的企業(yè)級(jí)框架，從struts到Spring，從EJB到mybatis……技術(shù)棧不斷更新，各種新技術(shù)被引入，如redis、memcache、kafka、activemq等。
最后我發(fā)現(xiàn)，大多數(shù)程序員的時(shí)間都被這些新技術(shù)、新框架占據(jù)了，能理解和吃透客戶業(yè)務(wù)的程序員越來越少。
干一個(gè)項(xiàng)目也不是之前的幾個(gè)開發(fā)人員就能搞定，項(xiàng)目職責(zé)分工更為細(xì)化，做需求的、做架構(gòu)的、做測(cè)試的，人多了還需要一個(gè)專業(yè)做管理的。溝通成本相較以前提高了，開發(fā)難度越來越大，但是客戶的滿意度在競(jìng)爭(zhēng)激烈的今天卻越來越低。
于是，我在想，我們做的這些事情給客戶的業(yè)務(wù)帶來價(jià)值了嗎？帶來了多少價(jià)值？
從集中式應(yīng)用到分布式應(yīng)用
我做ERP/MIS的年代還沒出現(xiàn)架構(gòu)師這個(gè)職位，B/S多層架構(gòu)的興起讓架構(gòu)師們走上了歷史舞臺(tái)。
隨著互聯(lián)網(wǎng)應(yīng)用的不斷發(fā)展，應(yīng)用架構(gòu)也在日益變得復(fù)雜和難以理解。以SOA（面向服務(wù)架構(gòu)）為代表的分布式應(yīng)用引發(fā)了新一波熱潮。
以往的集中式應(yīng)用，所有的模塊在一個(gè)容器中運(yùn)行，整個(gè)過程可以被單一程序員掌控；而分布式應(yīng)用的這項(xiàng)工作被分配給了多名程序員，一個(gè)調(diào)用會(huì)涉及到多個(gè)服務(wù)，容易發(fā)生問題，這類情況不在少數(shù)。于是，時(shí)而會(huì)引發(fā)問題是由誰(shuí)導(dǎo)致的這種爭(zhēng)端。
同時(shí)，應(yīng)用程序員們開始疑惑：由于分布式應(yīng)用下必須考慮分布式事務(wù)的實(shí)現(xiàn)，怎么能在滿足性能要求的同時(shí)實(shí)現(xiàn)一致性呢？這些工作以前是由數(shù)據(jù)庫(kù)來承擔(dān)的啊。
總的來說，以SOA為代表的分布式應(yīng)用沒有給業(yè)務(wù)帶來明顯的增值，但是卻很大程度上加大了開發(fā)和維護(hù)的復(fù)雜度、難度及成本。
因此，嚴(yán)格意義上說，SOA架構(gòu)并沒有大面積流行起來，繼而誕生了一種新架構(gòu)：微服務(wù)。
微服務(wù)可以看作是SOA架構(gòu)的一種進(jìn)化，核心思想是將系統(tǒng)拆解分散，通過專業(yè)化分工提升整個(gè)系統(tǒng)的效率。
從管理角度而言，專業(yè)化分工的確是提升整體系統(tǒng)效率最有效的手段，但前提是系統(tǒng)本身相對(duì)穩(wěn)定，一旦系統(tǒng)本身快速、劇烈變化，分工的基礎(chǔ)就會(huì)被打破，各個(gè)獨(dú)立的微服務(wù)就無法完成變更和協(xié)同。
而我們當(dāng)前正處于一個(gè)充滿不確定的時(shí)代。對(duì)企業(yè)而言，市場(chǎng)和業(yè)務(wù)快速變化，隨之也會(huì)要求與之相匹配的IT系統(tǒng)快速變化。而快速變化的前提是需要一個(gè)輕量靈活、統(tǒng)一設(shè)計(jì)、統(tǒng)一管理的系統(tǒng)，而不能是各自獨(dú)立、縱橫交錯(cuò)的復(fù)雜體系。
回顧了應(yīng)用開發(fā)近20年的演變，筆者一直在反思一個(gè)問題：為什么應(yīng)用開發(fā)中技術(shù)所占據(jù)的分量越來越重，這些投入客戶并不能有效感知。另一方面，客戶能夠直接感知到的業(yè)務(wù)價(jià)值沒有得到明顯的體現(xiàn)和提升。客戶認(rèn)為自己的投入沒有轉(zhuǎn)化為足夠的業(yè)務(wù)價(jià)值，對(duì)軟件供應(yīng)商未免不滿和無奈。
2B應(yīng)用架構(gòu)的復(fù)雜化帶來哪些問題？
學(xué)習(xí)和使用難度不斷增大
20年前的開發(fā)人員只需要掌握一種集成開發(fā)環(huán)境和SQL語(yǔ)言就能完成系統(tǒng)開發(fā)，不需要學(xué)習(xí)spring、javascript、vue、bootstrap等各種技術(shù)語(yǔ)言和集群、負(fù)載均衡的管理和維護(hù)。開發(fā)人員更多的是專注業(yè)務(wù)本身，思考如何將業(yè)務(wù)更好地通過IT技術(shù)進(jìn)行固化。
20年前的新人，師傅帶1個(gè)月基本就能開始做簡(jiǎn)單的模塊開發(fā)?，F(xiàn)在的Java是一種工業(yè)設(shè)計(jì)語(yǔ)言，涉及到的技術(shù)和點(diǎn)太多，Java工程師至少需要1年以上的練習(xí)才能把整個(gè)模塊穩(wěn)定地做出來。
另外，架構(gòu)的日趨復(fù)雜讓開發(fā)人員要學(xué)習(xí)的東西越來越多，也增大了學(xué)習(xí)和使用難度。
開發(fā)和維護(hù)成本不斷提升
在實(shí)際項(xiàng)目中，需求是最難控制的事情，需求變更是常有的事。有可能甲方一句話，整體系統(tǒng)都要面臨調(diào)整，時(shí)間緊，任務(wù)重。
但架構(gòu)的日益復(fù)雜及技術(shù)種類的增多使變更的難度和成本不斷增加；同時(shí)，分工的細(xì)化也促使溝通和協(xié)作的成本在不斷提升。
過去可以由一個(gè)人完成的模塊現(xiàn)在切分成了多個(gè)人，因此，在系統(tǒng)維護(hù)階段一旦出現(xiàn)問題，問題定位和改造的難度增大。
普通的售后維護(hù)人員無法定位和解決問題，需調(diào)動(dòng)原有的多名資深研發(fā)人員共同定位和排查問題，發(fā)生凌晨?jī)扇c(diǎn)給三四個(gè)人逐一打電話，從東南西北奔向客戶現(xiàn)場(chǎng)的情況也就屢見不鮮了。
高度總結(jié)企業(yè)應(yīng)用架構(gòu)變遷，三分鐘破局未來邊界之道
技術(shù)的復(fù)雜度阻礙了業(yè)務(wù)的持續(xù)發(fā)展
為了實(shí)現(xiàn)對(duì)技術(shù)的有效掌控，公司逐步加大在技術(shù)方面的投入，花費(fèi)高成本招募技術(shù)高手解決各類技術(shù)問題，在業(yè)務(wù)理解和應(yīng)用方面則用一些相對(duì)初級(jí)的開發(fā)人員做業(yè)務(wù)應(yīng)用開發(fā)，減少投入。
由此導(dǎo)致的問題是，業(yè)務(wù)應(yīng)用與需求的匹配度逐步下降，開發(fā)過程多次反復(fù)，項(xiàng)目質(zhì)量難以提升，結(jié)果軟件企業(yè)沒賺到錢，客戶的滿意度也不高。
破局之法：重構(gòu)數(shù)據(jù)庫(kù)和應(yīng)用邊界
業(yè)務(wù)應(yīng)用的最大價(jià)值是幫助客戶高效、低成本地解決業(yè)務(wù)問題，客戶并不關(guān)心內(nèi)在架構(gòu)，應(yīng)用開發(fā)商如果真的以客戶為中心，就應(yīng)該把精力轉(zhuǎn)移到業(yè)務(wù)問題上。
那么，非功能性問題、性能問題、分布式事務(wù)問題由誰(shuí)去解決呢？20年前是應(yīng)用程序+數(shù)據(jù)庫(kù)解決所有問題，今天，數(shù)據(jù)庫(kù)是不是也能往外邁一大步，接手應(yīng)用程序面對(duì)的這些非業(yè)務(wù)問題呢？
設(shè)想一：數(shù)據(jù)庫(kù)與緩存、消息引擎的一體化
目前，大量應(yīng)用程序使用了redis、memcache這類開源緩存，程序員們需要投入較多的精力才能深度掌握。而使用緩存的目的主要是為了緩存數(shù)據(jù)庫(kù)中的常用基礎(chǔ)數(shù)據(jù)或查詢數(shù)據(jù)，再由應(yīng)用來維護(hù)這些緩存數(shù)據(jù)的狀態(tài)更新。一旦應(yīng)用出錯(cuò)，緩存數(shù)據(jù)就有可能與數(shù)據(jù)庫(kù)的數(shù)據(jù)不一樣，導(dǎo)致業(yè)務(wù)邏輯出錯(cuò)。
既然緩存如此重要，和數(shù)據(jù)庫(kù)關(guān)系又相當(dāng)緊密，為什么不能由數(shù)據(jù)庫(kù)提供一個(gè)可被應(yīng)用程序訪問的緩存呢？同時(shí)由數(shù)據(jù)庫(kù)自動(dòng)維護(hù)數(shù)據(jù)表對(duì)應(yīng)的緩存數(shù)據(jù)的狀態(tài)更新，將緩存的部署、管理和數(shù)據(jù)庫(kù)的管理工具整合起來，這樣就節(jié)約應(yīng)用程序的大量工作了。
同理，消息引擎也可作為數(shù)據(jù)庫(kù)的功能延展出現(xiàn)，既能提供給應(yīng)用訪問，同時(shí)管理和部署又和數(shù)據(jù)庫(kù)整合到了一起，消息引擎中的消息在特定語(yǔ)法下就能直接轉(zhuǎn)化為SQL插入數(shù)據(jù)庫(kù)，以此實(shí)現(xiàn)通過消息引擎來訪問數(shù)據(jù)庫(kù)。
如果上述假設(shè)成立，未來的數(shù)據(jù)庫(kù)就能實(shí)現(xiàn)從底層向上解決業(yè)務(wù)應(yīng)用的非架構(gòu)、性能等非業(yè)務(wù)問題，讓應(yīng)用程序更專注于業(yè)務(wù)本身，從而更聚焦于業(yè)務(wù)價(jià)值的創(chuàng)新創(chuàng)造。
人大金倉(cāng)的KingbaseES V9.0產(chǎn)品將從這一角度出發(fā)，實(shí)現(xiàn)數(shù)據(jù)庫(kù)能力的外延和擴(kuò)展，提供一個(gè)一體化的DB+緩存+消息引擎的輕量級(jí)平臺(tái)。
設(shè)想二：從應(yīng)用的分庫(kù)分表轉(zhuǎn)變到分布式數(shù)據(jù)庫(kù)
大并發(fā)、大吞吐量的應(yīng)用需求增多，使得應(yīng)用開始采用分庫(kù)分表的方法分散并發(fā)量和數(shù)據(jù)量的壓力，在業(yè)務(wù)應(yīng)用中加入了相當(dāng)多的非業(yè)務(wù)代碼，業(yè)務(wù)應(yīng)用的復(fù)雜度進(jìn)一步加大。一旦遇到較復(fù)雜的業(yè)務(wù)問題時(shí)，業(yè)務(wù)應(yīng)用的代碼加上分庫(kù)分表的代碼使整個(gè)系統(tǒng)變得難以維護(hù)。
從分層的思想看，應(yīng)用不應(yīng)讓性能代碼侵入業(yè)務(wù)代碼，最好是從數(shù)據(jù)層想辦法，實(shí)現(xiàn)數(shù)據(jù)層處理能力的彈性伸縮，不去干擾業(yè)務(wù)層。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)沒能解決這類問題，分布式交易數(shù)據(jù)庫(kù)將是一個(gè)更好的選擇。
通過對(duì)傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)進(jìn)行改造和能力提升，實(shí)現(xiàn)多寫多讀的分布式數(shù)據(jù)處理能力，自動(dòng)實(shí)現(xiàn)數(shù)據(jù)的分庫(kù)分表動(dòng)作，同時(shí)對(duì)應(yīng)用層保持透明，在充分兼容原有SQL的情況下保持高性能及業(yè)務(wù)代碼的簡(jiǎn)潔度。
人大金倉(cāng)即將發(fā)布的分布式交易數(shù)據(jù)庫(kù)產(chǎn)品KSOne能在兼容Oracle/Mysql的基礎(chǔ)上實(shí)現(xiàn)數(shù)據(jù)庫(kù)的自動(dòng)分庫(kù)分表，減少對(duì)應(yīng)用開發(fā)的復(fù)雜度，提升系統(tǒng)的并發(fā)能力和吞吐量。
設(shè)想三：從Hadoop到兼容sql的輕量MPP數(shù)據(jù)庫(kù)
大數(shù)據(jù)的興起使Hadoop成為開源界重要的大數(shù)據(jù)存儲(chǔ)平臺(tái)。但由于開源的特性，Hadoop存在笨重、易用性較差、組件繁多、性能一般等較多局限性，效果不是很理想。
顯然，采用列式存儲(chǔ)技術(shù)的分布式MPP數(shù)據(jù)庫(kù)更適合處理結(jié)構(gòu)化的大數(shù)據(jù)，尤其是完全兼容SQL這項(xiàng)能力最大程度地適應(yīng)了傳統(tǒng)程序員的技術(shù)積累和習(xí)慣。MPP更輕量、更易于維護(hù)的特點(diǎn)也使其在商業(yè)化方面更易于規(guī)?；貞?yīng)用。
因此，采用MPP數(shù)據(jù)庫(kù)后，業(yè)務(wù)程序員可以更加集中精力在分析模型的構(gòu)建上，由MPP完成基礎(chǔ)的大數(shù)據(jù)存儲(chǔ)和處理工作，自動(dòng)實(shí)現(xiàn)節(jié)點(diǎn)的彈性伸縮，解決性能問題，發(fā)揮各自最大優(yōu)勢(shì)。
作為MPP數(shù)據(jù)庫(kù)中的佼佼者,人大金倉(cāng)打造的KADB和KVDB產(chǎn)品已廣泛應(yīng)用于安防、金融風(fēng)控、運(yùn)營(yíng)分析等大數(shù)據(jù)領(lǐng)域，應(yīng)用效果出色。
未來之路：數(shù)據(jù)庫(kù)+AI
隨著AI的快速發(fā)展，應(yīng)用開始要求向智能化方向發(fā)展。而應(yīng)用廠商的價(jià)值應(yīng)當(dāng)更多地放在在行業(yè)細(xì)分領(lǐng)域構(gòu)建應(yīng)用場(chǎng)景，將成熟的AI技術(shù)與客戶需求將結(jié)合，實(shí)現(xiàn)商業(yè)變現(xiàn)。
作為大數(shù)據(jù)的承載者，數(shù)據(jù)庫(kù)是天然的AI基礎(chǔ)平臺(tái)。將AI算法內(nèi)置到數(shù)據(jù)庫(kù)中，在庫(kù)內(nèi)完成例如計(jì)算機(jī)視覺相關(guān)、NLP相關(guān)的數(shù)據(jù)運(yùn)算。應(yīng)用廠商只需要調(diào)用AI算法與以圖搜圖、區(qū)域碰撞等應(yīng)用場(chǎng)景相結(jié)合即可。
數(shù)據(jù)庫(kù)：豐富能力與外延
總的來說，2B業(yè)務(wù)應(yīng)用要繼續(xù)發(fā)展，就應(yīng)當(dāng)將非業(yè)務(wù)需求拋出業(yè)務(wù)應(yīng)用的范疇，專注于打磨應(yīng)用本身；而數(shù)據(jù)庫(kù)想要更好地支撐應(yīng)用發(fā)展，就應(yīng)當(dāng)承接所有的非業(yè)務(wù)需求，在原有數(shù)據(jù)庫(kù)的基礎(chǔ)上實(shí)現(xiàn)能力的豐富與外延。
