聊聊什么是厂商绑定

绑定的三个矛盾

我们经常听到说要避免厂商绑定，可能主要提的商业产品上的绑定，但是使用开源软件就不存在绑定吗？Apache Struct2 臭名昭著，满分漏洞可以刷榜的存在，然后如果某个业务深度绑定了 Apache Struct2 框架，无法迁移到其他方案，那这种“开源”下的绑定，不也是一种巨大的伤害吗？这是第一个矛盾。

假如我们退一步不再纠结“厂商”，我们说避免供应链绑定如何呢？然而另一个经常挂载嘴边的说法是：不要重复造轮子。如果不重复造轮子，那又怎么能避免轮子绑定呢？这是第二个矛盾。

即便全部由自己人员来从头开发，就一定不存在绑定吗？网上充斥着程序员如何保护好自己饭碗的段子——就是把代码写到谁都看不懂，这样除了自己没人可以维护的了代码了。COBOL 语言前阵重新登上热搜，是因为美国许多 40 年开发历史的失业救济系统出现问题，只能招募退休的程序来维护。这种绑定该如何避免呢？这是第三个矛盾。

实现可替代性

所以到底什么是绑定？他并不在于产品是商业还是免费，是开源还是闭源，是自主研发还是外包服务，绑定的关键词永远只有一个：那就是可替换性，只要具备可替换性，那就没有彻底绑定。这里如果替换的成本代价很高，那就是绑的比较紧，但是用力还是可以挣脱的。

如何确保可替代性呢，最基本的遵循“标准”，更准确的说是遵循“事实上的标准”。网络产品是绑定最弱的领域之一，特别是运营商主导的路由，基站等领域，大家都遵循相同的标准规范，形成了标准的交互接口。，可以看到运营商们上亿规模的项目购买厂商的网络设备，然而我们不会说这里面存在什么厂商绑定，因为大家都具备可替代性。

避免私有特性

如果不同产品在标准的实现上有差异怎么办呢？那就应该在使用产品的时候尽可能选择各自标准的”交集“，避免使用专有的产品特性。

我们举个例子：对于应用程序而言，数据库的选型是很重要的事情，因为要更换数据库不太容易。不过我们暂且先不考虑数据迁移本身的困难，如何避免数据库选型上的绑定呢？答案是引入一些 orm 的框架，尽量避免直接编写原始的 SQL，更加要避免使用数据库独有的 SQL 语法和函数。如果能够做到这些，那么数据库是可以被替换的。因为 SQL 是所有数据库都遵循的标准语法，我们尽量使用标准规范的 SQL，避免专用的函数和语法，再引入 orm 框架进行封装，对程序屏蔽了不同数据库之间的差异，使得替换变成了可能，因此这里就解除了数据库选型的绑定。

封装屏蔽细节

刚才我们提到一个关键词是封装，这也是避免厂商绑定的一个有效路径。我们再举个例子：现在我们需要一个 API 网关，来进行 API 管理。然而 API 网关有自己的授权协议（特别是各家云上的网关，授权大都绑定自己的体系）。如果使用 API 网关原生的授权方案，这里就可能存在绑定，并且这个绑定会随着应用的开展越来越深，最终被完全绑定死，这是无法接受的。所以我们的方案是增加一层授权封装层，将他转换为标准的 OAuth2 授权协议，这意味着对下游的应用只存在标准的 OAuth2 协议，而 API 网关的私有部分被屏蔽了。因此尽管存在一定的代价，但在必要的时候，完全可以实现切换到其他 API 网关，且对下游保持 100%兼容，这就意味着消除了绑定。

这就是为什么很多时候我们会看重产品或者服务的开放能力，因为开放能力意味着允许二次封装，这就意味着屏蔽厂商产品细节，从而存在摆脱绑定的可能，当然这里需要权衡成本。我们依然举个例子：假定我们使用一些 BI 的商业产品进行数据分析，我们可以开发者和访问者都使用 BI 的账号与授权体系，这很方便也很简单，但是他存在厂商绑定。另一种方案是引入多个 BI 产品，并使用他们的开放能力对接 SSO 访问 Dashboard，构建一个封装层。这意味着只有开发者是绑定在 BI 产品上的，而 Dashboard 的访问者，他们的授权将建立在封装层上，这就消除了大部分（毕竟大部分用户是访问，开发是小部分）情况下绑定，并为业务带来了多样性。

怎么办？

如果要降低厂商绑定的风险，选择产品应该怎么办呢？

答案是尽量选择标准化的产品，并且是发售一段时间，经受过市场检验的标准化产品。这意味着产品大概率能持续的保持迭代，并且有大量其他的用户与你一同分担风险。比如大部分人对 windows 的依赖都很强，windows 有 bug 和漏洞吗？可太多了对吧，但是微软的更新和修补也很及时。微软有跑路的风险吗？不能说完全没有，但总是比较低，而且真跑路了大家这么多用 windows 的对吧，也不是你一个人倒霉。

然而这里很重要的一点在于产品的选项应该由甲方自己把控，而不是依赖于乙方的销售推荐。本质上来说，项目的技术架构方案，应该由甲方来自行设计，或者至少应该在完全理解其架构的前提下再进行选择。如果能做到这一点，至少不会再被供应商“忽悠”了——被“忽悠”正是一切“绑定”的开始。

如果一个供应商不能完全满足需求怎么办呢？

答案是尽量在在标准化产品之间做排列组合，让这些产品在”标准“的基础上交互，如果一个需求是普遍的大众场景，那在自由竞争的市场下必然会诞生覆盖着的需求的产品。在网络领域里，AAA 认证做的好的通常是各个第三方产品而不是网络设备供应商自身，微信上的小游戏，除了最开始的跳格子和打飞机，后续百花齐放的都是其他第三方开发者，这种健康的生态正是建立在”事实标准“之上。

如果标准化产品不能完全满足需求怎么办呢？

答案是将定制化部分与标准化部分解耦。我们再次发现产品开放能力的重要性，这意味着解耦的可能。而解耦意味着即便产生绑定相关的风险，也只存在定制化部分，标准化的部分如上段所述风险总体比较低。

如果注定需要定制开发，或者自主研发怎么办呢？

答案是必须要确保能够把控代码质量，避免或者至少延缓代码走向屎山的过程。并且只要业务还在运作，就要持续投入人力来保持迭代，给他一个能量，才能避免熵增，屎山代码才不会发生。

这和前面聊到的技术架构需要自行把控一样，本质上是甲方必须要有足够的技术能力，来把控乙方交付的内容，无论他是产品，还是代码，甚至外包的人员服务都一样。当甲方丧失这样的技术把关能力时，就不可避免的走向“绑定”。

如果具备技术把控的人他本身不可替代，这里的人员绑定风险该怎么办呢？

这让我想起了中国篮球，姚明受伤了还可以有王治郅，姚明退役了还有易建联，易建联老了就只能上周琦了，周琦再受伤亚运会就要输菲律宾了。毕竟球要靠人来打，事情要靠人来做，人才梯队跟不上该怎么办呢？这可能才是真正的难题。

以上