【干货下载】谷歌、亚马逊等十大公司精选微服务案例

摘要：自去年以来，微服务受到了前所未有的关注，众多的互联网巨头开始实施微服务架构并取得了不错的反响，话不多说，今天我们就为大家盘点一下谷歌亚马逊等十大科技公司的微服务实践案例。

自去年以来，微服务受到了前所未有的关注，众多的互联网巨头开始实施微服务架构并取得了不错的反响，话不多说，今天我们就为大家盘点一下谷歌、亚马逊等十大科技公司的微服务实践案例。

谷歌

随着多元化微服务的流行，越来越多的服务开始采用微服务来构建。近日，曾在Google和eBay担任高级职务的Randy Shoup在博客中分享了其从这两个公司所学习到的构建大规模服务架构的经验。本文对Randy谈论的内容进行了总结，为那些没有创建、使用和保护大规模架构的工程师提供参考。

拥有多元化微服务的大规模生态系统运行情况如何呢？

eBay和Google采用了数百到数千个多带带的服务来协同工作。
现在的大规模系统都是以图的形式，而不是层次式或多个连接的形式来构成服务。
服务之间相互依赖。
只有旧的大规模系统采用高度集成的方式进行组织。

目前运行良好的系统都是不断变革的产物。例如，Google从来没有对系统进行过集中的设计。当前的系统纯粹是适应时代和技术发展演变而成的。变异和自然选择。当一个新的问题出现，工程师通常选择利用已有的产品或服务来解决。因此，一个服务只有在不断的提供价值、不断被使用的情况下，才能避免被淘汰的命运。

详细文档请关注我们微信号，回复“京东”，获取下载地址

2.亚马逊

Munns是Amazon的DevOps部门的业务开发经理，他在演讲中引用了维基百科上微服务的定义，但同时也列举了微服务的4条使用上的限制：
单一目的。
仅通过API进行连接。
通过HTTPS协议进行连接。
微服务之间大体以黑盒的方式展现。

描述团队的规模有一个著名的术语，即刚好能吃完两只披萨的团队。在Amazon，这样的团队被称为服务团队，他们对于创建过程具有完全的自主权，包括产品的计划、开发工作、运维以及客户支持。他们具备完全的自主权及责任性，同时也负责每日的运维和维护工作。换句话说，谁创建的服务，就由谁负责运行。这意味着质量保证（QA）人员以及运维人员都隶属于服务团队之中。但Munns也提到，承担这一角色的部分员工也有可能由整个组织共享。
对于团队来说，这样的文化意味着很高的自由度，但这些团队将通过以下途径得到授权并保证实施的高标准：

全面的培训。
由具有20年以上开发经验的员工全面定义各种模式与实践。
在业务与技术两方面定期进行衡量指标审查。
由内部的专家分享关于新工具、服务与技术的知识。

Munn对于小型团队与微服务在Amazon的发展进行了深入的观察，以了解其重点所在。对于其他打算按照相同方式发展的组织，Munn提出了一些建议：

文化 —— 这里要强调一点，自主权与责任是不可分离的，规模越大的团队，其运作速度相对于小型团队将有所下降。团队要坚持卓越产品的标准，但并非坚守做事的方式一成不变。
实践 —— Munn提到了持续集成（CI）与持续交付（CD），以及简化运维任务的重要性。
工具 —— 这些工具将用于之前所提到的实践、基础设施的管理、指标的设立和监控，以及交流和协作。

Munns最后强调了为服务和客户建立起一种模式的重要性，这将使组织避免重复发明一些相同的基础部件，将精力浪费在通信、授权、防止滥用和服务发现等任务上。他还阐述了构建、托管、服务的指标对于观察基础设施是否按预期运行、SLA是否得到满足等问题的重要性。

详细文档请关注我们微信号，回复“亚马逊”，获取下载地址

3.Twitter

在围绕微服务展开的探讨当中，我们发现几乎很少有人能够切实回答上述问题。以Docker、Mesos、Kubernetes以及gRPC为代表的各类新型技术成果的快速崛起使得我们能够轻松建立小型新架构。然而，高流量生产性用例又该如何实现？根据我们的推算，目前能够以规模化方式运行微服务，从而解决实际问题的企业数量仍然相当有限。

