写点什么

Yelp 研发实践:使用服务拆分单块应用

  • 2015-03-27
  • 本文字数:1811 字

    阅读完需:约 6 分钟

Yelp 工程师团队表示,面对团队和代码库规模不断增长的情况,他们通过实践向面向服务架构迁移,得以使开发过程同步具备扩展能力,并且保持了快速的软件交付。这一切取决于以下因素,包括对团队灌输分布式系统的理念,创建一组基本的服务设计原则,定义服务接口规范,实现可扩展的测试方法,将对数据存储的访问封装到各自的服务接口中,同时部署一个健壮的服务发现方案。

Yelp 工程师团队在博客中表明他们很看重快速交付代码的能力。他们需要不断地进行生产系统的变更,而且这种频繁变更需要常态化保持,即便开发团队已经增长到300 人以上,Python 代码库规模也超过了几百万行。能够确保这样迭代速度的核心因素恰恰就是转向了面向服务的架构(SOA)。在过去的三年里,Yelp 工程师团队已经研发并在生产环境部署了超过七十个各式服务。

Yelp 工程师博客提出,构建面向服务的架构会迫使程序员应对分布式系统需要面临的现实挑战,例如需要面对系统部分失效以及代码由不同的团队开发的情况。Yelp 尝试采用一些手段去缓解这些问题,例如参考 Netflix Twitter ,实现并管理一套底层的基础研发平台。然而,Yelp 工程师团队还是提出,程序员只能靠自己去理解系统需要面对的这些现实问题,任何其他东西都帮不上忙。

Yelp 工程师团队倡导用多种技术手段在团队间扩散知识,包括建立一套编写和维护服务的基本准则,建立每周服务专题的例会,程序员可以自愿参加并提问探讨,同时通过咨询有过惨痛教训的人,从而帮助工程师团队从错误中汲取经验教训。

Yelp 的大多数内部服务都是以 HTTP 的方式暴露接口,并且传递的数据结构采用 JSON,这样既有优点也有缺点:

我们使用 HTTP 和 JSON 是一种折中的选择。使用标准化 HTTP 协议有一个巨大的好处,那就是可以使用业内成熟优秀的工具去调试、缓存和负载均衡。而最显著的缺点是在不考虑数据接口实现的情况下,没有标准的方案去定义服务的接口(这一点与 Thrift 这样的技术不同)。这样使得定义和检查接口变得很困难,并且会导致很糟糕的缺陷(“我原以为你的服务应该返回‘username’字段?”)

Yelp 工程师团队通过使用 Swagger 解决了以上问题。Swagger 是基于一套 JSON Schema 标准构建的,它针对 HTTP/JSON 服务接口提供统一的文档描述语言。 Swagger UI 则可以用来提供一个所有服务的集中式目录,允许所有 Yelp 开发团队成员检索已有的服务,避免重复发明轮子。

Yelp 工程师在博客上同时探讨说,对服务自身的测试应当采用标准的方法,包括单元测试和使用模拟对象集成测试。然而,跨服务的测试可能需要复杂的编排协调。Yelp 使用 Docker 容器快速提供私有的服务测试实例,包括数据库实例。核心的想法是服务的研发团队有责任发布自身服务的 Docker 镜像,供其他服务开发人员可以将这些服务置为依赖项,并在对其他服务进行验收测试时使用。

Yelp 服务中有很大一部分需要对数据进行持久化,工程师团队使用了 MySQL、Cassandra 和 ElasticSearch 的组合。Yelp 工程师在博客上说,无论数据库存储选用什么产品,底层的实现细节只需要服务自身了解。这种做法能够使服务作者拥有长期的灵活度,可以随意更改底层数据的表述方式,甚至是改变整个数据库。

