我与 SDK 之间的爱恨悲欢

在张爱玲的小说笔记中，我摘录过这么一句话：

你如果认识从前的我，也许你会原谅现在的我。

之所以将其摘录，是觉得这句话怎么看都很有道理，时间在变，人无时无刻也不在变，似乎充满了无尽的正能量。

的确，时间可以抹去多数的恨与悲，时间可以记录许多的爱与欢，可唯独那些惨杂着爱恨悲欢的事件，不但无法抹去，而且铭记在心。

在我的从业生涯中，够资格的，应该要属围绕 SDK 所发生的那点事了。

这里说的 SDK 是什么？

所谓 SDK，全称为 (Software Development Kit) ，中文叫 “软体开发工具组”，是用来帮一个产品或平台开发应用程式的工具组，由服务开发者提供给接入开发者使用的的工具包。

说白了，就是一个用于连接服务端的公共组件工具箱。

自古道 “手巧不如家什妙”，好工具不仅能够提高开发效率，避免重复开发，而且还能降低 BUG 率，便于升级与维护；

可自古又道 “拙匠常怨工具差”，当出现问题或异常时，把工具当成头号嫌疑犯，这也是常有的事。

爱与欢：SDK 是最人性化的设计

今年年初，为了提供更好的基础服务体验，基于松耦合、快速迭代的产品理念，在分布式缓存的第三代设计上，我们果断放弃了第二代所采用的 OpenAPI 模式，而尝试 SDK 模式，结果受到应用研发各团队的一致好评。

从产品收益者的角度来看，SDK 给接入者带来的收益是：

进一步拓展传统的统一通信和控制台边界，方便开发者、链路跟踪及日志分析等功能紧密整合到一起，从而创建独一无二的管理者体验；

通过 API 封装通信功能，降低开发者对通信技术和协议的门槛，直接调用通信能力内嵌于应用之中；

利用 SDK 实现负载均衡策略，支持热加载，与平滑过渡、扩容伸缩；

这些收益确实实在在的落在了掌心，为用户带来了多、快、好、省的利益，得到赞美与夸奖也是理所当然的。

就在上线的第二周，为了这样表彰大家的辛劳，推杯换盏在所难免，在宴席上，某同学借着酒劲说了一句 “SDK 应该说是最人性化的设计啦”

的确，无论服务方还是接入方，此时此刻充满脑海的，除了爱，更多的是欢……

恨与悲：异常都是 SDK 惹的祸？

几个月前，在某次缓存超时告警事件中，原本沾沾自喜的 SDK 模式，却被推到了风口浪尖：

SDK 交付前测过吗？测过？没问题？那为什么我们一用上就有异常？

我们 FullGC 那么高，是不是你们 SDK 导致的？

负载均衡算法是不是有问题？你们是怎么实现的？干嘛之前不告诉我们？

连珠炮般的问题，有时让人难以招架，不过又由于缺乏数据留痕、监控评测、日志分析等手段而难以给出具有说服力的回应，所以唯一能做的就是当出现问题时，用主动积极的态度、人肉化的手段，勉强应对进行处理。

在大智慧工作期间，类似的场景我也遇见过多次，一般任何以 SDK 模式提供接入的平台或产品，当应用本身出现异常或故障时，SDK 都会被优先贴上疑犯的标签，随后被拖到死角打个半死，甚至屈打成招（无法提供有效证明）的案例不在少数。

不可否认的是，SDK 的场景模拟测试至关重要，但令人愤恨的是，要想持续开展却非常困难：

与应用接入方的版本迭代周期不一致，无法及时获得测试环境；

与应用接入方的目标不一致，很难在应用测试周期中增加 SDK 的测试用例；

为了测试 SDK 而特地搭建应用模拟环境，无论从成本，还是收益角度出发都不合适；

的确，无论什么理由，作为 SDK 提供者，当使用者出现问题与异常时，都应毫无理由的给予积极协助，但却隐含着一种恨与悲……

可能大家会问……

出现这种情况，基本都属于监控没做到位，如果做到位肯定一眼就能发现

好一个 “如果做到位”，作为一家快速发展的互联网企业，除了某某某公司之外，又有谁家的监控不是 “一步一踩屎” 爬过来的？在设计当初就能 “掐指一算” 考虑得面面俱到？

也许有人会说，既然这样，干脆把 SDK 移交给应用研发团队自己去维护不就行了

您说的没错，上文提到的这些点，或许可以得到改善，但任何一种选择都会有利与弊之分。

比如 SDK 中通常会包含通用算法、公共方法等较为共享的内容，如果移交，那该有哪个团队接手呢？如果各自维护，那原本基于 SDK 获得的收益又将不复存在，并进入之前的恶心循环了吗？

对于我来说，能做的只是在企业与团队的发展过程中不断的去寻找平衡。或许这种平衡，无论时间多久，也永远，永远，无法找到……

本文转载自头哥侃码公众号。

原文链接：https://mp.weixin.qq.com/s/g7mlGxTlCqsDnl6Am1G1lg