Twitter就是其中的典型代表。而且尽管其也经历过公共服务中断，但Twitter负责运维的是世界上规模最大的微服务应用之一，其中包含上百种服务、数以万计的节点以及每项服务中的数百万RPS。令人震惊的是，事实证明这样的工作绝非易事。虽然不是不可能，但需要企业投入多年并充分运用自身聪明才智，从而令一切在实践层面运作良好。

当Oliver和我前几年离开Twitter公司时，我们的目标是运用自己多年积累下的专业知识，将其转化成可供全世界各组织机构使用的可行性资源。令人振奋的是，这些知识中已经有相当一部分以开源项目的面貌了，也就是Finagle项目——这是一套用于支撑Twitter微服务架构的高通量RPC库。

详细文档请关注我们微信号，回复“Twitter”，获取下载地址

4.SoundCloud

很多的技术文章着重介绍的都是项目后总结出的最佳实践，本文从另外的角度，介绍项目中解决问题的整个探索过程，详细讲述了在最终使用微服务架构之前所做的种种分析和尝试，这对于正在尝试解决问题的技术人员来说有很大的启示作用。

当我最初加入公司的时候，手头最重要的项目内部称之为v2。该项目对我们的网站做彻底的改版，发布时的商标名称为The Next SoundCloud。

一开始我加入了后端团队，App团队。我们负责巨大的Ruby on Rails应用程序。那时候还不称其为遗留系统，而称之为mothership。App团队负责Rails应用相关的所有事情，包括旧的用户接口。Next是一个单页面的JavaScript web应用程序，我们遵照当时的标准实践，将其构建为公开API的常规客户端，用Rails monolith实现的。

App和Web这两个团队是完全隔离的 -- 甚至在Berlin距离挺远的不同的大厦办公。我们几乎只在所有人都参加的大会上才能看到彼此，主要的沟通工具是问题跟踪系统和IRC。如果你问任何一个团队的任何人我们的开发流程时如何工作的，他们可能会这么回答：

有人想到了某个功能，随后写了很多描述，并且画了些模拟图。
设计师优化了用户体验。
编写代码。
一些测试之后，将应用部署。

但有时候这个过程会遇到一些障碍。工程师和设计师都抱怨他们加班过多，但同时产品经理和合作伙伴则抱怨他们永远无法按时得到想要的东西。

详细文档请关注我们微信号，回复“SoundCloud”，获取下载地址

5.Netflix

Cockcroft解释他在Netflix的职位是云架构师，他的职责不是管理架构，而是发现和标准化公司工程师所形成的架构。Netflix开发团队提出了几条设计和实现微服务架构的最佳实践

每个微服务的数据多带带存储

不同微服务不要使用同一个后台数据存储。让开发团队选择适合每个微服务的数据库。或许，不同团队使用同样的数据结构来存储会减少工作量，但当其中某个团队想要更改数据结构的时候，其他服务不得不跟着改变。

数据的拆分会使得数据管理异常复杂，是因为多带带的存储系统不容易同步，易于出现不一致的情况，外键也会发生意外的改变。你需要一个后台运行的主数据管理的工具来发现和修复不一致的情况。比如，你需要检查每个存储订阅者ID的数据库来确保所有的ID都是同一个。这个工具可以自己写或者直接买。很多商用的关系型数据库都提供此类核对，它常常过于耦合，不能支持很好的伸缩性。

使用类似程度的成熟度来维护代码

微服务中所有代码都保持同样的类似程度的成熟度和稳定度。也就是说，你想要重写或给一个运行良好的已部署好的微服务添加一些代码的话，最好的方式常常 是对于新的或要改动的代码，新建一个微服务，现有的微服务丢着不管就行。 [编辑注：这种架构常常称之为immutable infrastructure principle.] 这样的话，你可以迭代式的部署和测试新代码，直至没有bug，性能足够好,现有的微服务不会出现故障或性能下降.一旦新的微服务和原始的服务一样稳定，如果确实需要进行功能合并的话，你可以将其合并在一起，或者处于性能的考虑合并它们。然而，就Cockcroft’s的经验来讲，常常是你发现你的服务太大而要进行拆分。

详细文档请关注我们微信号，回复“Netflix”，获取下载地址

6.Yelp

在你开始考虑设计服务之初，也就是动手写代码和设计之前，和团队成员、其他服务领域的专家聊一聊。除了如何与现有的特性、产品以及服务如何适配之外，考虑一下你想要额外添加的功能。考虑一种最合理的组织整体功能的方式。有时候添加新功能意味着要对现有组件进行重组。

