左耳朵耗子：从亚马逊的理论，谈散布式系统的难点

作者｜陈皓

编辑｜杨爽

本文摘自陈皓（左耳朵耗子）在极客时间 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 Team 不超越 16 个人，两张 Pizza 能够喂饱的团队）担任，从前端担任到数据，从需求剖析担任到上线运维。这是良性的分工战略——按职责分工，而不是按技艺分工。
2. 散布式效劳查错不容易。一旦呈现比较严重的毛病，需求整体查错。呈现一个 S2 的毛病，就能够看到每个团队的人都会上线。在工单系统里能看到，在毛病发作的一开端，大家都在签到并自查自己的系统。假如没问题，也要在线待命（standby），等问题处置。（我在《毛病处置最佳理论：应对毛病》一文中细致地讲过这个事）。
3. 没有专职的测试人员，也没有专职的运维人员，开发人员做一切的事情。开发人员做一切事情的益处是——吃自己的狗粮（Eat Your Own Dog Food） 最微观的理论。自己写的代码自己维护自己养，会让开发人员明白，写代码容易维护代码复杂。这样，开发人员在接需求、做设计、写代码、做工具时都会思索到软件的长期维护性。
4. 运维优先，崇尚简化和自动化。为了能够运维如此复杂的系统，亚马逊内部在运维上下了十分大的功夫。往常人们所说的 DevOps 这个事，亚马逊在 10 多年前就做到了。亚马逊最为强大的就是运维，拼命地对系统进行简化和自动化，让亚马逊做到了能够轻松运维具有上千万台虚机的 AWS 云平台。
5. 内部效劳和外部效劳分歧。无论是从保险方面，还是接口设计方面，无论是从运维方面，还是毛病处置的流程方面，亚马逊的内部系统都和外部系统一样看待。这样做的益处是，内部系统的效劳随时都能够开放出来。而且，从第一天开端，效劳提供方就有对外效劳的才干。能够想像，以这样的规范运作的团队其才干会是什么样的。

在进化的过程中，亚马逊遇到的问题很多，以至还有很多简直没有人会想到的十分生僻的东西，它都逐一学习和总结了，而且都处置得很好。

构建散布式系统十分难，充溢了各种各样的问题，但亚马逊还是毫不犹疑地走了下去。这是由于亚马逊想做平台，不是“像淘宝这样的中介式流量平台”，而是那种“能够对外输出才干的平台”。

亚马逊觉得自己没有像史蒂夫·乔布斯（Steve Jobs）这样的牛人，不可能做出像 iPhone 这样的爆款产品，而且用户天生就是众口难调，与其做一个大家都不称心的软件，还不如把一些基础才干对外输出，引入外部的力气来一同完成一个用户称心的产品。这其实就是在树立自己的生态圈。固然在今天看来这个事曾经不稀奇了，但是贝索斯早在十五年前就悟到了，真实是个天才。

所以，散布式效劳架构是需求从组织，到软件工程，再到技术上的一个大的改造，需求比较长的时间来磨合和改进，并不时地总结经验和胜利经验。

散布式系统中需求留意的问题

我们再来看一下散布式系统在技术上需求留意的问题。

问题一：异构系统的不规范问题

这主要表往常：

• 软件和应用不规范。
• 通讯协议不规范。
• 数据格式不规范。
• 开发和运维的过程和措施不规范。

不同的软件，不同的言语会呈现不同的兼容性和不同的开发、测试、运维规范。不同的规范会让我们用不同的方式来开发和运维，惹起架构复杂度的提升。好比：有的软件修正配置要改它的.conf 文件，而有的则是调用管理 API 接口。

在通讯方面，不同的软件用不同的协议，就算是相同的网络协议里也会呈现不同的数据格式。还有，不同的团队由于用不同的技术，会有不同的开发和运维方式。这些不同的东西，会让我们的整个散布式系统架构变得异常复杂。所以，散布式系统架构需求有相应的规范。

好比，我看到，很多效劳的 API 出错不返回 HTTP 的错误状态码，而是返回个正常的状态码 200，然后在 HTTP Body 里的 JSON 字符串中写着个：error，bla bla error message。这简直就是一种反人类的做法。我真实不明白为什么会有众多这样的设计。这让监控怎样做啊？往常，你应该运用 Swagger 的规范了。

再好比，我看到很多公司的软件配置管理里就是一个 key-value 的东西，这样的东西灵活到能够很容易地被滥用。不规范的配置命名，不规范的值，以至在配置中直接嵌入前端展示内容……

一个好的配置管理，应该分红三层：底层和操作系统相关，中间层和中间件相关，最上面和业务应用相关。于是底层和中间层是不能让用户灵活修正的，而是只让用户选择。好比：操作系统的相关配置应该构成模板来让人选择，而不是让人乱配置的。只需配置系统构成了规范，我们才 hold 得住众多的系统。

再好比：数据通讯协议。通常来说，作为一个协议，一定要有协议头和协议体。协议头定义了最基本的协议数据，而协议体才是真正的业务数据。关于协议头，我们需求十分规范地让每一个运用这个协议的团队都运用一套规范的方式来定义，这样我们才容易对央求进行监控、调度和管理。

这样的规范还有很多，我在这就不逐一罗列了。

问题二：系统架构中的效劳依赖性问题

关于传统的单体应用，一台机器挂了，整个软件就挂掉了。但是你千万不要以为在散布式的架构下不会发作这样的事。散布式架构下，效劳是会有依赖的，于是一个效劳依赖链上，某个效劳挂掉了，会招致呈现“多米诺骨牌”效应，会倒一片。

