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

原文  http://www.infoq.com/cn/news/2015/03/yelp-soa-break-monoliths

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

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

Yelp工程师博客提出，构建面向服务的架构会迫使程序员应对分布式系统需要面临的 现实挑战 ，例如需要面对系统部分失效以及代码由不同的团队开发的情况。Yelp尝试采用一些手段去缓解这些问题，例如参考 Netflix 和 推ter ，实现并管理一套底层的基础研发平台。然而，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

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