【ArchSummit】如何通过AIOps推动可量化的业务价值增长和效率提升?>>> 了解详情
写点什么

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

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

评论

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

mybatis常用注解(绝对经典)

Java 程序员 后端

MyBatis常用标签和注解(绝对经典)

Java 程序员 后端

K8S环境的Jenkin性能问题处理续篇(任务Pod设置)

Java 程序员 后端

Linux常用命令(面试题)

Java 程序员 后端

Linux系统:第四章:Linux文件系统

Java 程序员 后端

MyBatis 框架系列之基础初识

Java 程序员 后端

Mybatis如何执行Select语句,你真的知道吗?

Java 程序员 后端

k8s常见问题大收集

Java 程序员 后端

Layui图片上传组件使用指南

Java 程序员 后端

Linux系统:第六章:Linux服务

Java 程序员 后端

Mybatis一二级缓存实现原理与使用指南

Java 程序员 后端

MyBatis初级实战之二:增删改查

Java 程序员 后端

Kurento实战之四:应用开发指南

Java 程序员 后端

Linux入门(二) ~ Linux的常用命令

Java 程序员 后端

Linux下jdk的安装卸载切换

Java 程序员 后端

Memcached缓存

Java 程序员 后端

MyBatis官方文档-XML 配置

Java 程序员 后端

mybatis映射器组件

Java 程序员 后端

keepalived实现双机热备(1)

Java 程序员 后端

Kurento实战之一:KMS部署和体验

Java 程序员 后端

Linux极速上手,超全面总结

Java 程序员 后端

markdown+七牛云,让写文更容易

Java 程序员 后端

MyBatis初级实战之二:增删改查(1)

Java 程序员 后端

Mybatis开发要点-resultType和resultMap的区别?

Java 程序员 后端

Kubernetes 常用命令大全

Java 程序员 后端

Log4j2的Appenders配置详解

Java 程序员 后端

MyBatis事务管理

Java 程序员 后端

keepalived实现双机热备

Java 程序员 后端

MongoDB :第六章:Java程序操作MongoDB

Java 程序员 后端

MyBatis 源码分析 - MyBatis入门

Java 程序员 后端

Kubernetes任务调用Job与CronJob及源码分析

Java 程序员 后端

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