最近在 Netflix 公司的技术博客网站上，该公司的工程经理 Katharina Probst 和 Justin Becker 合作撰写了一篇博客，内容是关于如何在API 环境中维持开发者自治的问题。这篇发布于2016 年8 月23 日的博客帖子题目为“工程上的权衡及Netflix API 的重架构”，文中探究了在API 环境中使用多种团队共享的服务时，调和开发者代码和流程所有权中所存在的难点问题。
当前微服务正在崛起，完全自包含、自维护的软件栈也正受到软件工程社区的日益重视（例如使用 Docker 这样基于容器的开发很受欢迎），但是这种趋势与一些用户的需求是相互矛盾的，因为这些用户希望能访问一些不同类型服务的数据，但不希望大量额外地增加自身应用的复杂度。对于围绕着代码复用和协作的工业标准最佳实践而言，它们与微服务间也有着复杂的关联性，因为它们在外部软件的微服务中建立了内部依赖。
在这篇博客帖子中，Probst 和 Becker 写道：“……我们的工作就是去调和貌似冲突的工程原则，其中包括了速度及完全所有权与代码复用最大化及合并之间的冲突”。鉴于 API 本身就意味着多个服务间的通信，一个棘手的问题就是如何去维持一个团队内部所使用数据的所有权问题。如果每个微服务都具有与消费者直接通信的 API，那么该微服务必须承担其所有消费者的各种请求，对请求整体的削弱就构成了一个完全独立且最大产出的服务。但是如果存在一个用做所有微服务缓存层的独立 API，尽管这意味着个体服务对用户实际上如何消费自己的数据并没有多少的控制权，但是这也使得 API 可以涵盖所有可能的消费者请求。
Probst 曾在 QCon 2016 纽约大会上报告称，为更好地适合很多自治应用的需求，Netflix 正计划对自身 API 进行可能的改进。在 Netflix 有一个 API 用于提供微服务与各自 API 间的编排服务。在由该 API 承担所有独立微服务中一千多种不同设备的消费者请求的同时，也引入了单点故障问题。即该 API 的宕机将会影响到所有的消费者服务，而不是仅仅影响到一小组相关用户。为缓解这样的服务污染的隐患，Probst 计划在未来版本的 API 中采用容器技术。她在 QCon 大会的报告中提出：“今后，当某个脚本对一大类情况都存在问题时……当某个设备或设备脚本不可用时，将不会影响到其它的设备，也不会影响到 API。”通过保留单一编排 API 并使用容器分隔过程实现对风险的降低，Probst 得以保留与所有面向消费者微服务通信的单一 API，进而形成完美的共享工具和服务的平台。而对很多微服务而言，共享工具和服务是一个臭名昭著的痛点。
虽然 Probst 已经确定了使用容器去分隔脚本等在内的一些关键 API 决策，但是很明显还存在其它的一些问题，这些问题尚未给出最优的解决方案。例如该博客帖子的一个主要话题就是，是否应该具有多个编排 API，这些 API 赋予底层服务对编排更大的控制能力；或是让已有的 API 包含更少的逻辑以成为更严格意义上的数据接口服务，而让大多数的逻辑围绕着消息而构建，并在将消息于逻辑自身服务组特定的逻辑层中提供给消费者之前，将该逻辑添加到数据层中。对于第一种方法，难点在于同时同步所有不同的编排，这构成了共享软件跨越多个服务分组的障碍。对于第二种方法，难点是对于非真实添加的功能，即仅是在各服务间做更大程度上的区分和更细粒度的控制，如何验证它们所导致的延迟增加。这个博客帖子最终并未给出明确的抉择，但是暗示了未来的选择取决于不同权衡间的妥协。考虑到随着通用工具、库和消费者连接性的需求增长会持续增加更多的独立自包含服务，所以可能当前并没有一种完美的解决方案。
查看英文原文： Netflix Attempts to Reconcile Large Scale APIs with Developer Autonomy
感谢夏雪对本文的审校。
给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。
评论