AICon 上海站|日程100%上线,解锁Al未来! 了解详情
写点什么

Netflix 试图通过开发者自治调和大规模 API

  • 2016-09-13
  • 本文字数:1557 字

    阅读完需:约 5 分钟

最近在 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 )关注我们。

2016-09-13 19:001824
用户头像

发布了 227 篇内容, 共 78.9 次阅读, 收获喜欢 28 次。

关注

评论

发布
暂无评论
发现更多内容

很多人神化了AI的能力

老张

软件测试 大模型 DeepSeek

淘宝数据获取终极指南:手把手教你调用商品详情与评论API

代码忍者

淘宝API接口

【Redis技术进阶之路】「原理分析系列开篇」高可用之Master-Slave主从架书的点制问题分析(分析旧版复制功能)

码界西柚

主从同步 redis 底层原理 redis主从复制 持久化机制

手把手教你给网站接API:从零到实战的保姆级教程

代码忍者

HDFS元信息管理的核心技术与实现

童子龙

hadoop hdfs #分布式存储

YashanDB配置资源管理

YashanDB

数据库 yashandb

人工智能丨专家系统与机器学习的概念

测试人

人工智能

Apache Paimon 在抖音集团多场景中的优化实践

火山引擎开发者社区

AI驱动的 ITSM趋势

ServiceDesk_Plus

AI ITSM IT服务管理

从 Snowflake 到 Databend Cloud:全球游戏平台借助 Databend 实现实时数据处理

Databend

堡垒机问题解答-运维安全网关是堡垒机吗?

行云管家

网络安全 等保

企业异地组网带宽效能提升攻略:公网IP与SD-WAN技术

Ogcloud

SD-WAN 企业组网 SD-WAN组网 异地组网 异地组网带宽

YashanDB资源管理

YashanDB

数据库 yashandb

抖音集团大数据血缘演进与深度应用

火山引擎开发者社区

YashanDB日志收集

YashanDB

数据库 yashandb

低代码平台:零代码基础的技术赋能与开发革命

JeeLowCode低代码平台

低代码 低代码平台 低代码凭条 低代码, 低代码选择

解锁 AI + 低代码的未来密码

伤感汤姆布利柏

抖音视频数据获取实战:从API调用到热门内容挖掘

Noah

和鲸科技受邀赴中国气象局气象干部培训学院湖南分院开展 DeepSeek 趋势下的人工智能技术应用专题培训

ModelWhale

人工智能 大数据 气象 DeepSeek

别以为AI助手只是工具,直接拔高你的工作节奏!

引迈信息

淘宝商品详情与评论爬取实战:一个野生程序员的逆向之旅与避坑指南

代码忍者

淘宝API接口

破局·共生——AI 与低代码融合的“化学反应”

秃头小帅oi

企业异地组网宽带用IPLC还是SD-WAN?

Ogcloud

宽带 SD-WAN 企业组网 异地组网 IPLC

轻松部署本地DeepSeek,一台酷睿Ultra 200H的笔记本就够了

E科讯

OpenTiny技术直播讲师招募:与开源同行,点亮技术影响力!

OpenTiny社区

开源 前端 低代码 组件库 OpenTiny

以抖音集团信息流推荐场景为例|如何做复杂的AB实验设计?

火山引擎开发者社区

Netty基础—Netty实现私有协议栈

不在线第一只蜗牛

Netty

SINANODE®技术可将碳足迹减少35%

财见

YashanDB慢日志管理

YashanDB

数据库 yashandb

YashanDB资源类型

YashanDB

数据库 yashandb

Netflix试图通过开发者自治调和大规模API_语言 & 开发_Margot Krouwer_InfoQ精选文章