左耳朵耗子：从亚马逊的实践，谈分布式系统的难点

点击关注 InfoQ，置顶公众号

接收程序员的技术早餐

作者｜陈皓

编辑｜杨爽

本文摘自陈皓（左耳朵耗子）在极客时间 App/ 小程序上开始的全年付费专栏《左耳听风》，已获授权。更多分布式系统关键技术、性能调优攻略，请点击下图查看，新用户注册立减 30 元，支持微信支付 ▽

从目前可以得到的信息来看，对分布式服务化架构实践最早的应该是亚马逊。因为早在 2002 年的时候，亚马逊 CEO 杰夫·贝索斯（Jeff Bezos）就向全公司颁布了下面的这几条架构规定（来自《Steve Yegge 对 Google 平台吐槽》一文）。

1. 所有团队的程序模块都要通过 Service Interface 方式将其数据与功能开放出来。

2. 团队间程序模块的信息通信，都要通过这些接口。

3. 除此之外没有其它的通信方式。其他形式一概不允许：不能直接链结别的程序（把其他团队的程序当做动态链接库来链接），不能直接读取其他团队的数据库，不能使用共享内存模式，不能使用别人模块的后门，等等。唯一允许的通信方式是调用 Service Interface。

4. 任何技术都可以使用。比如：HTTP、CORBA、Pub/Sub、自定义的网络协议等。

5. 所有的 Service Interface，毫无例外，都必须从骨子里到表面上设计成能对外界开放的。也就是说，团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例外。

6. 不这样做的人会被炒鱿鱼。

这应该就是 AWS（Amazon Web Service）出现的基因吧。当然，前面说过，采用分布式系统架构后会出现很多的问题。比如：

• 一个线上故障的工单会在不同的服务和不同的团队中转过来转过去的。

• 每个团队都可能成为一个潜在的 DDoS 攻击者，除非每个服务都要做好配额和限流。

• 监控和查错变得更为复杂。除非有非常强大的监控手段。

• 服务发现和服务治理也变得非常复杂。

为了克服这些问题，亚马逊这么多年的实践让其可以运维和管理极其复杂的分布式服务架构。我觉得主要有以下几点。

1. 分布式服务的架构需要分布式的团队架构。在亚马逊，一个服务由一个小团队（Two Pizza T