写点什么

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

  • 2018-03-28
  • 本文字数:1980 字

    阅读完需:约 6 分钟

本文摘自陈皓(左耳朵耗子)在极客时间 App/ 小程序上开始的全年付费专栏《左耳听风》,已获授权。更多分布式系统关键技术、性能调优攻略,点击此处订阅专栏阅读(支持微信支付),全年订阅199 元,新用户立减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 这样的爆款产品,而且用户天生就是众口难调,与其做一个大家都不满意的软件,还不如把一些基础能力对外输出,引入外部的力量来一起完成一个用户满意的产品。这其实就是在建立自己的生态圈。虽然在今天看来这个事已经不稀奇了,但是贝索斯早在十五年前就悟到了,实在是个天才。

所以,分布式服务架构是需要从组织,到软件工程,再到技术上的一个大的改造,需要比较长的时间来磨合和改进,并不断地总结教训和成功经验。

分布式系统中需要注意的问题

我们再来看一下分布式系统在技术上需要注意的问题。

注:以上仅为文章的一部分,欲阅读全文,请点击此处订阅专栏(支持微信支付)。一次订阅,永久阅读,现在订阅,立享福利:

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

福利二:每邀请一位好友购买,你可获得 36 元现金返现,多邀多得,上不封顶,立即提现(提现流程:极客时间服务号 - 我的 - 现金奖励提现)

2018-03-28 18:303466

评论

发布
暂无评论
发现更多内容

为什么数字化转型就应该选择低代码?一文详解

加入高科技仿生人

低代码 数字化转型

Zilliz @ GOTC:大模型的记忆体——向量数据库的现在与未来

Zilliz

Milvus AIGC 向量数据库 zillizcloud cvpstack

【LLM for SE】顶会ICSE-2023发布LIBRO技术,利用大模型技术进行缺陷重现,自动重现率(33%)实现业界突破

云计算 华为云

WePY小程序框架如何使用

Onegun

小程序 小程序框架

企业号 6 月 PK 榜,火热开启!

InfoQ写作社区官方

热门活动 企业号 6 月 PK 榜

玩转服务器之网站篇:新手使用WordPress搭建博客和静态网站部署

京东科技开发者

Wordpress 部署 服务器 WordPress 企业号 5 月 PK 榜 静态网站部署

低代码+MOM:释放制造业数字化魅力

力软低代码开发平台

对线面试官-线程池(一)

派大星

面试

独立游戏开发:掌握成功的五大关键技巧

龙智—DevSecOps解决方案

游戏开发 独立游戏 独立游戏开发

APP出海的现状与挑战​

MobTech袤博科技

财务共享案例分享!大型企业财务先锋交流财务数智化转型的关键举措

用友BIP

财务共享

财务共享经验分享!权威教授解读企业走向财务数智化的关键路径

用友BIP

财务共享

是 CI 也是阿拉伯飞毯——腾讯云 CODING CI 3.0 云原生构建

CODING DevOps

云原生 持续集成 CODING DevOps

软件测试/测试开发丨学习笔记之App自动化用例录制、结构分析

测试人

程序员 软件测试 自动化测试 测试开发 appium

生态共建丨崖山数据库系统与杉岩分布式存储系统完成兼容互认证

YashanDB

数据库

当 Serverless 遇上 AI,锁定年度最佳 CP,这场论坛满足你的好奇心

阿里巴巴云原生

阿里云 Serverless 云原生

理论+实操|一文掌握 RFM 模型在客户数据洞察平台内的落地实战

袋鼠云数栈

大数据 RFM模型 标签体系 RFM

数据可视化:地图类可视化图表大全

2D3D前端可视化开发

大数据 数据分析 数字化转型 数据可视化 数据可视化工具

Server版支持即将到期,Jira和Confluence如何迁移?(2)

龙智—DevSecOps解决方案

云原生 迁移 云 原生云 CTO 迁移上云 迁移计划

生态共建丨YashanDB与金蝶软件完成兼容互认证

YashanDB

数据库

崖山数据库系统YCA认证,首发期限时免费!

YashanDB

数据库

OIDC & OAuth2.0 认证协议最佳实践系列 02 - 授权码模式(Authorization Code)接入 Authing

Authing

低代码 OAuth 2.0 OIDC Authing

人脸识别图像技术的原理及其应用

数据堂

靠AI自动生成视频撸自媒体收益,月入5000+

派大星

ChatGPT4

7 步提升私有化部署的极狐GitLab 实例安全等级

极狐GitLab

DevOps 安全 SSH DevSecOps 密钥

极氪汽车 APP 系统云原生架构转型实践

阿里巴巴云原生

阿里云 云原生 合作

欧伟杰:乘“20+8”政策之东风,促进深圳空间数据向好发展

YashanDB

数据库

全面预算管理可以从科技发展中得到什么?

智达方通

全面预算管理 信息孤岛

嘉为蓝鲸荣登广东软件风云榜,获评新技术应用最受欢迎产品TOP10

嘉为蓝鲸

软件 新技术 应用程序

探索 Web 管理之路,OpenYurt 社区 UI/CLI SIG 正式启动

阿里巴巴云原生

阿里云 开源 云原生 openyurt

C4D必备的7个素材网站,很多爆款素材!

Finovy Cloud

C4D

左耳朵耗子:从亚马逊的实践,谈分布式系统的难点_语言 & 开发_陈皓_InfoQ精选文章