我们希望避免那些简单的 “append-only”服务架构，也就是说development只存在于新的服务中

核实是否能够给现有服务添加新的功能

在编写新的服务之前，应该核实是否现有服务不包括你的功能。它可能会与现有的功能存在冲突，处理相同的信息，或者只是在现有服务功能范围内的演化。另一方面，如果给现有服务添加新的功能会让服务的使用者感到困惑的话，最好就不要添加新的功能了。

考虑你的功能是否更适合作为一个库

尽管这篇文档是讲服务的，但值得注意的是一些功能更适合做成库。为了帮助大家更好的决策，我们介绍了库与服务之间进行取舍的一些经验：

升级速度 对于库来讲更适合哪些用户期望很长时间才进行升级的场合(通常数周或数月，甚至于数年)。一般来说，这要求功能本身相对小且自包含，所以本身变更的可能就小。相反，如果你还正在进行开发，或者你希望能够快速推送一些bug修订给用户，这样的功能更适合作为一个服务。这样功能就回更复杂一些，常常需要依赖外部的一些库。

性能和可靠性 库与调用请求的寻址空间一样，而服务则处于不同的网络地址。假使其他东西都是一样的，访问一个库 要比服务更快更可靠。但是，如果功能对资源需求较高，比如CPU,内存和硬盘，那么作为一个服务能够让客户端的运行效率更高，能够使得服务所依赖的硬件独立于客户端的硬件而水平扩展。

详细文档请关注我们微信号，回复“Yelp”，获取下载地址

7.ThoughtWorks

随着公司国际化战略的推行以及本土业务的高速发展，后台支撑系统已经不堪重负。在吞吐量、稳定性以及可扩展性上都无法满足日益增长的业务需求。对于每10万元额度的合同，从销售团队准备材料、与客户签单、递交给合同部门，再到合同生效大概需要3.5人天。随着业务量的快速增长，签订合同的成本急剧增加。

合同管理系统是后台支撑系统中重要的一部分。当前的合同系统是5年前使用.NET基于SAGE CRM二次开发的产品。 一方面，系统架构过于陈旧，性能、可靠性无法满足现有的需求。另一方面，功能繁杂，结构混乱，定制的代码与SAGE CRM系统耦合度极高。由于是遗留系统，熟悉该代码的人早已离职多时，新团队对其望而却步，只能做些周边的修补工作。同时，还要承担着边补测试，边整理逻辑的工作。

在无法中断业务处理的情况下，为了解决当前面临的问题，团队制定了如下的策略：

1). 在现有合同管理系统的外围，构建功能服务接口，将系统核心的功能分离出来。
2). 利用这些功能服务接口作为代理，解耦原合同系统与其调用者之间的依赖；
3). 通过不断构建功能服务接口，逐渐将原有系统分解成多个独立的服务。
4). 摒弃原有的合同管理系统，使用全新构建的(微)服务接口替代。

随着团队对业务的理解加深和对微服务实践的尝试，数个微服务程序已经成功构建出来。不过，问题同时也出现了：对于这些不同的微服务程序而言，虽然具体实现的代码细节不同，但其结构、开发方式、持续集成环境、测试策略、部署机制以及监控和告警等，都有着类似的实现方式。那么如何满足DRY原则并消除浪费呢？带着这个问题，经过团队的努力，Stencil诞生了。 Stencil是一个帮助快速构建Ruby微服务应用的开发框架，主要包括四部分：Stencil模板、代码生成工具，持续集成模板以及一键部署工具。

Stencil模板

Stencil模板是一个独立的Ruby代码工程库，主要包括代码模板以及一组配置文件模板。

代码模板使用Webmachine作为Web框架，RESTful和JSON构建服务之间的通信方式，RSpec作为测试框架。同时，代码模板还定义了一组Rake任务，譬如运行测试，查看测试报告，将当前的微服务生成RPM包，使用Koji给RPM包打标签等。

除此之外，该模板也提供了一组通用的URL，帮助使用者查看微服务的当前版本、配置信息以及检测该微服务程序是否健康运行等。

详细文档请关注我们微信号，回复“ThoughtWorks”，获取下载地址

京东

京东资深架构师李鑫主要负责京东的服务框架， 他所分享的内容是对微服务底层的技术框架支持。

为何要微服务化？

