22-《分布式系统架构的本质》系列02——从亚马逊的实践,谈分布式系统的难点

一、亚马逊的架构规定

  最早实践分布式服务化架构思想的公司应该是亚马逊,它早在 2002 年就颁布了下列架构规定,这应该就是 AWS(Amazon Web Service)出现的基础:

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

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

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

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

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

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

  前面提到过,分布式系统架构会带来很多问题,譬如:

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

  2. 每个团队都可能成为一个潜在的 DDoS 攻击者,除非每个服务都做好配额和限流;

  3. 监控和查错变得更复杂,除非有非常强大的监控手段;

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

  面对以上问题,亚马逊多年的实践,使其可以运维和管理极其复杂的分布式服务架构。主要在于以下几点:

  1. 分布式服务的架构需要分布式的团队架构

  在亚马逊,一个服务由一个小团队(two pizza team,两张 pizza 就可以喂饱的团队)负责。从前端到数据,从需求分析到上线运维。按职责分工,而非按技能分工。

  2. 分布式服务查错不容易

  一旦出现比较严重的故障,需要整体查错。出现一个 S2 的故障,就可以看到每个团队的人都会上线。在工单系统里能看到,在故障发生的一开始,大家都在签到并自查自己的系统。如果没问题,也要在线待命(standby),等问题解决。

  3. 没有专职的测试人员,也没有专职的运维人员,开发人员做所有的事情

  开发人员做所有事情的好处是——吃自己的狗粮(Eat Your Own Dog Food)。自己写的代码自己维护自己养,会让开发人员明白,写代码容易维护代码复杂。这样,开发人员在接需求、做设计、写代码、做工具时都会考虑到软件的长期维护性。

  4. 运维优先,崇尚简化和自动化

  为了能够运维如此复杂的系统,亚马逊内部在运维上下了非常大的功夫。现在人们所说的 DevOps 这个事,亚马逊在 10 多年前就做到了。亚马逊最为强大的就是运维,拼命地对系统进行简化和自动化,让亚马逊做到了可以轻松运维拥有上千万台虚机的 AWS 云平台。

  5. 内部服务和外部服务一致

  无论是从安全方面,还是接口设计方面,无论是从运维方面,还是故障处理的流程方面,亚马逊的内部系统都和外部系统一样对待。这样做的好处是,内部系统的服务随时都可以开放出来。而且,从第一天开始,服务提供方就有对外服务的能力。可以想象,以这样的标准运作的团队其能力会是什么样的。

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

1. 异构系统的不标准问题

  异构系统的不标准问题主要体现在:

    • 软件和应用不标准
    • 通讯协议不标准
    • 数据格式不标准
    • 开发、运维的过程和方法不标准

  不同的软件、语言,自然有不同的兼容性和不同的开发、测试、运维标准。自然而然地,这会使我们用不同的方式来开发和运维,从而引起架构复杂度的提升。譬如有些软件修改配置需要改 .config 文件,有些则需要调用管理 API。

  在通讯方面,不同的软件可能使用不同的协议,即使协议相同,数据格式也不一而足。不同的团队,采用不同的技术,开发和运维方式也不一样。这些不同会让整个分布式系统架构异常复杂。所以,分布式系统架构要有相应的规范。以网络通讯为例,很多服务的 API 出错,并不返回 HTTP 的错误状态码,而是返回正常状态码 200,然后在 HTTP Body 的 JSON 字符串中加入 error message。这就给监控造成很大困难。现在,应该使用 Swagger 规范了。

  我们再以软件配置管理为例进行说明:很多公司的软件配置管理就是 key-value 的形式。这种方式很灵活,灵活到可以轻易被滥用——不规范的配置命名、不规范的值,甚至在配置中直接嵌入前端展示内容。

  好的配置管理应该分为三层:底层和操作系统相关、中间层和中间件相关、最上层和业务应用相关。底层和中间层不能让客户灵活修改,而是要提供模板,让用户只能从中选择,而非胡乱配置。

  再譬如数据通讯协议,一定会有协议头和协议体。协议头定义基本的协议数据,协议体则是真正的业务数据。我们要让每个使用此协议的团队都遵循协议头规范定义,才能易于对请求进行监控、调度和管理。