面向服务架构的一个核心问题是如何发现其他服务实例的位置。Yelp 使用了 AirBnB 的 SmartStack 服务发现机制,将服务发现的问题从应用自身中脱离出来,交由其他独立进程来解决。SmartStack 包含两个进程; Nerve 用于服务注册,Synapse 用于服务发现。Yelp 研发团队在博客上说每一个服务节点都运行着一个绑定本地节点的 Synapse HAProxy 实例。HAProxy 负载均衡会读取 Nerve 在远程 Zookeeper 上服务注册的信息,并动态配置服务路由。这样一来,本地的负载均衡器可以将服务请求路由到其他健康的服务实例上,从而使一个服务可以连接其他额外的服务。

Yelp 工程师在博文结束时表示下一代名为 Paasta 的服务平台研发工作已经开始,项目会使用 Apache Mesos Marathon 框架的组合,在集群机器之间分配容器化的服务实例。关于这个项目的更详细的内容将于今年晚些时候在博客上发布。

在Yelp 官方博客上,大家可以找到更多关于 Yelp 开发团队使用服务分解单块应用的细节。

查看英文原文 Yelp Engineering: Using Services to Break Down a Monolith


感谢赵震一对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

2015-03-27 02:202936

评论

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

React源码分析7-state计算流程和优先级

goClient1992

React

Baklib|FAQ页面是什么?为什么它是必要的?

Baklib

Vue 组件通信六种方法

默默的成长

Vue 前端 10月月更

37手游基于云平台的大数据建设实践

Apache Flink

大数据 flink 实时计算

阿里老表总结的“JVM核心笔记”,让我瞬涨7K!

程序知音

Java 架构 性能优化 JVM 后端技术

运维监控管理平台 TASKCTL 流程启动的3种不同模式

敏捷调度TASKCTL

大数据 数据仓库 自动化运维 TASKCTL DevOps工具

基于 openEuler 22.09 版本构建的 NestOS 全新发布!

openEuler

镜像 操作系统 openEuler

从 0 到 1 上手阿里云服务器 ECS(四)

六月的雨在InfoQ

Docker 阿里云 容器技术 ECS 10月月更

《数字经济全景白皮书》证券财富管理篇 重磅发布

易观分析

金融 证券

SAP | 常见的命令字段格式

暮春零贰

SAP abap 10月月更

算法评测在本地生活地图技术领域的探索和实践

阿里技术

算法 可解释

一文带你玩转ProtoBuf

王中阳Go

Go 微服务 RPC protobuf 10月月更

IaC示例:Terraform & Ansible自动化创建K3S集群

mengzyou

DevOps ansible IaC Terraform

Vue 全部生命周期组件整理

默默的成长

Vue 前端 10月月更

阿里大牛强力推荐:springboot实战派文档,采用知识点+实例的形势,深入了解

Geek_0c76c3

数据库 spring 开源 程序员 架构

React源码分析8-状态更新的优先级机制

goClient1992

React

中国CRM要超车,没有弯道

ToB行业头条

分布式事务

C++后台开发

分布式 分布式事务 后端开发 linux开发 C++开发

Baklib|还在为客户服务繁琐感到麻烦?快用帮助中心

Baklib

Baklib|企业文档管过不来?试试新型文档管理

Baklib

数据库改造方案 | 同花顺、弘源泰平真实案例分享

TDengine

数据库 tdengine 时序数据库

《新手测试正确的打开方式》

测吧(北京)科技有限公司

软件测试 测试

基于 Impala 的高性能数仓实践之物化视图服务

网易数帆

大数据 impala 企业号十月 PK 榜 物化视图 Calcite

Vue 状态过度

默默的成长

前端 Vue 3 10月月更

FinClip | 2022 年 9月产品更新放送

FinClip

人工智能软件及服务细分市场数据监测报告合集

易观分析

人工智能 报告

Bklib|客户体验数字化转型成未来企业升级的新目标

Baklib

数字化转型

【一Go到底】第十三天---循环控制

指剑

Go golang 10月月更

Dataphin V3.6版来了!多项能力升级,助力企业提升全链路数据治理能力

瓴羊企业智能服务

煤矿上的女孩

脑极体

Yelp研发实践:使用服务拆分单块应用_SOA_Daniel Bryant_InfoQ精选文章