?前陣子和一家大型企業(yè)討論數(shù)據(jù)庫國產化的方案，這個工作實際上是去O，在技術層面上并不難，弄清楚企業(yè)數(shù)據(jù)庫應用現(xiàn)狀，確定幾條遷移路線，剩下就把各個系統(tǒng)往這幾條路線里套就可以了。

我們討論確定的總體思路也不復雜，對于新建中小型系統(tǒng)，原則上使用云上RDS；對于存量大型核心系統(tǒng)，選擇裸金屬部署的國產數(shù)據(jù)庫或者云原生分布式數(shù)據(jù)庫，經過系統(tǒng)改造后完成替代；對于新建大型系統(tǒng)，采用裸金屬部署的國產關系型數(shù)據(jù)庫或者云原生分布式數(shù)據(jù)庫；對于存量的原來使用Oracle數(shù)據(jù)庫的中小型系統(tǒng)，已經計劃上云改造遷移的，盡可能使用云上RDS，暫無升級改造需求的，挑選一款與Oracle兼容性較好的國產數(shù)據(jù)庫做遷移。

按照這個方案把上千套系統(tǒng)歸類到這幾條里雖然工作量不小，不過也很快完成了。本來以為方案讓領導認可了，就可以開展選型工作，然后就可以進行試點了。沒想到領導看到這個方案后覺得這個方案考慮的太復雜了，他覺得，反正所有系統(tǒng)都要上云，那么為什么不全部使用免費的云上RDS，還花錢去買什么國產數(shù)據(jù)庫呢？他覺得云平臺比傳統(tǒng)架構強太多了，以前沒上云用Oracle的時候還總是今天這個系統(tǒng)出問題，明天那個系統(tǒng)出問題。自從上云后，他還沒聽說哪個云上系統(tǒng)出過問題呢。

經過領導這一番教導，前陣子花了一個多月搞的方案算是白搞了。雖然不太甘心，但是也覺得很難去說服領導。會后企業(yè)中一個搞技術的朋友和我聊這件事，他說目前上云的系統(tǒng)雖然有好幾百套，但是都是一些很小的非關鍵系統(tǒng)，哪怕真的出了事，領導也不會知道。而企業(yè)的核心系統(tǒng)目前還都沒有上云，都在Oracle數(shù)據(jù)庫里跑著呢，那些系統(tǒng)出點小問題，都會反饋到領導那里去，所以領導就自然而然的認為，系統(tǒng)上云了就萬事大吉了。

另外一方面，以前稍微大一點的系統(tǒng)搬遷上云，改用RDS的時候，都是做了拆庫分表工作的，在研發(fā)上大大投入了一把，把數(shù)據(jù)庫都切分為多個小型數(shù)據(jù)庫了，這么一切分，數(shù)據(jù)庫變小后，哪怕缺個索引啥的，也都不怕了，確實是上云用了RDS后反而問題比以前少了很多。只不過采用這種方式研發(fā)投入比較大，很多沒錢的二級企業(yè)搞不起，像他們這種大型的比較有錢的二級企業(yè)，目前的整個應用架構都改成這樣了，自己下屬的IT公司的研發(fā)目前也比較適應這樣的應用模式了。

領導的思路也不是完全不可行，也不是完全不正確。如果所有的應用系統(tǒng)都能夠比較徹底的完成上云適配改造，那么把所有的Oracle上的應用系統(tǒng)遷移到云上RDS也并不是不可行。這種方式還可以省去購買國產數(shù)據(jù)庫許可證的費用（事實上這個費用是省不下來的，因為企業(yè)購買的商用版云平臺，RDS節(jié)點的授權費用基本上與國產數(shù)據(jù)庫許可證授權相當，只是領導認為這是云平臺投資，不是數(shù)據(jù)庫許可證投資而已），因此在領導眼里，數(shù)據(jù)庫國產化改造并不需要花那么多心思去區(qū)分各種技術路線。幾個核心系統(tǒng)單獨考慮，其他的系統(tǒng)全部用RDS替代就好了。因為在領導眼里，Oracle和RDS雖然有區(qū)別，但是都只是數(shù)據(jù)庫而已，因此數(shù)據(jù)庫國產化替代不如化繁為簡。

不過在技術人員眼里，數(shù)據(jù)庫的差異就大了。應用從Oracle遷移到不同的數(shù)據(jù)庫，應用改造，性能優(yōu)化、高可用運行、日常運維，都有極大的差別。而作為企業(yè)IT部門的高級管理人員，領導并不一定了解這些不同，甚至無法理解這里存在什么不同。再加上領導身邊也經常有些半懂不懂的人忽悠忽悠，出現(xiàn)類似的情況就很難說了。

在和很多企業(yè)探討數(shù)據(jù)庫國產化的方案的時候，我經常提出一個總體成本的問題。實際上目前大多數(shù)領導都只關注購買數(shù)據(jù)庫許可證的費用，并不會去考慮總體的成本。我曾經和一個企業(yè)的IT主管討論過數(shù)據(jù)庫國產化改造的成本問題，最后發(fā)現(xiàn)實際上最難解決的是存量系統(tǒng)的問題。一個大型企業(yè)，經過近三十年的信息化建設，至少有上千套大大小小的系統(tǒng)使用Oracle數(shù)據(jù)庫，這些系統(tǒng)中至少一半系統(tǒng)使用了大量的PL/SQL存儲過程。如果不選擇一款與Oracle高度兼容的數(shù)據(jù)庫系統(tǒng)作為遷移對象，那么整個遷移改造的成本是一個天文數(shù)字，這個數(shù)字遠比已經讓各位領導頭痛的國產數(shù)據(jù)庫許可證采購費用大的多。

除了遷移之外，選擇不同的數(shù)據(jù)庫，運維的費用也是需要考慮的。國產數(shù)據(jù)庫哪怕在一些接口上與Oracle做的有多像，實際上內部核心與Oracle的差異還是巨大的。在運維上，以前我們積累的經驗大多數(shù)不可用了。因此在運維、原廠服務、第三方支撐等方面都會存在巨大的差異。企業(yè)的IT主管在考慮數(shù)據(jù)庫國產化改造的時候，往往會忽略這方面的費用投資，這將導致國產化遷移大規(guī)模開始的時候，一定會遇到很多運維方面的問題，導致應用系統(tǒng)不斷出問題，IT部門疲于奔命。

與數(shù)據(jù)庫國產化工作開展有關的技術路線選擇、產品選型、費用與預算、人才培養(yǎng)、技術儲備等相關的工作，無論哪一個環(huán)節(jié)沒有做好，都會給數(shù)據(jù)庫國產化工作帶來極大的困難。但是如果這些無論哪一項都不是基層技術人員能夠決定的。如果不讓領導真正明白這些關鍵，那么這項工作想做好都不容易。

另外每個企業(yè)的實際情況不同，技術能力、投資策略、改革目標等的不同都會導致最后的策略在領導眼中與技術人員眼中存在巨大的差異。就像我開始說的這個例子，如果企業(yè)下決心要將所有的系統(tǒng)都做云化改造，也有大量的資金可以用于應用改造，那么領導的方案也并不是無法實現(xiàn)的，只是要花更多的時間，花更多的錢而已。而如果領導選擇這個技術路線是想省錢，那么這個方案就很危險了。我們在討論數(shù)據(jù)庫國產化技術路線的時候，是不是也要想辦法先讓領導搞清楚數(shù)據(jù)庫是怎么一回事？領導真的懂了，再結合企業(yè)的IT發(fā)展路線去做決定，可能會比基層技術人員只是從技術層面去考慮問題更全面一些。?