最近和客戶交流的時候，聽到一些的關於開源可控與開源軟件使用的聲音。正直華爲被制裁，多箇中國企業上榜美國商務部進出口管制實體名單，又有一些自媒體在帶節奏，描繪開源軟件同樣受到實體名單限制的影響，似乎一時間，加強自主可控的聲音、避免被卡脖子的聲音似乎等同於拒絕採購，拒絕開源廠商的服務。
我認爲自主可控是必須的，但到底如何實現真正的自主可控，可能還需要探討。
什麼是自主可控？
如果涉及到軟件的使用，用一句話來形容“自主可控”，其實很簡單，就是自己擁有源代碼，可自主根據需求對源碼進行修改，並且可以用在生產和業務場景上，而不受到任何的約束和管制。（作爲商用產品售賣除外，自主可控需與白嫖，盜版區分開來）
因此，自主可控的首要前提是有源碼，能自由改動，這是大多數開源協議支持的。
另外一個需要搞明白的對象是“自主”的含義，我們可以大致有兩種理解，一個“自主”指的是用國內廠商具有完全自主知識產權的軟件，不受國外法律的限制，因此這裏的“主”是指的國家主體；另一個理解是指的企業本身，企業可根據自主意志，按自己的需求，想法在不違反的情況下自由地修改和使用軟件。
那在這裏，我覺得後者的理解是更加準確的。因爲如果用國內國外去區分的話，我們可以看到國內很多具有完全自主知識產權廠商的軟件並不是Open Source，一個黑盒軟件是無法可控的。
什麼是自主可控的對立面？
我們在談論自主可控的時候，對象應該是通常情況下無法掌控的對象，特別是我們很容易被所謂"卡脖子"的對象。這裏不應該是指的國外開源軟件，更加準確的，應該是不開放源碼和技術的黑盒廠商，畢竟衆多的開源項目的源碼是開放的，我們完全有能力通過各種方式獲得代碼，自己編譯代碼軟件，獲得最新的開源軟件和功能，在此前提下，也完全不存在進出口管理限制的問題，可以做到自主可控。而黑盒廠商的技術或軟件，因爲沒有源碼，也沒有開源協議，完全依賴商業授權，倘若暴露在斷供的風險之下，則抵抗風險的能力是非常之弱的。
自主可控的大背景下
該如何使用開源？
對於開源協議，想必大家都是瞭解的，如上所述，一個開源軟件的使用，在有源碼，可自主編譯，修改的情況下，是完全不會存在進出口管制的問題的，這裏引發爭議之處，或者說焦慮點的地方是開源軟件的商用版本，在“實體名單”的風險之下，商業軟件可能會存在被斷供的情況。
因此，對於開源軟件基於我們原先架構選型/評審時的原因，該用的還是應該繼續使用的，這裏討論的重點應該是我們該如何獲取對開源軟件的主動權，即便在商業軟件斷供的時候，也可以做到不受影響，或者說，儘量把影響降到最低。任何的未雨綢繆，防患於未然都是值得的，從現在開始，就要做好最壞的打算。我們姑且不討論中美完全脫鉤，所有的商用軟件都不能使用這種極端情況的具體可能性。我們就先根據墨菲定律，假設這種最糟糕的事情一定會發生，這種情況下我們該怎麼辦？
從我目前瞭解到的部分開源用戶的想法/做法就是，從現在開始就不再採購開源軟件的商用版本和商用服務。轉而集中精力，自己研發，自己把控，在特定的場景上，放棄商用功能，使用自己開發的替代方案，甚至是另起爐竈，做出一套完全自主的產品。誠然，這樣的成功例子是有的，部分企業真的做到了，但這畢竟是統計上的極少數，客觀上，這需要有大量優秀的工程師，並且對開源軟件的使用上積累了大量經驗才能夠做到。但國內還有數以萬計的用戶，實際上尚不具備能真正做好自主研發的能力，還需要與廠商合作來保證自己商業的成功，因此，這是不是一個最優解，甚至，這是不是一個合理解，還非常值得商榷。
我們可以把這個想法/做法拆分爲三個部分來分開討論：
不再採購開源軟件的商用版本和商用服務
在特定的場景上，放棄商用功能，使用自主開發的替代方案
另起爐竈，做出一套完全自主的產品
對於第一點，我們先暫時不討論這麼做是否合適，第二點是我們的關鍵，因爲開源軟件的開源部分是沒有風險的，我們只需要解決有風險的商用部分，找到無風險的替代方案即可，自主研發風險最低，困難適中，可以實現。而第三點，如果沒有以軟件盈利爲目標，並且有清晰的盈利模式和渠道，則大多數企業完全沒有必要再重新畫輪子，畢竟投入過於巨大，成功的概率過於渺小。
需要再次明確的是，引發此討論的主要原因在於我們要在商業軟件可能斷供風險之下，儘量把風險的影響降到最低。風險的影響也可以進行拆分：
斷供情況下：
商用軟件不能使用，業務立即受到影響
在沒斷供情況下：
爲應對風險，進行了大量的投入，成本受到影響
爲應對風險，與廠商脫鉤，服務穩定性和正常運維受到影響
在開源商用版本可能斷供的情況下
規避或減緩風險的辦法？
這裏，主要的風險影響是商用軟件不能使用，業務受到影響，再具體準確一點，應該是指的開源軟件的商用部分不能使用，而開源部分是不受影響的。因此，我們的預防這個風險，或者說規避這個影響的主要方式應該是：
在必須使用到商用功能的場景，有自主可控的Plan B，可以完全避免斷供帶來的影響。
而爲了實現這個Plan B，或者說是替代方案/自主方案，我們需要投入成本，是我們的次要影響。這個風險影響無法規避，我們只能減緩，主要目標是：
找到最高效的方式，以儘可能低的成本，獲取替代方案。
而如果當前選擇與廠商硬脫鉤，或者不掛鉤的方式，選擇完全自己使用和運維開源軟件，我們可以看到的風險是，缺乏售後和諮詢的支持，而在版本升級、bug修復、漏洞修補等方面可能會滯後，商業服務可靠性、穩定性和正常運維可能會受到影響。這部分可以採取多種規避或者減緩措施：
繼續與廠商合作，在理論上的斷供發生之前，通過廠商來保證服務的正常運行，並且積極尋求技術支持，來提高自身的能力
尋找第三方合作伙伴提供類似原廠的服務
投入技術人力，完全掌握開源技術的完整內容，自己保證高質量軟件的維護
尋找國內沒有斷供風險的其他軟件廠商，提供類似的功能
毫無疑問，第一種方案是最爲合理的。這裏，我們結合之前提到的幾個點來分析一下。
規避或減緩風險的合理做法？
首先，對於主要風險，我們預案是 “在必須使用到商用功能的場景，有自主可控的Plan B，完全避免斷供帶來的影響。” 這裏的核心在於，如何能夠做出自主可控的替代方案，另外一個重要問題的，什麼是最高效的方式，能夠以儘可能低的成本來獲取替代方案。
對於大多數企業來說，要想自己做到自主可控，規避風險，是一定要沉下來仔細專研開源軟件的代碼、架構、測試，然後掌握定製化修改的能力的，但也並非沒有捷徑，學習和模仿是快速掌握的方法。因此，我們不僅不應該切斷與廠商的聯繫，相反，自己越是有可能面臨風險，越應該建立與廠商的聯繫，直到這種聯繫真的會被外部客觀不可抗拒原因所切斷。
使用開源不意味着我們要完全靠自己的努力去重頭開始摸索和學習，因爲畢竟我們不是一直在開發和維護這個產品的團隊，我們不一定對所有的場景、需求和坑有足夠清楚的認識。我們完全可以從商用版本上去學習那些必要的高級功能特性的使用跟經驗，我們可以學習其產品的研發思路。比如，瞭解爲什麼商用版上要這個特性？該特性在實踐中解決了哪些背後的需求和痛點？它是如何解決的，思路是怎樣的，功能是如何實現的。我們可以在不停的使用過程中總結經驗和學習知識，並且，跟開源社區以及廠商的售後及諮詢保持足夠的溝通和交流，也能加快我們瞭解產品的進程。通過這樣的方式，我們才能夠更有效地掌握開源產品的核心屬性跟能力，以最高效的方式實現替代方案，避免走過多的彎路。同時，在這種方式下，我們可以做到業務的發展不受影響，保證服務的可靠和穩定。
開源的一大特性，就是背後有龐大的開源社區，是各種聲音，需求融合後演變爲軟件產品的地方。開源的先進性代表着對市場需求的不斷響應、不斷地迭代、不斷地進化。創新不是一個一蹴而就的事情，而是一個持續演進的過程，我們需要通過不停的接觸最新的思想，在社區裏面不停的交流，聽到不同的聲音，才能夠掌握最能解決問題的技術。而自主可控，也應該是一個持續的過程，在技術不斷演變的過程中，持續的做到自主可控，因此，自主可控的那部分內容，也需要持續的瞭解整個社區內部的最新的變化，跟原廠的合作實際上是瞭解到技術演進的方向的最有效的手段之一，然後，以這些信息爲嚮導調整自己產品設計的思路。
因此從這幾個方面來看，我們要做到完全的自主可控。其實第一步就是要全面瞭解廠商的技術、架構、設計、方向、願景，這個不能夠脫離商業產品的特性，自己去想象，必須融合整個社區的思想。瞭解多方面的信息，不能夠閉門造車，故步自封，需要師夷之長技。
舉個例子，我們要自主實現一些開源軟件的商用功能，比如，Elasticsearch的災備（CCR）。在沒有大量的用戶反饋，跟實踐經驗的前提下面我們很難做到一個考慮完備的解決方案，這時候，我們可以借鑑廠商的商業特性去了解他的設計思路，可以去跟售後支持，跟諮詢架構師去討論具體實現的一些細節，可以通過問問題的方式，加深瞭解。可以自己去做定製化的改造，在改造的過程中，通過跟原廠進行交流，積累經驗。又比如說，我們要在Elasticsearch上做機器學習的功能。我們可以觀察官方解決方案中的端到端的設計思想，如何從數據攝入，到數據提取，數據分析，到建模，再將模型應用到流式框架上實時計算，從而一步一步的去夯實自己的知識。
持續更新和共享的重要性
如果要說開源軟件最大的優勢，其實是其背後的社區驅動，是持續的需求響應和持續的特性迭代。
自己定製化開發，自主可控的一大問題是可能無法保持版本的同步。我們不能夠拿到一個版本之後，就只停留在這個版本上面，而不做持續的升級，我們要計劃好這部分的投入，其實這不是一次性的而是持續的，我們需要去考量我們投資回報率。即便是最開放的互聯廠商，他們也會去思考，什麼時候應該用自研，什麼時候應該用商業產品，他們也會持續的在社區裏面反饋和原廠進行合作。簡而言之，就是自主可控並不意味着就不和廠商合作，相反，只有跟廠商進行更加深度的交流及合作，才能夠做到真正的自主可控，才能真正的不被別人卡脖子，才能把對方的技術轉化爲自己的能力。
我們可以看到，無論是阿里的OceanBase，還是中興的的Golden DB，甚至說到我們這幾年一直在做的去IOE架構。這些變化能夠產生的前提是我們已經足夠的瞭解已有產品，比如，Oracle數據庫的功能特性，我們足夠了解mySQL數據庫才能夠在上面去做自主研發和創新。但是我們也要看到，mySQL這些數據庫的開源社區背後也是足夠活躍的，他們並不是停滯不前的，社區提出share-nothing分佈式架構是Golden DB能夠推出的原因之一。所以即便我們要去做自主研發，也不可能脫離社區，不可能脫離開源，不可能脫離技術的共享，因此。保持足夠的開放性，保持足夠的技術敏銳，保持足夠的需求敏銳是能夠保持先進的前提條件，因爲，自主可控絕不是落後，老化的同義詞。我們不能夠迴避廠商。切斷交流的渠道，我們應該做的是在保持最低限度的交流的情況下面。持續學習，掌握核心技能。
這部分我們可以參考騰訊雲和阿里雲，上面的服務上面有定製化，自主化的服務：
也有廠商提供的商用服務:
爲什麼它們在具有自己開發的能力時，還要持續的保持着跟原廠/社區的合作和交流？主要的問題就在更新和共享。
比如新增的功能、特性、優化，要怎麼把它變成一種持續優化的東西，唯一的方法就是把其併入到主分支，持續和整個開源軟件集成到一起，成爲開源的一部分，讓自己成果固化的同時，能夠和開源一起演進，同時避免自己拉的分支，需要一直需要持續merge，持續適配的問題。
另外一個，我們會看到騰訊和阿里在開源社區上面的持續提交這些能力，並不會變成商用版本里面的特性，而是對整個產品的開源部分的持續的優化。開源的精神是我爲人人，人人爲我。自主可控不應該成爲和開源相對應的相對立的一種意思。把開源融入到血液中，這是他們的業務能夠持續保持先進性的一個主要原因。
另外一個需要思考的是到底需要在哪些點上做自主可控，自己做的自主可控的功能能否足夠的優秀，足夠的成熟。比如，很多廠商自己在ES上去做了SQL的支持，去做了安全特性的支持，但最終的結果是並不如開源免費的部分做得好。因此，共享到開源項目中是檢驗產品，獲得提升的手段，一旦自己被禁錮在了自己的區域內，也會影響我們享受開源帶來的進步的權利。
商業上的成功
是軟件持續發展的動力
畢竟所有技術的發展其背後主要的推動力是商業上的成功，是持續的盈利能力。如果爲了強調，所謂的自主可控，導致成本投入過大，甚至正常的業務服務得不到保障，反過來也會影響到持續在技術上進行投入的能力。
不要忘了，身處漩渦之中的華爲，即便如此，任總也在強調合作的重要性。在被斷供之前，還和廠商有大量的商務合作，這些合作的價值，不應該因爲霧裏看花般似是而非的“斷供”而被忽略。
自主可控，不是和開源的對立，自主可控，也需要擁抱開源，以正確的方式對待開源軟件和開源廠商。
本文作者
李捷
Elastic資深解決方案架構師
專注於Elastic Stack 的解決方案的設計和諮詢。13年軟件行業從業經驗，從嵌入式開發，到後端J2EE應用和前端界面開發。從爬蟲腳本，到區塊鏈和大數據分析。從開發工程師，到測試工程師和項目經理。擁有全棧開發經驗和豐富的項目實施經驗，同時也是一個活躍的知識分享者和社區活動者。
本文分享自微信公衆號 - Hadoop實操（gh_c4c535955d0f）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。