互联网巨头亚马逊公司微服务化经验

大数据官方网站重磅推出——大型互联网公司的微服务化经验谈系列文章

大数据官网|伊可萤 译

“If you have a new business idea or problem you want to solve you form a team. Limit the team to 8-10 people because communication hard. They are called two pizza teams. The number of people you can feed off two pizzas”

亚马逊

这是一篇惊人且信息量很大的关于亚马逊公司的文章，该文章来自于Joachim罗德对亚马逊CEO一次采访中的所见所闻所感。您将了解亚马逊如何围绕服务化来组织他们的团队，了解构建可扩展系统的上限定理,了解他们如何部署软件以及更多内容。

亚马逊从一个很小的网上书店成长为地球上最大的在线商店之一。Greg Linden在一系列博客文章中分享了亚马逊成长过程中经历的种种痛苦。任何一个大型的互联网公司几乎都会经历风雨飘摇、死而后已的过程，这在当今的中国市场形势下更是如此，能够避开BAT阻击并发展壮大自己公司的人都算是英雄，可萤向来如此认为。

亚马逊平台技术

• Linux
• Oracle
• C++
• Perl
• Mason
• Java
• Jboss
• Servlets

亚马逊平台统计

• 超过5500万个活跃客户账户。
• 全球超过100万个活跃零售合作伙伴。
• 构建一个页面可能需要访问100 - 150个服务才能完成。

 

亚马逊平台架构

我们提到的可伸缩性究竟是什么意思呢?当我们增加或减少系统资源时,系统性能的提高或降低是与资源的增加或减少成正比的，这样可以称为该服务是具备可伸缩的。提高性能一般来说意味着要服务更多的工作单元（也即使用服务的应用）,但它也可以处理更大的工作单元,例如可以处理日益增长的数据量。

亚马逊做出这么大的架构变化,实际上是把一个两层的庞然大物（传统架构，传统架构一般包含应用层和数据库，应用层集合了所有的业务逻辑，十分臃肿）变成一个完全分布式的、去中心化的并且可服务于许多不同应用的服务化平台。

起初，当一个应用程序要与后端交互，是用c++写的。

随着亚马逊慢慢发展。多年来,亚马逊所做的可伸缩性的努力主要集中在做后端数据库的可伸缩性上，以使数据库可以存储更多项目信息、更多的顾客信息、更多的订单信息、并支持多样的国际站点。2001年,前端应用程序不能做可伸缩改造已经非常明朗清晰了。数据库的可伸缩性改造是将数据库被分为多个小的组成部分,将一个大而全的数据库分成多个小数据库，应用只有通过调用统一封装的数据库访问接口这一种途径才能访问数据库。

数据库成为一个共享资源,这导致很难扩展整个业务。在数据库改动时前端和后端的处理被限制,因为数据库被许多不同的团队和进程共享。

他们的架构是松耦合的并且是围绕服务构建。面向服务的框架给了他们允许快速且独立的构建许多软件组件的隔离性。

发展成为数以百计的服务和若干聚合来自服务提供的信息的应用程序服务器。呈现Amazon.com Web页面的应用程序就是这样的一个应用程序服务器，提供webservice接口、客户服务应用程序以及卖方接口的也是这样一些应用程序服务器。

许多第三方技术很难适合亚马逊这么庞大的系统。特别是通信基础设施的技术。他们在一定规模下工作的很好然后规模再增大就会失败。所以他们不得不开创自己的技术，为自己创造适合自己的技术。这一点与我们国家的阿里巴巴很像，阿里随着自己业务量的增长开创了许多非常优秀的技术，比如TDDL、Dubbo、Tair、TFS等等。

亚马逊并不被迫接受一个特定的方法。一些地方他们也使用java技术,但是他们只使用servlet、没有用到其他的J2EE技术。

c++是用来处理请求。Perl /Mason是用于构建内容。

亚马逊不喜欢中间件,因为它往往是框架,而不是工具。如果你使用一个中间件，那么你很容易会被禁锢在你所选择的软件模式里面。你只能够使用他们的软件。所以,如果你想使用不同的中间件产品，你可能就会被限制住，陷入消息传递、数据持久化的问题循环中不能自拔。

AJAX等。太复杂。如果中间件在更小的组件可用,更多的是一种工具而不是一个框架,他们会更感兴趣。由此可见，大公司在技术选型上别有一番道理在里面，值得我们深思。

SOAP web相关技术似乎想解决所有的分布式系统问题。

提供SOAP和REST两种方式的webservice接口。30%使用SOAP。这些往往是Java和.Net用户，他们使用WSDL文件来生成远程对象的接口。70%的人使用REST接口，这些往往是PHP或PERL用户。

亚马逊想建立一个围绕他们服务的开放社区。他们选择了Web services,因为它很简单。但这只是与第三方系统的边界或者说访问亚马逊服务的入口。亚马逊系统内部是一个面向服务的体系结构。只能通过接口访问数据。这些接口在WSDL文件中进行描述,但是他们用自己的封装和传输机制。

团队小,并且围绕服务来组织建立
1）在亚马逊内部服务是提供功能的独立单元。这也是亚马逊如何在内部组织团队的方式。
2）如果你有一个新的业务想法或存在你想解决的问题，你组织一个团队。尽量限制在8 - 10人的这样一个团队，因为沟通成本很高且沟通困难。这被称为两个披萨的团队。你刚好可以用两个披萨喂饱这些人。说到这里，这有些像当今的敏捷开发，同样也是小团队，团队里面的成员多半是全栈工程师，版本迭代效率非常快，这种开发方式在当今被华为或者阿里借用。
3）团队很小。他们被分配权限和授权解决开发服务过程中遇到的问题。
4）举个例子,他们创建了一个团队，在一本具有独特文本的书中找短语。这个团队对于这种特性建立了一组分离的服务接口并且他们有权做他们需要的事。
5）大量的A / B测试（啥是A/B测试，不懂的同学百度脑补去吧）是用于集成一个新的服务。他们看到影响是什么和采取大量测试。

