likes
comments
collection
share

SDK的罪与恶

作者站长头像
站长
· 阅读数 33

SDK引入的由来

2022年由于公司发展需要，对整个项目发起重构，来解决系统可靠性差、业务需求支撑效率低的问题。重构时就考虑到关于系统配置的重新建设。

而原来系统的配置设计如下：

SDK的罪与恶

主要的问题如下：

  1. Apollo配置和业务策略的配置没有明显的边界，很多业务策略在Apollo进行配置。
  2. 业务策略配置在Apollo管理效率成为明显的问题。
    • 业务策略调整，Apollo这种纯文本化的管理方式，很容易出现格式配置错误。
    • Apollo变更，每次都要走一次发布流程，效率很低。
    • Apollo配置数据，很快就达到上限，无法管控。
  3. 业务策略配置的管理和业务系统没有形成一个闭环，适配层只是做了一层简单的配置管理，无法承担后期大量的策略建设。

基于以上问题，业务系统就需要建立一个属于自身的配置中心，来管控所有的业务策略。于是，我们就进行了重建，把原先由Apollo和配置适配层来承载的部分，全部转移到配置中心来管理。而这其中就涉及到一个问题，配置中心如何跟业务系统进行交互，来确保能够顺利替换原来的方式。

这个替换有一定的约束前提：

  • 业务系统需要基于不同的维度（比如：城市、订单来源）依赖各自不同的业务策略配置数据，就是业务系统依赖的策略配置多。
  • 业务系统要求的可靠性以及系统性能高。

原来的交互方式：Apollo和适配层都是把策略配置提前获取到本地进行存储，在使用时直接从本地获取，可靠性和性能都得到了保障。

配置中心交互方式： 新建了一个配置���理服务，所有配置数据的管理统一由配置中心收口。按照常规思路：如果业务系统需要使用策略时，再通过接口的形式从配置中心获取，这样可靠性和性能都无法跟原来本地获取相对比。

这个时候设计需要考虑的重点来了：为了保证和原交互方式一样的可靠性和高性能，配置中心建立一个SDK嵌入到业务系统，SDK直接使用本地缓存并且和配置中心的存储打通。

SDK的罪与恶

SDK带来的问题

上面引入SDK确实解决了可靠性和高性能的问题。但是同时却引入了另一个问题，就是业务系统和配置中心耦合过重，并且需要SDK版本不断进行升级。

在需求迭代的过程中，有如下一个功能场景开发：

  • 配置中心：某个策略配置A需要升级为B，这个升级既要体现在策略配置前端页面，也要体现在SDK的查询中。但是，为了确保策略升级平滑过渡，需要做一个开关支持策略A到策略B的切换。如果新策略B有问题，可以通过关闭开关，切换回策略A。

在方案设计的时候，这个开关设计就很冗余，既要在配置中心进行控制，也要在SDK中进行控制。为了确保一个开关能够同时在两侧进行生效，如果配置中心的开关变换了，还得发个消息通知SDK感知到。

SDK的罪与恶

本来一个开关切换这么简单的功能，就要考虑到配置中心和SDK两边功能的开发，设计上面就很冗余。如果使用接口的方式来交互，上面的设计就非常简单，如下所示：

SDK的罪与恶

SDK的罪与恶

设计系统时考虑是否提供SDK（Software Development Kit，软件开发工具包）是一个重要的决策点。

优势

  1. 简化开发过程：SDK通常包含了一系列工具、库、文档和示例代码，帮助开发者快速开始项目，减少重复工作。
  2. 标准化开发：SDK提供了一套标准化的开发环境和接口，确保不同开发者使用相同的方法和实践来构建应用。
  3. 提高开发效率：通过使用SDK，开发者可以利用预先构建的模块和功能，从而加速开发流程。
  4. 促进生态系统发展：提供SDK可以吸引更多的开发者加入你的技术生态系统，共同推动平台的发展。
  5. 稳定性和性能： 内部交互时通过SDK把相关的数据和能力统一封装，减少接口的交互提升稳定性和性能。

劣势

  1. 依赖性：开发者可能会过度依赖SDK提供的功能，这可能限制了他们的创新能力和自定义解决方案的灵活性。
  2. 更新依赖：SDK的更新可能需要开发者频繁地更新他们的应用程序以保持兼容性。
  3. 学习曲线：对于新手开发者来说，学习如何有效使用SDK可能需要一定的时间和资源。
  4. 技术锁定：使用特定SDK可能会使开发者在技术选择上受限，难以迁移到其他平台或技术。

SDK替代的方案

  1. APIs（应用程序编程接口） ：
    • 提供RESTful API或GraphQL API，允许开发者通过HTTP请求与你的系统进行交互。
    • 这种方式允许开发者使用他们选择的编程语言和框架来构建应用。
  2. 微服务架构：
    • 将系统拆分成一系列小的、独立的服务，每个服务都提供特定的功能。
    • 开发者可以通过这些服务的API来集成和使用功能。
  3. 容器化技术：
    • 使用Docker等容器技术，将服务打包成容器，方便开发者部署和扩展。
  4. 云服务和PaaS（平台即服务） ：
    • 提供云服务或平台即服务，允许开发者在云环境中构建、部署和管理应用。
  5. 插件系统：
    • 如果你的系统支持扩展，可以提供一个插件系统，允许第三方开发者创建插件来扩展功能。

SDK的总结

一个团队里面各个服务模块应该都是相互打通的，应该不存在还需要SDK的方式来解决问题。重构时，为了保证和原交互方式一样的可靠性和高性能，这个目的本身就值得再考量一下。

一个团队内部的系统的存储和网络应该都是互通的，可靠性和高性能本身应该有更好的方式来保障，SDK的交互方案就不应该存在。如果作为中间件，开发了一套解决方案，需要对外提供能力输出，这种情况才会考虑SDK。因为要简化外部团队的开发复杂度，通过SDK提供一套标准化的工具，来提高开发效率。

上面业务系统和配置中心，可以进行如下设计，来达到同样的效果。

SDK的罪与恶

  • 业务系统：服务启动时，调用配置中心服务的接口，把策略数据提前热加载到本地缓存中。
  • 配置中心：配置发生变更，通过广播消息发送通知，业务系统服务感知变更来更新本地缓存。
转载自:https://juejin.cn/post/7392513123861594139
评论
请登录