以Netflix的API重构为例，谈如何权衡工程效率以及代码重用

正文

请到「今天看啥」查看全文

目前，该API服务可暴露三类粗粒度API： 非会员 （注册、计费、免费试用等）、 内容发现 （电视和电影推荐、搜索等），以及 内容播放 （有关流媒体播放体验的决策、确保用户可以观看特定内容的许可机制、观看历史记录、用户书签心跳信号等）。

以内容播放类API为例。假设用户在手机上点击了怪奇物语（Stranger Things）第一集的“播放”按钮。为了开始播放，手机会向API发出“播放”请求。随后API会调用底层的多个微服务。其中某些调用由于相互之间不依赖，可并行进行。其他调用可能需要以特定顺序进行。API中包含了顺序或并行执行调用所需的全部逻辑。因此客户点击“播放”后设备并不需要知道底层的各种安排。

图1：设备向API发出请求，API对不同微服务进行编排

不过有关内容播放的请求有所例外，只需要映射至负责播放的后端服务。除了播放服务外，还有很多与内容发现和非会员有关的服务，但相互之间的界限非常明显，只有少数服务需要同时发出与播放有关和无关的请求。

这种需求对我们来说算不上新发现，我们的组织结构就反映出类似的情况。目前我们有两个团队（API团队和播放团队）负责编排层的设计，其中播放团队主要负责与播放有关的API。但API团队需要负责整个API体系的完整运作，包括发布、24/7支持、回滚等。这样的做法可极大促进代码重用，但与我们所期待的，由开发不同内容的团队自行拥有并自行负责生产环境中的运作这一原则相违背。

因此新架构需要满足下列目标：

• 我们希望每个团队能自行拥有自己开发的代码并负责生产环境中的运维。这样即可实现更有针对性的预警以及更快速的MTTR。

• 同理，我们希望每个团队自行管理自己的发布计划，并在可能的情况下让自己的发布计划不受不相关变更的影响。

请到「今天看啥」查看全文