受到互聯(lián)網(wǎng)企業(yè)的影響，這些年在企業(yè)級應用開發(fā)中，存儲過程的使用受到了一定的限制，甚至有些企業(yè)明確在IT技術(shù)應用規(guī)范中禁用存儲過程。實際上在二十多年前，使用存儲過程是Oracle數(shù)據(jù)庫優(yōu)化中的一個十分重要的技術(shù)手段，對于處理批量業(yè)務處理十分有幫助。因為當時的數(shù)據(jù)庫CPU、內(nèi)存、IO資源都相對緊張，網(wǎng)絡的帶寬和延時也存在諸多瓶頸。使用存儲過程可以將一些工作封裝在一個數(shù)據(jù)庫的內(nèi)部執(zhí)行單元中，減少前臺進程與RDBMS內(nèi)核的交互，從而獲得更高的效率?；诖?，目前還有不少銀行還在大量使用存儲過程。

二十年前，華為的一個項目組為了實現(xiàn)應用與數(shù)據(jù)庫無關(guān)，對應用進行改造的時候去掉了所有的存儲過程，上線后發(fā)現(xiàn)改造后的應用性能下降十分嚴重。我?guī)椭治龊蟀l(fā)現(xiàn)因為數(shù)據(jù)庫與應用模塊跨數(shù)據(jù)中心部署，因此SQL在網(wǎng)絡上的交互延時嚴重影響了性能。因此在當時的條件下，他們很難放棄存儲過程，為此他們最終放棄了多數(shù)據(jù)庫支持而選擇了回歸存儲過程。

這些年隨著互聯(lián)網(wǎng)企業(yè)在IT上的成功，很多企業(yè)也在學習互聯(lián)網(wǎng)架構(gòu)。大量的應用不再使用存儲過程，應用的業(yè)務邏輯更多地被從數(shù)據(jù)庫中抽取出來，放到應用系統(tǒng)中。應用對數(shù)據(jù)庫的依賴就降低了，應用在不同品種的數(shù)據(jù)庫之中的遷移也變得簡單了。同時因為業(yè)務邏輯更多地遷移到應用服務器上，數(shù)據(jù)庫服務器的資源消耗也下降了，數(shù)據(jù)庫服務器的瓶頸也得到了緩解。于是這些年應用去存儲過程在很多企業(yè)里熱門起來，存儲過程的使用也大幅下降了。

不過也有一些企業(yè)發(fā)現(xiàn)，去掉存儲過程，將業(yè)務邏輯放到應用中去之后，應用的質(zhì)量管控變得更加困難了。以前在一個研發(fā)隊伍中開發(fā)存儲過程的都是對業(yè)務邏輯理解十分深刻，數(shù)據(jù)庫功底比較好的老鳥，這些人寫出的存儲過程雖然復雜，不過質(zhì)量還是杠杠的。哪怕存在一些問題，優(yōu)化起來只要集中精力去優(yōu)化PL/SQL的代碼就可以了。而現(xiàn)在業(yè)務邏輯分散到應用中，由水平差異較大的開發(fā)人員去開發(fā)，應用的質(zhì)量變得更難控制了，優(yōu)化的難度也變大了。

實際上絕大多數(shù)傳統(tǒng)行業(yè)企業(yè)是缺乏互聯(lián)網(wǎng)基因的，互聯(lián)網(wǎng)企業(yè)與傳統(tǒng)企業(yè)最大的區(qū)別是在IT上的投入的區(qū)別?；ヂ?lián)網(wǎng)企業(yè)能把所有邏輯放到應用上，并不是互聯(lián)網(wǎng)企業(yè)的架構(gòu)有多優(yōu)秀，而是互聯(lián)網(wǎng)企業(yè)能夠在IT上投入巨資，由大量優(yōu)秀的開發(fā)人員來完成這項工作。而傳統(tǒng)行業(yè)企業(yè)的IT投入與互聯(lián)網(wǎng)企業(yè)無法相比，IT員工工資收入要低得多，IT部門人員的素質(zhì)肯定也要遠遠低于互聯(lián)網(wǎng)企業(yè)。在這種情況下，研發(fā)團隊往往是很難駕馭好互聯(lián)網(wǎng)架構(gòu)的應用的。