1.系统规模随着业务的发展⽽而增长，原有系统架构模式中逻辑过于耦合，不再适应；
2.拆分后的⼦系统逻辑内聚，易于局部扩展；
3.⼦系统之间通过接⼝口来进⾏交互，接⼝契约不变的情况下可独⽴变化。

上图中，左边是几年前京东的架构，很多服务都是访问同样一个DB。这种架构的问题在于：流量来了以后全部压力都在DB上。而且在之前京东的架构里比较强调快速开发，很多逻辑比如说仓储配送服务都不存在，全都依靠BD来进行。这样可扩展性相当差，性能也不太可控。后来，我们根据业务模块和特性进行水平拆分，应用和应用之间都要通过接口进行交互，有同步和异步接口。

团队在2014年推出了新服务平台JSF，其框架示意图如下。

可以看出，服务注册和寻址没有太大变化，主要变化在于注册中心。采用团队自己写的服务，并提供了index服务数据库。相对来讲，询问注册中心地址，会进行一个服务的调用。因为这一块有自己内部的逻辑，没有办法实现，所以定期会发送性能统计数据。把RPC转化，生成负载均衡管理重试策略，然后经过序列化以后发送到server并解码，再进行实际的业务调用，然后进行一些过滤的逻辑。

详细文档请关注我们微信号，回复“京东”，获取下载地址

七牛

肖勤介绍重点介绍了七牛图片处理（FOP）场景的微服务应用。FOP服务早期的架构以它的每一个应用为后端。随着用户越来越多，流量越来越高，负载均衡逐渐出现了带宽和流量的压力。

七牛将图像处理服务拆成两个部分，分别负责处理文件的传输和图像本身的处理。从负载均衡过来的请求不再是完整的文件，而是文件的地址。这样，负载均衡和流量优化跟整个图像处理没有关系，可以做多带带的部署。而对于稍微复杂一些的请求（如图片格式和尺寸的变更，添加水印），就用管道的方式把不同的服务串联起来最终实现。

详细文档请关注我们微信号，回复“七牛”，获取下载地址

10 好雨云

微服务架构是好雨云基础组件，好雨云的很多功能都跑在它上，好雨微服务架构的第一个用户就是好雨云自身，在这个过程中我们也体会到微服务架构给我们带来的便捷。

好雨云的微服务包括：

控制台服务 —— python 实现
实时消息服务 —— java 实现
计费服务 —— python实现
统计服务 —— java实现
日志服务 —— c 实现
redis服务 —— dockerfile 构建
mysql服务 —— dockerfile构建

我们技术团队每个人擅长的开发语言不同，在微服务中也有体现，喜欢python的开发者用python开发微服务，喜欢java的开发者用java开发，适合用c的微服务用c开发，开源的服务直接用dockerfile构建。新来的开发人员不需要学习就可以开始开发。

好雨云微服务的开发过程全部在云平台上进行，本地没有设置开发和测试环境，我们为每一个微服务建立两个应用，一套是开发测试应用，另一套是生产应用，开发测试应用关联开发代码分支，依赖测试数据服务，生产应用关联代码主干，依赖生产数据服务，开发人员日常开发调试在开发测试应用进行，代码提交开发分支，点击部署，马上就能看见应用的效果，测试通过的应用，将代码合并到主干，点击生产应用的部署，完成上线过程，如果代码有重大bug，点击日志中的“代码回滚”就能迅速回滚到上一个代码版本。

除此之外服务高可用、服务伸缩、服务容错这些需求都交给好雨微服务架构组件去解决，通过这样的方法我们一天最多上线50多个版本，而过程中用户的服务没有异常中断。

控制台服务是用户使用量比较大的服务，为了优化性能，我们重度依赖应用实时性能分析，它可以分析出对性能影响最大的SQL和URL，优化完SQL和对应的程序，上线后立马就能看见效果。并根据效果继续优化。对服务的伸缩，我们依赖于实时业务监控，通过监测总体响应时间和吞吐率决定服务是扩容还是缩容。

通过好雨微服务架构来开发好雨云的特性， 我们践行了“吃自己的狗粮”，并持续优化着好雨微服务架构，做为第一个微服务架构的用户我们也从中受益，我们在环境问题、系统管理、性能优化、服务伸缩和代码发布上线上几乎没有浪费时间，让我们更加专注产品本身，快速迭代。

详细文档请关注我们微信号，回复“好雨云”，获取下载地址

更多精彩内容请扫描下方二维码轻松获取。