时隔16年Jeff Barr重返10.23-25 QCon上海站,带你看透AI如何重塑软件开发! 了解详情
写点什么

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

  • 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:303530

评论

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

10个经典场景带你玩转SQL优化,Java笔试题算法题

Java 程序员 后端

2020年Java篇:蚂蚁金服、拼多多、字节跳动的面试总结,mysqlserver使用教程

Java 程序员 后端

2020年春招复盘:技术三面+HR面,成功斩获京东offer,springboot项目实战源码

Java 程序员 后端

10万字Spring Boot详细学习笔记+源码免费开放下载,京东T7大牛纯手写出来的!

Java 程序员 后端

2021 年最新版 68道Redis面试题,20000字,赶紧收藏起来备用,成功入职阿里

Java 程序员 后端

2021年10月最新版Java面试真题+视频解析(价值24980赶紧收藏码住!

Java 程序员 后端

代码覆盖率VS测试覆盖率

FunTester

测试 测试覆盖率 覆盖率 FunTester 代码覆盖率

免费试用的堡垒机哪里有?哪家好?咨询电话多少?

行云管家

网络安全 数据安全 等级保护 IT运维

名震GitHub,字节跳动内部顶级数据结构刷题学习笔记根本停不下来

Java 程序员 数据结构 面试 字节

1024 的那天,我这个三线的程序员是这样度过的,阿里巴巴高级java工程师薪酬

Java 程序员 后端

大开眼界,终于有人将Spring技术精髓收录成册,已在Github上获赞百万

Java spring 编程 程序员 SpringCloud

15W字!腾讯总监手写“Netty速成手册”(1),SpringBoot项目瘦身指南

Java 程序员 后端

1小时破千万点击量!阿里巴巴首发:Java实践指南,mysql使用教程图解目录

Java 程序员 后端

2021年最新基于Spring Cloud的微服务架构分析,java技术经理岗位职责

Java 程序员 后端

10个 解放双手的 IDEA 插件,少些冤枉代码,java程序员进阶路线

Java 程序员 后端

10分钟手把手教你快速入门SpringBoot!,字节跳动java研发面试题社招

Java 程序员 后端

1万字长文高速你千万级并发架构下如何提高数据库存储性能,使用指南

Java 程序员 后端

迎接10亿快递高峰,看百度OCR如何助力物流企业提速

百度大脑

人工智能 OCR

2021BATJ面试题大全500道:Redis+数据库+分布式,java面试简历百度云

Java 程序员 后端

2021年五面蚂蚁、三面拼多多、字节跳动最终拿offer入职拼多多,我是如何收割多家大厂offer的

Java 程序员 后端

进击的Java(四)

ES_her0

11月日更

license是什么意思?谁能解释一下?

行云管家

云计算 LICENSE IT运维

15 高可用网站的软件质量保证,java技术基础知识总结

Java 程序员 后端

2020-6次面试阿里,持续一个多月,终于拿到offer了!,java三层架构登录功能实现

Java 程序员 后端

2020淘宝双十一快速刷金币工具,这份字节跳动历年校招Java面试真题解析

Java 程序员 后端

2021字节总监最新发布:JVM +GC优质手册!面试专属,mongodb集群搭建原理

Java 程序员 后端

15W字!腾讯总监手写“Netty速成手册”,mysql索引优化面试题

Java 程序员 后端

2020百度、小米、乐视、美团,小米java面试几轮

Java 程序员 后端

100道 IT名企前端面试真题,java教程pdf百度网盘

Java 程序员 后端

从OA到COP,致远互联成引领行业的“灯塔”

海比研究院

致远互联 COP 协同运营平台

2021年总结阿里、腾讯、百度等大厂11个Redis系列高频面试题,哪些你还不会

Java 程序员 后端

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