2. 系统架构中的服务依赖性问题

  传统的单体应用中,一台机器挂了,整个软件也会随之挂掉。那么分布式架构是否就不会发生这样的事情呢?事实上,分布式架构下,服务是有依赖的。一个服务依赖链上的某个服务挂了,就有可能引起多米诺骨牌效应。

  如上所述,分布式系统中,服务的依赖也会带来一些问题:

    • 如果非关键业务被关键业务所依赖,那么这个非关键业务就变成了关键业务。
    • 服务依赖链中,会有“短板效应”。整个 SLA 由最差的那个服务决定。

  这就是服务治理的内容了。服务治理不仅要我们定义出服务的关键程度,还要我们定义或描述出关键业务或服务调用的主要路径。没有服务治理,就无法运维、管理整个系统。

  很多分布式架构在应用层上做到了业务隔离,然而,在数据库结点上并没有。如果一个非关键业务把数据库拖死,那么会导致全站不可用。所以,数据库方面也需要做相应的隔离,最好一个业务线用一套自己的数据库。这就是亚马逊服务器的实践——系统间不能读取对方的数据库,只通过服务接口耦合。这也是微服务的要求。我们不但要拆分服务,还要为每个服务拆分相应的数据库。

3. 故障发生概率更大

  在分布式系统中,因为使用的机器和服务会非常多,所以,故障发生的频率会比传统的单体应用更大。只不过,单体应用的故障影响面很大,而分布式系统中,虽然故障的影响面可以被隔离,但是因为机器和服务多,出故障的频率也会多。另一方面,因为管理复杂,而且没人知道整个架构中有什么,所以非常容易犯错误。对分布式系统架构的运维,堪比噩梦。

  以下两条堪比金科玉律:

    • 出现故障不可怕,故障恢复时间过长才可怕。
    • 出现故障不可怕,故障影响面过大才可怕。

  分布式系统的运维团队非常忙,几乎每时每刻都在处理故障。很多公司拼命给自己的系统里添加监控指标,这其实是费力不讨好——信息太多,等于没有信息。此外,SLA 要求我们定义出“Key Metrics”,即关键指标。不求质而重量,这是战术上勤奋,战略上懒惰的做法。

  上述都是“救火”,而非“防火”。我们在设计或运维系统时,就要考虑如何减轻故障(Design for Failure)。如果无法避免,也要用自动化的方式来恢复故障,减少故障影响面。

  当机器和服务数量越来越多时,瓶颈就变成了人固有的缺陷——人无法对复杂的事情做到事无巨细的管理,只有及其自动化才能帮助我们。

4. 多层架构的运维复杂度更大

  我们通常把系统分为四层:

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

  任何一层的问题都会导致整体问题。没有统一的视图和管理,导致运维被割裂开来,造成了更大的复杂度。

  很多公司都是按技能分工的,他们按照技能把技术团队分为产品开发、中间件开发、业务运维、系统运维等子团队。这样的分工导致的结果就是大家各管一摊,很多事情完全连不在一起。整个系统会像 “多米诺骨牌”一样,一个环节出现问题,就会倒下去一大片。因为没有一个统一的运维视图,不知道一个服务调用是如何经过每一个服务和资源,也就导致在出现故障时要花大量的时间在沟通和定位问题上。

  分工不是问题,问题是分工后的协作是否统一和规范。这点一定要重视。

原文地址:https://www.cnblogs.com/murongmochen/p/12077381.html

时间: 2024-10-10 21:22:20

22-《分布式系统架构的本质》系列02——从亚马逊的实践,谈分布式系统的难点的相关文章

亚马逊光缆被挖?——阿里工程师讲解支付宝如何架构设计数据中心

文: 周瑜 校对:李二 全文2500字,建议阅读时长7分钟 点击右上角关注我们,每天都能收到有趣的推文哦. 昨天科技圈最火的新闻应该是"AWS中国区光缆被挖,导致三星.小米等众多企业服务不可用". 又是光缆被挖,咦!?为什么是又,让我们来一起回到过去: 过往案例 2019.6.02:亚马逊光缆被挖断,国内部分地区网络出现异常 2019.3.23:施工队挖断腾讯光纤,致腾讯旗下100多款游戏受影响,损失大了 2015.5.27:由于杭州市萧山区某地光纤被挖断,造成目前少部分用户无法使用支

亚马逊的技术架构是怎么样的

还有这个:http://www.nedworks.org/~mark/presentations/san/Wikimedia%20architecture.pdf Amazon的体系结构Amazon从一个很小的网上书店发展成为现今世界上最大的网上书店中.他们开辟了让顾客来评估,审查和推荐商品的新方式.平台 inux orace C++ Per Mason Java Jboss Servets 状态 超过5500万活动顾客帐号 世界范围内超过100万活动零售合作商 构建一个页面所需访问的服务介于1

亚马逊AWS在线系列讲座——基于AWS云平台的高可用应用设计