所以，在散布式系统中，效劳的依赖也会带来一些问题。

• 假如非关键业务被关键业务所依赖，会招致非关键业务变成一个关键业务。
• 效劳依赖链中，呈现“木桶短板效应”——整个 SLA 由最差的那个效劳所决议。

这是效劳管理的内容了。效劳管理岂但需求我们定义出效劳的关键水平，还需求我们定义或是描画出关键业务或效劳调用的主要途径。没有这个事情，我们将无法运维或是管理整个系统。

这里需求留意的是，很多散布式架构在应用层上做到了业务隔离，但是，在数据库结点上并没有。假如一个非关键业务把数据库拖死，那么会招致全站不可用。所以，数据库方面也需求做相应的隔离。也就是说，最好一个业务线用一套自己的数据库。这就是亚马逊效劳器的理论——系统间不能读取对方的数据库，只经过效劳接口耦合。这也是微效劳的请求。我们岂但要拆分效劳，还要为每个效劳拆分相应的数据库。

问题三：毛病发作的概率更大

在散布式系统中，由于运用的机器和效劳会十分多，所以，毛病发作的频率会比传统的单体应用更大。只不外，单体应用的毛病影响面很大，而散布式系统中，固然毛病的影响面能够被隔离，但是由于机器和效劳多，出毛病的频率也会多。另一方面，由于管理复杂，而且没人知道整个架构中有什么，所以十分容易犯错误。

你会发现，对散布式系统架构的运维，简直就是一场噩梦。我们会慢慢地明白下面这些道理。

• 呈现毛病不可怕，毛病恢复时间过长才可怕。
• 呈现毛病不可怕，毛病影响面过大才可怕。

运维团队在散布式系统下会十分忙，忙到每时每刻都要处置大大小小的毛病。我看到，很多大公司，都在自己的系统里拼命地添加各种监控指标，有的能够添加出几万个监控指标。我觉得这完整是在“使蛮力”。一方面，信息太多等于没有信息，另一方面，SLA 请求我们定义出“Key Metrics”，也就是所谓的关键指标。但是，他们却没有。这其实是一种思想上的懒散。

但是，上述的都是在“救火阶段”而不是“防火阶段”。所谓“防火胜于救火”，我们还要思索如何防火，这需求我们在设计或运维系统时都要为这些毛病思索，即所谓 Design for Failure。在设计时就要思索如何减轻毛病。假如无法避免，也要运用自动化的方式恢复毛病，减少毛病影响面。

由于当机器和效劳数量越来越多时，你会发现，人类的缺陷就成为了瓶颈。这个缺陷就是人类无法对复杂的事情做到事无巨细的管理，只需机器自动化才干辅佐人类。 也就是，人管代码，代码管机器，人不论机器！

问题四：多层架构的运维复杂度更大

通常来说，我们能够把系统分红四层：基础层、平台层、应用层和接入层。

• 基础层就是我们的机器、网络和存储设备等。
• 平台层就是我们的中间件层，Tomcat、MySQL、Redis、Kafka 之类的软件。
• 应用层就是我们的业务软件，好比，各种功用的效劳。
• 接入层就是接入用户央求的网关、负载均衡或是 CDN、DNS 这样的东西。

关于这四层，我们需求知道：

• 任何一层的问题都会招致整体的问题；
• 没有统一的视图和管理，招致运维被割裂开来，构成更大的复杂度。

很多公司都是按技艺分工是，把技术团队分为产品开发、中间件开发、业务运维、系统运维等子团队。这样的分工招致各管一摊，很多事情完整连不在一同。整个系统会像 “多米诺骨牌”一样，一个环节呈现问题，就会倒下去一大片。由于没有一个统一的运维视图，不知道一个效劳调用是如何经过每一个效劳和资源，也就招致我们在呈现毛病时要花大量的时间在沟通和定位问题上。

之前我在某云平台的一次阅历就是这样的。从接入层到负载均衡，再到效劳层，再到操作系统底层，设置的 KeepAlive 的参数完整不分歧，招致用户发现，软件运转的行为和文档中定义的完整不一样。工程师查错的过程简直就是一场恶梦，以为找到了一个，结果还有一个，来来回回花了大量的时间才把一切 KeepAlive 的参数设置成分歧的，糜费了太多的时间。

分工不是问题，问题是分工后的协作能否统一和规范。这点，你一定要注重。

小 结

好了，我们来总结一下今天赋享的主要内容。首先，我以亚马逊为例，讲述了它是如何做散布式效劳架构的，遇到了哪些问题，以及是如何处置的。我以为，亚马逊在散布式效劳系统方面的这些理论和经验积聚，是 AWS 呈现的基因。随后分享了在散布式系统中需求留意的几个问题，同时给出了应对计划。

我以为，构建散布式效劳需求从组织，到软件工程，再到技术上的一次大的改造，需求比较长的时间来磨合和改进，并不时地总结经验和胜利经验。

专栏目录

下面是《左耳听风》的部分目录，呈现你面前的每一篇文章，都是左耳朵耗子仅在小范围分享的独家经验，20 年大范围系统架构和开发经验总结：

本专栏自 2017 年 10 月更新以来，已有 6000+ 学员参与学习，更有专属学员群 + 答疑时间，让你和左耳朵耗子沟通交流。

用户福利

即日起，

福利一：原价199/ 年，极客时间新用户注册立减30

福利二：每约请一位好友置办，你可取得 36 元现金返现，多邀多得，上不封顶，立刻提现（提现流程：极客时间效劳号 - 我的 - 现金奖励提现）

如何订阅