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

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

1. 谷歌

随着多元化微服务的流行，愈来愈多的服务开始采用微服务来构建。近日，曾在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. 京东

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

为什么要微服务化？

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

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

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

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

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

1. 七牛

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

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

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

10 好雨云

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

好雨云的微服务包括：

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

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

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

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

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

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

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

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