设计高可用的应用是架构师的一个重要目标,但是基于云计算平台设计高可用应用与基于传统平台的设计有许多不同.云计算在给架构师带来了许多新的设计挑战的时候,也给带来了许多新的设计理念和可用的服务.如何在设计应用的时候充分利用云平台的各种特点是基于云计算设计的一个重要条件.在这个在线讲座中,我们将以亚马逊AWS云平台为例,讨论如何设计一个高可用应用. 我们先会根据AWS服务是否天然高可用.高容错的特点把常见的AWS服务分类.比如AWS把下面服务设计成高可用和高容错的服务: ·     Amazon S3

亚马逊AWS在线系列讲座——如何在AWS云平台上构建千万级用户应用

用户选择云计算平台来构建应用的一个重要原因是云平台的高弹性和高扩展性.面向互联网的应用往往需要支撑大量用户的使用,但是构建一个高扩展性的.高可用的应用具有一一定的挑战,不过基于AWS云平台来构建应用可以相对简化这个事情.这个在线讲座将讨论如何如何充分利用云平台的特性和AWS的相关服务来构建一个可以支撑千万级用户的应用.通过讨论不同用户数量级别的应用需求和架构特点,然后结合不同的AWS的服务来满足用户访问,并最终逐渐把架构优化成为可以支持千万级用户的设计.这个演讲的目的是帮助对AWS服务有一定基础

AWS系列之一 亚马逊云服务概述

云计算经过这几年的发展,已经不再是是一个高大上的名词,而是已经应用到寻常百姓家的技术.每天如果你和互联网打交道,那么或多或少都会和云扯上关系.gmail.github.各种网盘.GAE.heroku等各种服务都属于云服务的范畴.那么云计算的定义到底是什么?这里有摘自wiki的定义. Cloud computing in general can be defined as a computer network which includes, computing hardware machine o

亚马逊如何变成 SOA(面向服务的架构)?

阮一峰 日期: 2016年9月10日 上一篇文章,我摘录了<程序员的呐喊>.这本书有趣的内容太多,今天再摘录一段. 1. 亚马逊公司不仅是世界最大的网络书店,还是世界最大的云服务商.它是怎么实现从电商到云商的转变呢? 一切都是CEO杰夫·贝索斯促成的,他对市场有着超乎常人的理解和预见. 2. 2000年前后,贝索斯有一次在员工大会上提到,各种办公工具.书籍.影音制品都可以数字化,所以也意味着很容易盗版.数字产品可能会利润越来越低,很快就不再产生任何收入了. 所有的民用工业品也都很不妙,服装和电

亚马逊AWS在线系列讲座——第1讲:云计算和AWS入门

无论您是正在运行照片共享或是关键业务应用程序,您都需要快速获取灵活和低成本的IT资源. "云计算"是指通过互联网,按需交付IT资源并且按使用量付费的服务.无论您是一个创业公司需要加快增长但缺乏前期投入资金,还是大型企业在降低成本的同时,寻求IT创新,提高敏捷性和灵活性, AWS提供了一套完整的无需前期投入的Web服务,您只需点击几下,即可在数分钟之内获得需要的资源. 亚马逊AWS在线讲座将围绕AWS云平台的各种服务分不同的主题对AWS服务进行系统介绍.AWS在线讲座系列会由浅入深帮助刚

如何看透他人行为背后的本质 | 思维模型02:行为分析模型

阿牛(皱眉):辣鸡啊,你们团队新来的那个小白,业绩不怎么样啊,怎么回事儿? 辣鸡(一激灵):老板,小白的能力和态度都挺好的.可能是因为刚入职没多久,对自己的工作重点把握不好. 阿牛(更加不满):哦,那你作为他老板,怎么没好好引导一下? 辣鸡(指指手机):我也想啊老板,可实在太忙抽不出空.我连陪女朋友的时间都没了,她说我不在乎她,天天找我吵架,喏,你听. 阿牛(和颜悦色):最近的确辛苦你了,天天加班啊. 辣鸡(几近崩溃):可不,上周听你讲了"可得性偏差模型",我就毫无怨言地加班了. 阿牛

.NET分布式系统架构思路

分布式系统是由一组通过网络进行通信.为了完成共同的任务而协调工作的计算机节点组成的系统.分布式系统的出现是为了用廉价的.普通的机器完成单个计算机无法完成的计算.存储任务.其目的是利用更多的机器,处理更多的数据. 一.最初假设的网站中,我们把应用系统网站.文件和数据库都放在一台服务器上,一台服务器包打天下. 二.随着业务扩展,一台服务器无法满足性能需求,将应用程序.数据库.文件分别部署在不同的服务器上,并根据服务器用途不同,配置不同的硬件,达到性能最佳的效果. 三.随着业务扩展,一台数据库.网站.