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