文章目录
最近和客户交流的时候，听到一些的关于开源可控与开源软件使用的声音。正直华为被制裁，多个中国企业上榜美国商务部进出口管制实体名单，又有一些自媒体在带节奏，描绘开源软件同样受到实体名单限制的影响，似乎一时间，加强自主可控的声音、避免被卡脖子的声音似乎等同于拒绝采购，拒绝开源厂商的服务。
我认为自主可控是必须的，但到底如何实现真正的自主可控，可能还需要探讨。
什么是自主可控？
如果涉及到软件的使用，用一句话来形容“自主可控”，其实很简单，就是自己拥有源代码，可自主根据需求对源码进行修改，并且可以用在生产和业务场景上，而不受到任何的约束和管制。（作为商用产品售卖除外，自主可控需与白嫖，盗版区分开来）
因此，自主可控的首要前提是有源码，能自由改动，这是大多数开源协议支持的。
另外一个需要搞明白的对象是“自主”的含义，我们可以大致有两种理解，一个“自主”指的是用国内厂商具有完全自主知识产权的软件，不受国外法律的限制，因此这里的“主”是指的国家主体；另一个理解是指的企业本身，企业可根据自主意志，按自己的需求，想法在不违反的情况下自由地修改和使用软件。
那在这里，我觉得后者的理解是更加准确的。因为如果用国内国外去区分的话，我们可以看到国内很多具有完全自主知识产权厂商的软件并不是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的支持，去做了安全特性的支持，但最终的结果是并不如开源免费的部分做得好。因此，共享到开源项目中是检验产品，获得提升的手段，一旦自己被禁锢在了自己的区域内，也会影响我们享受开源带来的进步的权利。
商业上的成功，是软件持续发展的动力
毕竟所有技术的发展其背后主要的推动力是商业上的成功，是持续的盈利能力。如果为了强调，所谓的自主可控，导致成本投入过大，甚至正常的业务服务得不到保障，反过来也会影响到持续在技术上进行投入的能力。
不要忘了，身处漩涡之中的华为，即便如此，任总也在强调合作的重要性。在被断供之前，还和厂商有大量的商务合作，这些合作的价值，不应该因为雾里看花般似是而非的“断供”而被忽略。
自主可控，不是和开源的对立，自主可控，也需要拥抱开源，以正确的方式对待开源软件和开源厂商。