企業(yè)級關(guān)系型數(shù)據(jù)庫都有存儲過程這個功能，這個功能就是為了簡化應用開發(fā)難度，提高應用效率的。在應用中使用存儲過程是可以降低應用軟件開發(fā)與維護成本，提高系統(tǒng)中批量處理業(yè)務的性能的。近來企業(yè)應用中使用較少除了受到互聯(lián)網(wǎng)企業(yè)的引導之外，還有一個因素是減少對某個數(shù)據(jù)庫的依賴。其實在前些年去IOE的過程中，很多企業(yè)已經(jīng)感受到了數(shù)據(jù)庫遷移帶來的痛苦，以及被Oracle數(shù)據(jù)庫綁定后不斷上升的數(shù)據(jù)庫使用成本的困擾。

當年很多企業(yè)決定借鑒互聯(lián)網(wǎng)架構(gòu)的另外一個原因是因為很多應用開發(fā)以數(shù)據(jù)庫為核心，而數(shù)據(jù)庫在橫向擴展方面的能力不足，因此數(shù)據(jù)庫往往會成為應用系統(tǒng)中最大的瓶頸。與其擴容昂貴的小型機，還不如將部分應用負載轉(zhuǎn)移到相對便宜、比較容易橫向擴展的應用服務器上。

有些企業(yè)在應用架構(gòu)轉(zhuǎn)型中獲得了成功，不過很多企業(yè)轉(zhuǎn)型后雖然解決了數(shù)據(jù)庫服務器瓶頸的問題，但是遇到了新的挑戰(zhàn)-應用開發(fā)的成本太高了。與傳統(tǒng)的IOE架構(gòu)相比，現(xiàn)在的應用架構(gòu)中引入了太多復雜的組件，應用開發(fā)成本增大，開發(fā)周期變長，運維難度也大幅上升。有些企業(yè)甚至已經(jīng)在反思是不是每個系統(tǒng)都需要采用如此復雜的架構(gòu)。

在數(shù)據(jù)庫國產(chǎn)化替代的今天，我看到了一個十分有趣的現(xiàn)象，那就是國產(chǎn)數(shù)據(jù)庫大多數(shù)都提供了比較好的Oracle PL/SQL的兼容支持。而且大多數(shù)國產(chǎn)數(shù)據(jù)庫支持的PL/SQL語法肯定都不全面，不過因為PL/SQL中較為容易實現(xiàn)的部分都被國產(chǎn)數(shù)據(jù)庫所支持了，所以目前國產(chǎn)數(shù)據(jù)庫的PL/SQL語法反而是比較接近的。在國產(chǎn)數(shù)據(jù)庫之間遷移PL/SQL存儲過程的難度很低。使用國產(chǎn)數(shù)據(jù)庫后，如果想要換另外一個國產(chǎn)數(shù)據(jù)庫，基本上可以平替。

前幾天和一個國產(chǎn)數(shù)據(jù)庫廠商談到這方面的問題的時候，突然想到，國產(chǎn)數(shù)據(jù)庫時代，是不是可以回歸大量使用存儲過程，從而降低應用研發(fā)與應用維護的成本呢？似乎這是可行的，當年JAVA剛剛流行，替代C的時候就是如此。因為存儲過程這個大殺器的存在，讓企業(yè)使用熟悉業(yè)務邏輯與數(shù)據(jù)庫架構(gòu)的高手將核心業(yè)務邏輯封裝在存儲過程中，再安排大量技術(shù)水平一般的JAVA程序員去解決前端應用易用性的問題，從而讓信息系統(tǒng)開發(fā)的門檻一下子降低了幾個數(shù)量級。

已經(jīng)脫離開發(fā)多年了，不太清楚目前應用架構(gòu)師關(guān)注的是什么。我做應用架構(gòu)師的時候，總是在追求化繁為簡，盡可能讓一線開發(fā)人員變成工具人，而似乎現(xiàn)在的風向有些變化，應用開發(fā)已經(jīng)變得相當復雜了。而讓部分企業(yè)級應用回歸到以數(shù)據(jù)庫為核心，對于國產(chǎn)數(shù)據(jù)庫而言也是一個巨大的挑戰(zhàn)，只有國產(chǎn)數(shù)據(jù)庫真的能打了，這個愿望才能實現(xiàn)。不過對于企業(yè)級應用而言，適當回歸存儲過程的使用，可能能夠解決目前的一些問題。

今天就聊到這里吧，明天我們來分析分析，國產(chǎn)數(shù)據(jù)庫的PL/SQL兼容能力，需要在哪些地方發(fā)力，或者說用戶選型數(shù)據(jù)庫的時候從哪些角度來看存儲過程的兼容性。