部署
1）他们为管理依赖创造特殊的基础设施以便于做部署工作。
2）目标是所有合适的服务部署在一个盒子里。所有应用程序代码、监控、许可证等应该在一个盒子里。
3）部署过程的输出是一个虚拟机。你可以使用EC2来运行它们。
源自客户的逆向工作来验证一个新的服务是值得做的
1）来自客户的逆向工作。专注于你想要为客户提供的价值。
2）迫使开发人员专注于交付给客户的价值,而不是专注于建设技术和研究如何使用它。
3）最后一个，设计尽可能最小。简单是关键,如果你真的想建立大型分布式系统。正所谓大道至简吧。
状态管理是大规模系统的核心问题
1）内部他们可以提供无限的存储空间。
2）许多操作是有状态的，当然不是所有。付款步骤是有状态的。
3）最近点击的网页服务是基于session id的。
4）他们跟踪一切（如服务调用链），这不是保持状态的问题。几乎是没有独立的需要保存一个会话的状态,。所以你只使用服务这些服务就已经保存了相关信息。

Eric Brewer的上限定理或系统的三个属性
1）系统的三个属性:一致性、可用性、容忍网络分区。
2）对于任何数据共享系统，你最多有这三个属性中的两个。
3）可分割性:将节点分为小组,可以看到其他团体,但他们不能看到每一个人。
4）一致性:写一个值,然后你再读这个值，你拿回相同的值。在分布式系统中会有数据不一致的时间窗口，这很难避免。
5）可用性:可能并不总是能够写或阅读。系统会说你不能写,因为它希望保持系统一致。
6）要扩展你必须分区,所以对于一个特定的系统你只剩下选择高一致性或高可用性。你必须找到可用性和一致性合适的搭配。
7）基于需求的服务选择一个特定的方法。
8）对于结帐过程，你总是要光荣的请求将物品添加到购物车,因为这会有收入产生。在这种情况下,你选择高可用性。在客户那里错误会被隐藏并后续解决。
9）当客户提交一个订单，你关切一致性,因为有好几个服务——信用卡处理、运输和处理、报告等同时访问数据库。

“Only way to manage as large distributed system is to keep things as simple as possible.”

经验教训
      你必须改变你的思维构建可伸缩系统。在传统的系统里我们呈现了一个完美的世界,没有宕机而且我们在这个完美的世界里构建了复杂的算法(技术协议)。相反,这个系统却理所当然的失败了,但这是现实,接受它吧。例如,去更多的快速启动和快速恢复的方法。一个像样的数据和服务的推广，你多半可能会创建自修复、自组织等着一些的运维策略。
创建一个共享基础设施。基础设施可以成为开发和部署的共享资源，在你的逻辑和数据层也同样作为共享资源，这其实是有缺陷。它可能导致锁定、阻塞和死锁。

用API开发你的系统,你将创建一个围绕在你应用系统周边的生态系统。

管理大型的分布式系统的唯一方法就是让一切尽可能保持简单。尽量保持简单的解决方式之前要确保没有隐藏的需求和隐藏的依赖关系的设计。技术尽量少用，解决了你的问题或需求即可。

以服务化的思维来组织工作会给予我们更多的敏捷和灵活性。你可以并行的做一些事情，因为输出的是一个服务。这将容许将产品更快的投放市场。创建一套允许服务快速构建的底层基础设施。

在落地之前就进行大肆宣传、炒作势必会带来一些问题。

在公司内部使用SLAs管理服务

每个人都可以快速的往他们产品中添加web services，只是实现你的产品作为服务的一部分,并开始使用它。

为性能、可靠性以及控制成本来构建你自己的基础设施，通过建设自己的平台你永远不需要说你失败了,因为它是X公司的错。您的软件可能不会比其他人更可靠,但是你可以修复、调试并且部署比与使用第三方更快。

创建一个节俭的文化。例如,亚马逊门用于办公桌。

创建一个测试站点，在版本发布之前需要得到充分测试。

如果要给更新不生效或者失败要有一套回滚策略。

在采访中寻找三件事:热情,创造力,能力。Amazon.com的成功更多的来自于热情。

创新只能来自于底层。最接近问题的这些人才有这个机会去解决它们。任何依赖创新的组织势必要拥抱混沌，忠诚和服从不是你的工具。

每个人都必须能够实验、学习和迭代。位置、服从和传统不应持有权利。为创新可以蓬勃发展开来，测评要有一定的规则。

在数据中心中,只有30%的员工时间价值创造相关的基础设施问题,剩下的70%用于处理“繁重”的硬件采购、软件管理、负载平衡、维护、可伸缩性挑战等等。

禁止通过客户端直接访问数据库，不涉及客户端意味着会让服务扩展更加可靠。

创建一个单独的、统一的服务访问机制。这允许易聚合的服务,分散的请求路由、分布式请求跟踪,和其他先进的基础设施技术。

倾听客户的声音,客户服务统计数据可能会提供给你做错了什么的早期信号, ,或者会告诉你什么才是客户的痛点。

原文章地址：http://www.datacoder.cn/microservices/324