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)关注我们,并与我们的编辑和其他读者朋友交流。