分布式架构概述

作者: 匠丶 | 来源:发表于2018-11-27 23:14 被阅读157次

    随着计算机系统规模变得越来越大,将所有的业务单元集中部署在一个或若干个大型机上的体系架构,已经越来越不能满足当今计算机系统。同时,随着微型计算机的出现,越来越多廉价的PC机成为了各大企业IT架构的首选,分布式的处理方式越来越受到业界的青睐。本文将介绍分布式架构的发展历史和分布式架构的一些相关概念。

    分布式架构的发展历史

    自20世纪60年代大型主机被发明出来之后,凭借其超强的计算和I/O处理能力,以及在稳定性和安全性方面的卓越表现,在很长一段时间内,大型主机引领了计算机行业以及商业计算领域的发展。在大型主机的研发上最知名的当属IBM,其主导研发的革命性产物SYSTEM/360系列大型主机,是计算机发展史上的一个里程碑。

    伴随着大型主机时代的到来,集中式的计算机系统架构也成为了主流。但从20世纪80年代以来,计算机系统向网络化和微型化的发展日趋明显,传统的集中式处理模式越来越不能适应人们的需求。

    集中式架构的劣势:

    1、通常一台大型主机汇集了大量精密的计算机组件,操作非常复杂,导致培养一个能够熟练运维大型主机的人的成本很高;

    2、大型主机非常昂贵,一台配置较好的IBM大型主机,其售价可能在上百万美元,因此也只有像政府、金融和电信等企业才有能力采购大型主机;

    3、集中式系统具有明显的单点问题。一旦一台大型主机出现了故障,那么整个系统将处于不可用状态;

    4、在单一大型主机上进行系统的扩容往往比较困难。

    "去 IOE"运动

    IOE 指的是 IBM 小型机、Oracle 数据库、EMC 的高端存储。阿里巴巴在 2009 年发起了一项"去 IOE"运动。阿里巴巴过去一直采用的是 Oracle 数据库,并利用小型机和高端存储设备提供高性能的数据处理和存储服务。随着业务的不断发展,数据量和业务量呈爆发性增长,传统的集中式Oracle 数据库架构在扩展性方面遭遇瓶颈。

    分布式架构的常见概念

    集群

    小饭店原来只有一个厨师,切菜洗菜备料炒菜全干。后来客人多了,厨房一个厨师忙不过来,又请了个厨师,两个厨师都能炒一样的菜,这两个厨师的关系是集群。


    分布式

    为了让厨师专心炒菜,把菜做到极致,又请了个配菜师负责切菜,备菜,备料,厨师和配菜师的关系是分布式,一个配菜师也忙不过来了,又请了个配菜师,两个配菜师关系是集群。


    副本机制

    副本(replica/copy)指在分布式系统中为数据或服务提供的冗余。数据副本指在不同的节点上持久化同一份数据,当出现某一个节点的数据丢失时,可以从副本上读取到数据。服务副本表示多个节点提供相同的服务,通过主从关系来实现服务的高可用方案。

    分布式系统的难点

    毫无疑问,分布式系统对于集中式系统而言,在实现上会更加复杂。分布式系统将会是更难理解、设计、构建和管理的,同时意味着应用程序的根源问题更难发现。

    三态

    在集中式架构中,我们调用一个接口返回的结果只有两种,成功或者失败,但是在分布式领域中,会出现“超时”这个状态。

    分布式事务

    这是一个老生常谈的问题,我们都知道事务就是对一系统操作的原子性保证。在单机的情况下,我们能够依靠本机的数据库连接和组件轻易做到事务的控制,但是分布式情况下,业务原子性操作很可能是跨服务的,这样就导致了分布式事务。

    例如 A和 B 操作分别是不同服务下的同一个事务操作内的操作,A 调用 B,A 如果可以清楚的知道 B 是否成功提交从而控制自身的提交还是回滚操作,但是在分布式系统中调用会出现一个新状态就是超时,就是 A 无法知道 B 是成功还是失败,这个时候 A是提交本地事务还是回滚呢?其实这是一个很难的问题,如果强行保证事务一致性,可以采取分布式锁,但是那样会增加系统复杂度而且会增大系统的开销,而且事务跨越的服务越多,消耗的资源越大,性能越低,所以最好的解决方案就是避免分布式事务。

    还有一种解决方案就是重试机制,但是重试如果不是查询接口,必然涉及到数据库的变更,如果第一次调用成功但是没返回成功结果,那调用方第二次调用对调用方来说依然是重试,但是对于被调用方来说是重复调用,例如 A 向 B 转账,A-100,B + 100,这样会导致 A 扣了 100,而 B 增加 200。这样的结果不是我们期望的,因此需在要写入的接口做幂等设计。多次调用和单次调用是一样的效果。通常可以设置一个唯一键,在写入的时候查询是否已经存在,避免重复写入。但是幂等设计的一个前提就是服务是高可用,否则无论怎么重试都不能调用返回一个明确的结果调用方会一直等待,虽然可以限制重试的次数,但是这已经进入了异常状态了。根据 CAP 和 BASE 理论,不可能在分布式情况下做到高可用和强一致性,一般都是保证最终一致性。

    负载均衡

    每个服务单独部署,为了达到高可用,每个服务至少是两台机器,因为互联网公司一般使用可靠性不是特别高的普通机器,长期运行宕机概率很高,所以两台机器能够大大降低服务不可用的可能性,这正大型项目会采用十几台甚至上百台来部署一个服务,这不仅是保证服务的高可用,更是提升服务的QPS。但是这样又带来一个问题,一个请求过来到底该路由到哪台机器?

    一致性

    数据被分散或者复制到不同的机器上,如何保证各台主机之间的数据的一致性将成为一个难点。

    节点故障

    分布式系统由多个节点组成,整个分布式系统完全出问题的概率是存在的,但是更多的情况是某个节点出问题。这种情况下我们实现分布式系统时需要考虑的问题。

    相关文章

      网友评论

        本文标题:分布式架构概述

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