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

自去年以来，微服务受到了前所未有的关注，众多的互联网巨头开始实施微服务架构并取得了不错的反响，话不多说，今天我们就为大家盘点一下谷歌、亚马逊等十大科技公司的微服务实践案例。 1. 谷歌 拥有多元化微服务的大规模生态系统运行情况如何呢？ eBay和Google采用了数百到数千个单独的服务来协同工作； 现在的大规模系统都是以图的形式，而不是层次式或多个连接的形式来构成服务； 服务之间相互依赖； 只有旧的大规模系统采用高度集成的方式进行组织……

关注好雨微信服务号，回复“谷歌”，获取下载地址 2. 亚马逊

Amazon DevOps部门业务开发经理Munns列举了微服务4条使用限制： 1）单一目的 2）仅通过API进行连接 3）通过HTTPS协议进行连接 4）微服务之间大体以黑盒的方式展现…… 关注好雨微信服务号，回复“亚马逊”，获取下载地址 3. Twitter 目前能够以规模化方式运行微服务，从而解决实际问题的企业数量仍然相当有限。Twitter就是其中的典型代表，尽管其也经历过公共服务中断，但Twitter中包含上百种服务、数以万计的节点以及每项服务中的数百万RPS，是世界上规模最大的微服务应用之一…… 关注好雨微信服务号，回复“Twitter”，获取下载地址 4. SoundCloud 很多的技术文章着重介绍的都是项目后总结出的最佳实践，SoundCloud从另外的角度，介绍项目中解决问题的整个探索过程，详细讲述了在最终使用微服务架构之前所做的种种分析和尝试，这对于正在尝试解决问题的技术人员来说有很大的启示作用…… 关注好雨微信服务号，回复“SoundCloud”，获取下载地址 5. Netflix 想要重写或给一个运行良好的已部署好的微服务添加一些代码的话，最好的方式常常是对于新的或要改动的代码，新建一个微服务。然而，就Netflix的经验来讲，情况常常是发现服务太大而要进行拆分……

关注好雨微信服务号，回复“Netflix”，获取下载地址 6. Yelp 在你开始考虑设计服务之初和团队成员、其他服务领域的专家聊一聊；

除了如何与现有的特性、产品以及服务如何适配之外，考虑一下你想要额外添加的功能；

考虑一种最合理的组织整体功能的方式；

有时候添加新功能意味着要对现有组件进行重组……

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

关注好雨微信服务号，回复“ThoughtWorks”，获取下载地址 8. 京东 为何要微服务化？ 1.系统规模随着业务的发展⽽而增长，原有系统架构模式中逻辑过于耦合，不再适应； 2.拆分后的⼦系统逻辑内聚，易于局部扩展； 3.⼦系统之间通过接⼝口来进⾏交互，接⼝契约不变的情况下可独⽴变化…… 关注好雨微信服务号，回复“京东”，获取下载地址 9. 七牛 七牛将图像处理服务拆成两个部分，分别负责处理文件的传输和图像本身的处理。从负载均衡过来的请求不再是完整的文件，而是文件的地址。这样一来，负载均衡和流量优化跟整个图像处理没有关系，可以做单独的部署。而对于稍微复杂一些的请求（如图片格式和尺寸的变更，添加水印），就用管道的方式把不同的服务串联起来最终实现…… 关注好雨微信服务号，回复“七牛”，获取下载地址 10. 好雨 微服务架构是好雨基础组件，好雨云帮的很多功能都跑在它上，好雨微服务架构的第一个用户就是好雨云帮自身，在这个过程中我们也体会到微服务架构给我们带来的便捷。 好雨云帮的微服务包括： 控制台服务 —— python 实现 实时消息服务 —— java 实现 计费服务 —— python实现 统计服务 —— java实现 日志服务 —— c 实现 redis服务 —— dockerfile 构建 mysql服务 —— dockerfile构建 我们技术团队每个人擅长的开发语言不同，在微服务中也有体现，喜欢python的开发者用python开发微服务，喜欢java的开发者用java开发，适合用c的微服务用c开发，开源的服务直接用dockerfile构建。新来的开发人员不需要学习就可以开始开发。 好雨云帮微服务的开发过程全部在云平台上进行，本地没有设置开发和测试环境，我们为每一个微服务建立两个应用，一套是开发测试应用，另一套是生产应用，开发测试应用关联开发代码分支，依赖测试数据服务，生产应用关联代码主干，依赖生产数据服务，开发人员日常开发调试在开发测试应用进行，代码提交开发分支，点击部署，马上就能看见应用的效果，测试通过的应用，将代码合并到主干，点击生产应用的部署，完成上线过程，如果代码有重大bug，点击日志中的“代码回滚”就能迅速回滚到上一个代码版本。 除此之外服务高可用、服务伸缩、服务容错这些需求都交给好雨微服务架构组件去解决，通过这样的方法我们一天最多上线50多个版本，而过程中用户的服务没有异常中断。 控制台服务是用户使用量比较大的服务，为了优化性能，我们重度依赖应用实时性能分析，它可以分析出对性能影响最大的SQL和URL，优化完SQL和对应的程序，上线后立马就能看见效果。并根据效果继续优化。对服务的伸缩，我们依赖于实时业务监控，通过监测总体响应时间和吞吐率决定服务是扩容还是缩容。 通过好雨微服务架构来开发好雨云帮的特性，我们践行了“吃自己的狗粮”，并持续优化着好雨微服务架构，做为第一个微服务架构的用户我们也从中受益，我们在环境问题、系统管理、性能优化、服务伸缩和代码发布上线上几乎没有浪费时间，让我们更加专注产品本身，快速迭代……