美文网首页
分布式系统的难点

分布式系统的难点

作者: 自天佑之吉无不利 | 来源:发表于2023-10-16 20:00 被阅读0次

    2002年的时候,亚马逊就颁布了下面的架构规定:
    • 所有团队的程序模块都要通过 Service Interface 方式将其数据与功能开放出来。
    • 团队间程序模块的信息通信,都要通过这些接口。
    • 除此之外没有其它的通信方式。其他形式一概不允许:不能直接链结别的程序(把其他团队的程序当作动态链接库来链接),不能直接读取其他团队的数据库,不能使用共享内存模式,不能使用别人模块的后门,等等。唯一允许的通信方式是调用 Service Interface。
    • 任何技术都可以使用。比如:HTTP、CORBA、Pub/Sub、自定义的网络协议等。
    • 所有的 Service Interface,毫无例外,都必须从骨子里到表面上设计成能对外界开放的。也就是说,团队必须做好规划与设计,以便未来把接口开放给全世界的程序员,没有任何例外。
    • 不这样做的人会被炒鱿鱼。

    这其实就是微服务和分布式的雏形,亚马逊的运维和管理实践非常值得借鉴:
    • 分布式服务的架构需要分布式的团队架构。在亚马逊,一个服务由一个小团队(Two Pizza Team 不超过 16 个人,两张 Pizza 可以喂饱的团队)负责,从前端到数据,从需求分析到上线运维。这是良性的分工策略——按职责分工,而不是按技能分工。
    • 分布式服务查错不容易。一旦出现比较严重的故障,需要整体查错。出现一个 S2 的故障,就可以看到每个团队的人都会上线。在工单系统里能看到,在故障发生的一开始,大家都在签到并自查自己的系统。如果没问题,也要在线待命(standby),等问题解决(我在《故障处理最佳实践:应对故障》一文中详细地讲过这个事)。
    • 没有专职的测试人员,也没有专职的运维人员,开发人员做所有的事情。开发人员做所有事情的好处是——吃自己的狗粮(Eat Your Own Dog Food)。自己写的代码自己维护自己养,会让开发人员明白,写代码容易维护代码复杂。这样,开发人员在接需求、做设计、写代码、做工具时都会考虑到软件的长期维护性。
    • 运维优先,崇尚简化和自动化。为了能够运维如此复杂的系统,亚马逊内部在运维上下了非常大的功夫。现在人们所说的 DevOps 这个事,亚马逊在 10 多年前就做到了。亚马逊最为强大的就是运维,拼命地对系统进行简化和自动化,让亚马逊做到了可以轻松运维拥有上千万台虚机的 AWS 云平台。
    • 内部服务和外部服务一致。无论是从安全方面,还是接口设计方面,无论是从运维方面,还是故障处理的流程方面,亚马逊的内部系统都和外部系统一样对待。这样做的好处是,内部系统的服务随时都可以开放出来。而且,从第一天开始,服务提供方就有对外服务的能力。可以想象,以这样的标准运作的团队其能力会是什么样的。
    分布式系统中需要注意的问题
    问题一:异构系统的不标准问题
    这主要表现在:
    • 软件和应用不标准。
    • 通讯协议不标准。
    • 数据格式不标准。
    • 开发和运维的过程和方法不标准。
    问题二:系统架构中的服务依赖性问题
    如果非关键业务被关键业务所依赖,会导致非关键业务变成一个关键业务。
    服务依赖链中,出现“木桶短板效应”——整个 SLA 由最差的那个服务所决定。

    问题三:故障发生的概率更大
    在分布式系统中,因为使用的机器和服务会非常多,所以,故障发生的频率会比传统的单体应用更大。只不过,单体应用的故障影响面很大,而分布式系统中,虽然故障的影响面可以被隔离,但是因为机器和服务多,出故障的频率也会多。另一方面,因为管理复杂,而且没人知道整个架构中有什么,所以非常容易犯错误。
    你会发现,对分布式系统架构的运维,简直就是一场噩梦。我们会慢慢地明白下面这些道理。
    出现故障不可怕,故障恢复时间过长才可怕。
    出现故障不可怕,故障影响面过大才可怕。

    所谓“防火胜于救火”,我们还要考虑如何防火,这需要我们在设计或运维系统时都要为这些故障考虑,即所谓 Design for Failure。在设计时就要考虑如何减轻故障。如果无法避免,也要使用自动化的方式恢复故障,减少故障影响面。
    因为当机器和服务数量越来越多时,你会发现,人类的缺陷就成为了瓶颈。这个缺陷就是人类无法对复杂的事情做到事无巨细的管理,只有机器自动化才能帮助人类。也就是,人管代码,代码管机器,人不管机器!

    问题四:多层架构的运维复杂度更大
    通常来说,我们可以把系统分成四层:基础层、平台层、应用层和接入层。
    基础层就是我们的机器、网络和存储设备等。
    平台层就是我们的中间件层,Tomcat、MySQL、Redis、Kafka 之类的软件。
    应用层就是我们的业务软件,比如,各种功能的服务。
    接入层就是接入用户请求的网关、负载均衡或是 CDN、DNS 这样的东西。
    对于这四层,我们需要知道:
    任何一层的问题都会导致整体的问题;
    没有统一的视图和管理,导致运维被割裂开来,造成更大的复杂度。

    此文章为10月Day9学习笔记,内容来源于极客时间《左耳听风》,强烈推荐该课程

    相关文章

      网友评论

          本文标题:分布式系统的难点

          本文链接:https://www.haomeiwen.com/subject/twqfidtx.html