在前面一篇談數(shù)字化轉(zhuǎn)型的趨勢文章中，我曾經(jīng)談到過當(dāng)前企業(yè)數(shù)字化轉(zhuǎn)型，特別是大型集團性企業(yè)，有一定IT建設(shè)技術(shù)積累的企業(yè)，在數(shù)字化轉(zhuǎn)型和IT平臺和應(yīng)用構(gòu)建過程中，有一個關(guān)鍵轉(zhuǎn)變點就是自主可控。
很多大集團企業(yè)當(dāng)前主流趨勢都變成了自建IT團隊，進行相應(yīng)的IT系統(tǒng)開發(fā)和后續(xù)運維，而不是類似傳統(tǒng)模式下去選擇商業(yè)套件產(chǎn)品。對于ERP套裝軟件，短期要做到自主研發(fā)不現(xiàn)實，但是除了ERP軟件，大部分上層應(yīng)用軟件企業(yè)已經(jīng)具備自主研發(fā)能力。
也就是ERP應(yīng)用下沉為企業(yè)的后臺能力，而基于ERP上層的各類應(yīng)用變成了前臺，同時由企業(yè)IT團隊自己開發(fā)，并自己進行后續(xù)實施和運維管控。
自己組建團隊從頭開發(fā)內(nèi)部應(yīng)用，看上去并不省錢，前期投入成本往往比構(gòu)建成熟的商業(yè)套件花費更大。但是帶來兩個關(guān)鍵好處，其一就是敏捷響應(yīng)業(yè)務(wù)需求的能力；其二是真正做到自主可控，合作IT支撐能力掌控在自己手上，而不是被開發(fā)商綁架。
所以今天準(zhǔn)備再來討論下數(shù)字化轉(zhuǎn)型過程中IT建設(shè)自主可控的話題。
自主可控本身是一個大命題，當(dāng)前談的開源，國產(chǎn)替代，鯤鵬云生態(tài)，信創(chuàng)，核高基，鴻蒙等都可以劃入到自主可控的范疇。今天談的自主可控則重點談IT應(yīng)用建設(shè)中的軟硬件方面的自主可控。
從早期的去IOE談起
如果回到14,15年左右，當(dāng)時談得最多的不是自主可控，而是由互聯(lián)網(wǎng)發(fā)起逐步也延伸到B端企業(yè)信息化建設(shè)的去IOE。去IOE簡單來說就是要去掉昂貴的IBM小型機，Oracle數(shù)據(jù)庫，EMC的集中化存儲，而采用相應(yīng)的X86服務(wù)器，開源中間件進行替代。
大家要注意到去IOE當(dāng)前本質(zhì)已經(jīng)是變化為解決數(shù)據(jù)庫層面的問題，對于應(yīng)用服務(wù)器和中間件，采用X86服務(wù)器和負(fù)載均衡，集群技術(shù)本身已經(jīng)不存在太大的問題。包括其可靠性，可擴展性和性能等。當(dāng)前我們看到的很多應(yīng)用本身也是應(yīng)用服務(wù)器層基本全部X86+虛擬化，而對于數(shù)據(jù)庫往往還在使用小型機和集中存儲。
現(xiàn)在的高性能的X86服務(wù)器性能已經(jīng)趕上了3，4年前的中端小型機性能。比如現(xiàn)在的6到8C，8核高配的X86服務(wù)器性能能夠達到80-100萬TPMC，而3年前的中端小型機性能也就60萬TPMC的樣子。對于小型機的替代大家最關(guān)心的問題仍然是高可用性，小型機基本可以達到5個9的高可用性，而現(xiàn)在隨著類似至強7500等X86服務(wù)器引入了大量在小型機中才使用到的RAS技術(shù)，基本達到4個9是沒有太大問題的。
還有就是小型機的縱向擴展能力相當(dāng)強，比如CPU可以最多擴展到24個，而對于X86服務(wù)器則是希望通過橫向擴展來應(yīng)對小型機的縱向擴展能力。而橫向擴展自然帶來的一個問題就是分布式的問題。
對于數(shù)據(jù)庫層面，拿MySQL數(shù)據(jù)庫來和Oracle數(shù)據(jù)庫做一個比較，當(dāng)前第三方的評測是在相同的硬件配置條件下兩個數(shù)據(jù)庫的性能和Benchmark數(shù)據(jù)庫相當(dāng)。而實際上對于數(shù)據(jù)庫層面我們更加關(guān)心的還是在海量數(shù)據(jù)下的復(fù)雜事務(wù)處理能力。如果對于存儲大表數(shù)據(jù)都在千萬行級別一下，可以說兩個數(shù)據(jù)庫可能不會出現(xiàn)太明顯的差距。而如果對于大于千萬或上億數(shù)據(jù)的海量數(shù)據(jù)OLTP處理上，Oracle估計還是具備有明顯的優(yōu)勢。而對于這一個問題的解決，根據(jù)互聯(lián)網(wǎng)企業(yè)的經(jīng)驗，仍然是通過數(shù)據(jù)庫的水平拆分和垂直拆分來解決這個問題。
類似EMC提供的集中存儲是另外一個重要的話題，可以看到在使用集中存儲的時候，我們很容易去實現(xiàn)類似Oracle的RAC集群，同時本身集中SAN,NAS存儲也具備更高的存儲高可用性和高可靠性。類似互聯(lián)網(wǎng)企業(yè)淘寶也曾經(jīng)談到過，在采用廉價的本地磁盤存儲后，由于大量的IO磁盤讀寫也經(jīng)常出現(xiàn)硬盤掛掉的情況。雖然這些可以通過RAID技術(shù)來避免單獨故障，但是對于存儲的高可靠性確實本地存儲趕不上集中存儲。
在云數(shù)據(jù)中心建設(shè)中，你會看到采用類似Ceph來實現(xiàn)一個分布式的共享存儲，或者采用NFS來提供共享存儲，都是一種對傳統(tǒng)EMC存儲的替代方案。但是不得不說，這些替代方案在性能和穩(wěn)定性上比FC SAN實現(xiàn)還是有較大差距。
由于在去小型機，Oracle數(shù)據(jù)庫和集中存儲情況下，將直接轉(zhuǎn)換為數(shù)據(jù)庫層的構(gòu)建成為一個share nothing的分布式數(shù)據(jù)庫集群。而現(xiàn)在的MPP+Share nothing的New SQL數(shù)據(jù)庫，類似Greenpulm，Vertica，Hive等更多的都是解決OLAP層面的問題。而對于去IOE首先需要解決的是聯(lián)機事務(wù)處理層面的事情。
最近幾年出來一個新的開源MPP數(shù)據(jù)庫ClickHouse，當(dāng)前也已經(jīng)相當(dāng)成熟并不斷在真實場景中得到應(yīng)用，感興趣的也可以關(guān)注。
那么對于Share nothing的分布式數(shù)據(jù)庫，當(dāng)前也有類似Mysql Cluster技術(shù)來支撐，但是這種分布式數(shù)據(jù)庫雖然做到了高可靠性，但是由于需要支撐CUD操作，導(dǎo)致這種集群很難達到滿足實際應(yīng)用需求的存儲容量和業(yè)務(wù)高性能。在實際的業(yè)務(wù)應(yīng)用場景下，除了少量的類似MDM主數(shù)據(jù)場景比較適合采用外，真正的核心的大量業(yè)務(wù)操作和邏輯處理場景往往并不適合。
基于這種情況，當(dāng)前最常用的技術(shù)是對數(shù)據(jù)庫進行水平拆分和垂直拆分，但是這種拆分我們希望的是對應(yīng)用層透明，因此在數(shù)據(jù)庫上面引入了一個核心的DaaS服務(wù)層。但是當(dāng)前的DaaS服務(wù)層很難做到數(shù)據(jù)庫的完全透明，同時對于上層的應(yīng)用構(gòu)建造成一定的約束。包括有些跨庫的Sql語句，類似跨庫聚合Group By等的語句不支持，這些都需要應(yīng)用層自己去解決。
在跨庫后帶來的一個重要問題就是分布式事務(wù)的問題，對于DaaS來說可以解決部分分布式事務(wù)的問題，但是需要采用嚴(yán)格的XA兩階段提交來解決分布式事務(wù)，本身的高可靠性和一致性仍然需要進一步進行驗證。而對于應(yīng)用，仍然需要應(yīng)用去解決一些分布式事務(wù)的問題，即通過事務(wù)補償，base方法等去解決分布式事務(wù)的問題，這些本質(zhì)上都是削弱了對高一致性的支持，這也是CAP定量經(jīng)常說的，在一個分布式的系統(tǒng)中很難真正做到三者全部滿足。在滿足高可用性和分區(qū)容錯性的基礎(chǔ)上，往往需要犧牲一定的高一致性。
由于采用數(shù)據(jù)庫拆分和DaaS層，對于應(yīng)用層的應(yīng)用構(gòu)建將帶來比較大的變化，特別是很多原來數(shù)據(jù)庫沒有拆分的時候一個SQL就搞定的問題，一個通過數(shù)據(jù)庫層事務(wù)就能解決的問題，都會變成了分布式事務(wù)問題，或者多次調(diào)用服務(wù)操作才能夠解決的問題。這往往才是說得去IOE的一個關(guān)鍵。
自主可控，國產(chǎn)化和開源
注意前面談到的去IOE運動，最開始的考慮并不是自主可控，而是降低整個IT硬件設(shè)施和基礎(chǔ)中間件的成本投入。而當(dāng)前談的自主客戶，則更多是從自主知識產(chǎn)權(quán)，國產(chǎn)化等方面再考慮。
舉個簡單的例子你如果采購類似人大金倉，達夢數(shù)據(jù)庫，整個成本并不是一定比采用類似Oracle，SqlServer數(shù)據(jù)庫便宜多少。但是好處就是符合當(dāng)前國家的自主可控，國產(chǎn)化替代和新創(chuàng)發(fā)展趨勢。
那么開源是否也算自主可控？
實際上當(dāng)前很多國內(nèi)的國產(chǎn)化軟件，本身底層也是基于開源軟件進行的二次開發(fā)，采用開源軟件本身也是實現(xiàn)自主可控的一個關(guān)鍵。企業(yè)采用各類開源軟件，并不是開發(fā)一個新產(chǎn)品用于產(chǎn)品銷售，從當(dāng)前的開源軟件授權(quán)協(xié)議各方面來說完全可行。
開源帶來的一個好處就是至少源代碼可見可控掌控。
但是當(dāng)前開源軟件本身也出現(xiàn)免費版和社區(qū)企業(yè)版的分離，對于社區(qū)版或企業(yè)版本同樣需要付費，而且有些核心技術(shù)模塊代碼本身也沒有開源，而且開源軟件你購買后續(xù)的技術(shù)支撐服務(wù)同樣需要付費。
在很多年前我們實施SOA項目就為客戶做過比較，當(dāng)前可以選擇Oracle SOA產(chǎn)品套件和Mule開源ESB的商業(yè)服務(wù)版本。由于Mule本身是按年度收技術(shù)服務(wù)訂閱費用，實際核算下來即使按使用3到5年，那么Mule實際投入成本都超過Oracle產(chǎn)品套件。
所以開源本身也不一定節(jié)約成本，但是開源帶來的關(guān)鍵好處是自主可控。
簡單總結(jié)下就是對于國產(chǎn)化各類基礎(chǔ)軟件本身并不開源，但是符合國家大力發(fā)展自主軟件政策和最新的信創(chuàng)發(fā)展政策，從國家層面是自主可控；對于國外的一些開源軟件，本身可以開放源代碼，降低被廠商綁架的風(fēng)險，但是可能后續(xù)的技術(shù)服務(wù)也不便宜。
當(dāng)前就甲方企業(yè)來說。如果你是國企或政府行業(yè)，對各種安全性要求都更高，更多的方式都是直接購買國產(chǎn)化基礎(chǔ)軟件。而對于民營企業(yè)來說，當(dāng)前購買國產(chǎn)化軟件的很少，更多的還是采用各種開源軟件，類似Mysql數(shù)據(jù)庫，Tomcat中間件等，這些也都是很成熟的技術(shù)中間件并得到了大面積應(yīng)用和驗證。
在前面我們談到了大的集團性企業(yè)更多的思路是自建IT開發(fā)團隊，自建進行IT應(yīng)用軟件的開發(fā)和后續(xù)管控運維。當(dāng)前還有一個思路就是仍然是公開招標(biāo)，但是要求完全按自己的技術(shù)規(guī)范進行定制開發(fā)，并最終交付源代碼。
這個技術(shù)規(guī)范實際已經(jīng)制定了選擇的數(shù)據(jù)庫和中間件類型，開發(fā)框架和技術(shù)，技術(shù)標(biāo)準(zhǔn)要求等各種內(nèi)容，所有入圍的廠家都需要按照標(biāo)準(zhǔn)的技術(shù)規(guī)范，開發(fā)框架和環(huán)境進行應(yīng)用軟件的開發(fā)，這屬于定制化開發(fā)范疇，而不是簡單的提供一個你已有的成熟軟件。
注意特別是在微服務(wù)架構(gòu)后，原來的一個單體應(yīng)用往往已經(jīng)拆分為多個微服務(wù)模塊，甲方企業(yè)完全可以將一個應(yīng)用拆分后分包給多個供應(yīng)商定制開發(fā)，那么開發(fā)商之間本身就成為一個相互備份和可替代關(guān)系，而不是被單一供應(yīng)商完全捆綁。
最近從招投標(biāo)情況來這種情況逐漸變多，就是集團企業(yè)更多的是招標(biāo)軟件開發(fā)外包的大框架協(xié)議，而外包需求，外部技術(shù)規(guī)范，開發(fā)框架標(biāo)準(zhǔn)等甲方都會在發(fā)布的技術(shù)規(guī)范中說明清楚。所有入圍的廠家遵循相同的開發(fā)標(biāo)準(zhǔn)規(guī)范，技術(shù)框架體系進行開發(fā)，而且最終提供開發(fā)完成的源代碼，那么甲方也更加容易做到自主可控。
在這里必須打個小廣告。
一個甲方招標(biāo)了很多個開發(fā)商進行按自己的需求進行定制開發(fā)，那么如何加強對開發(fā)商整個開發(fā)生命周期的全過程管控和質(zhì)量檢查，確保開發(fā)商最終交付的產(chǎn)品本身滿足需求，同時產(chǎn)品本身甲方能夠接手運維。這里面就是涉及到需要對整個開發(fā)過程，CI/CD持續(xù)集成和持續(xù)交付，測試和質(zhì)量管理全過程管控。而這也正是我們DevOps平臺提供的關(guān)鍵價值。
從自主可控到云原生
在前面談數(shù)字化轉(zhuǎn)型的時候已經(jīng)談到，當(dāng)前整個IT發(fā)展趨勢是云原生。原來是IT基礎(chǔ)設(shè)施建設(shè)從自己構(gòu)建到直接使用云服務(wù)商提供的云資源池。而到了云原生階段后，整個抽象進一步上移，從資源的使用變化到服務(wù)的使用。
舉個例子來說，你原來構(gòu)建應(yīng)用需要考慮選擇哪個數(shù)據(jù)庫，然后自己安裝配置，后續(xù)運維這個數(shù)據(jù)庫。而現(xiàn)在你可能使用的是云服務(wù)商提供的數(shù)據(jù)庫服務(wù)，你不用再去關(guān)心數(shù)據(jù)庫的安裝和運維。你只需要關(guān)心應(yīng)用層的軟件開發(fā)和功能實現(xiàn)。
底層技術(shù)資源提供+底層技術(shù)服務(wù)提供都全部云化。
那么在這個時候又如何去做自主可控？
簡單來說你需要考慮的是應(yīng)用層的軟件開發(fā)，比如你使用當(dāng)前主流的類似Springcloud微服務(wù)開發(fā)框架去進行應(yīng)用開發(fā)，最終開發(fā)完成后將其持續(xù)集成和交付到云環(huán)境即可。這個應(yīng)用本身的開發(fā)源代碼還是在你手里面，你能夠做到自主可控。
但是這個時候?qū)嶋H引入一個新問題。
各個云平臺服務(wù)商都推出了自己的各類PaaS層技術(shù)服務(wù)能力，包括了數(shù)據(jù)庫，緩存，消息中間件等各種服務(wù)能力，也包括了自己的DevOps研發(fā)效能管理平臺等。其核心目的還是希望能夠?qū)⒃品?wù)延伸到企業(yè)需求開發(fā)過程管理中，做到深度綁定。
那么從企業(yè)角度你需要思考的問題就很簡單，即不能被單個云服務(wù)商完全綁架，今天你的應(yīng)用托管在阿里云，明天也能夠快速平滑的遷移到華為云，只有這樣你才能夠做到完全的自主可控。
而要做到這個，又涉及到一個核心能力就是你需要去構(gòu)建一個混合云的管理平臺，你最終開發(fā)的應(yīng)用能夠同時向不同的云環(huán)境交付，這個混合云管理平臺需要完成對多個公有云服務(wù)商服務(wù)能力的適配。而這個也是我們自己的DevOps平臺的一個優(yōu)點，感興趣的可以發(fā)翻看我前面發(fā)布過的文章進行詳細(xì)了解。
