精华内容
参与话题
问答
  • 分布式系统架构

    2019-06-27 18:53:48
    面试官们“爱不释手”的分布式系统架构到底是个什么鬼? 转载地址:http://www.imooc.com/article/288454 一、什么是分布式系统? 在谈分布式系统架构前,我们先来看看,什么是分布式系统? 假设原来我们有一个...

    面试官们“爱不释手”的分布式系统架构到底是个什么鬼?

    转载地址:http://www.imooc.com/article/288454

    一、什么是分布式系统?

    在谈分布式系统架构前,我们先来看看,什么是分布式系统?

    假设原来我们有一个系统,代码量30多万行。现在拆分成20个小系统,每个小系统1万多行代码。

    原本代码之间都是直接基于Spring框架走JVM内存调用,现在拆开来,将20个小系统部署在不同的机器上,然后基于分布式服务框架(比如dubbo)搞一个rpc调用,接口与接口之间通过网络通信来进行请求和响应。

    所以分布式系统很重要的特点就是服务间要跨网络进行调用,我们来看下面的图:

    https://img3.mukewang.com/5d121f610001ec3c04480271.jpg

    此外,分布式系统可以大概可以分成两类。

    1. 底层的分布式系统。

    比如hadoop hdfs(分布式存储系统)、spark(分布式计算系统)、storm(分布式流式计算系统)、elasticsearch(分布式搜索系统)、kafka(分布式发布订阅消息系统)等。

    2. 分布式业务系统

    分布式业务系统,把原来用java开发的一个大块系统,给拆分成多个子系统,多个子系统之间互相调用,形成一个大系统的整体。

    举个例子,假设原来你做了一个OA系统,里面包含了权限模块、员工模块、请假模块、财务模块,一个工程,里面包含了一堆模块,模块与模块之间会互相去调用,1台机器部署。

    现在如果你把他这个系统给拆开,权限系统,员工系统,请假系统,财务系统,4个系统,4个工程,分别在4台机器上部署。

    然后一个请求过来,完成这个请求,员工系统去调用权限系统,调用请假系统,调用财务系统,4个系统分别完成了一部分的事情。

    最后4个系统都干完了以后,才认为是这个请求已经完成了。这就是所谓的分布式业务系统。

    同样,我们来一张图,感受一下上述过程:

    https://img1.mukewang.com/5d121f7300019a8a06760490.jpg

     

    二、为什么要走分布式系统架构?

     

    有的同学可能要问了,我一台服务器跑的好好的,所有系统一个工程全部搞定,多好。为啥一定要去搞什么分布式系统架构,互相调用还要走远程,似乎还增加了不少工作量?

    这里我就以我曾经待过的一个公司的血泪经历为例,来聊聊这个问题。

    很多年前,在没有走分布式架构的时候,我待的这家公司的各个业务线都是垂直的 “烟囱式” 项目。

    随着互联网的快速发展,公司的业务也在不断的发展,注册用户增加、网站应用的功能、规模不断扩大,特别是移动互联网的发展,APP、微信、自助终端机等访问渠道的增加,各种新业务,新需求不断涌入,系统遇到了各种各样的问题。

    首先是项目工程无节制的变得臃肿庞大,系统复杂度增加,大几十万行代码,几十个开发人员,service层,dao层代码大量被copy使用,经常各种代码合并冲突问题要处理,非常耗费时间。

    经常是我改动了我的代码,别人调用了我的接口,导致他的代码也出现问题,需要重新测试,麻烦的要死。

    然后每次发布都是几十万行代码的系统一起发布,大家得一起提心吊胆准备上线,几十万行代码的上线,每次上线都要做很多的检查,很多异常问题的处理,每个人都高度紧张,被搞得几乎崩溃。

    而且如果我现在有个新业务,打算把相关依赖升级一下,比如升级到最新的spring版本,还不行,因为这可能导致别人的代码报错,不敢随意乱改技术。并且一个web工程每次启动都需要好分钟的时间,本地IDE里面调试一次代码都很痛苦。

    其次,随着用户访问流量的增加,系统负载压力变大,变得不堪重负,通过增加实例数,增加硬件扩容能够带来的效果已微乎其微,故障频发,效率低下。系统质量也越来越难以保证,测试周期也变得越来越长,无法满足公司业务发展的需要。

    以上就是以前待过的公司一些 “不堪回首” 的往事,总得来说,问题主要体现在以下几个方面:

    1. 应用代码耦合严重,功能扩展难

    2. 新需求开发交互周期长,测试工作量大

    3. 新加入的开发同事需要很长时间才能熟悉系统

    4. 升级维护也很困难(改动任何一点地方都要升级整个系统)

    5. 系统性能提升艰难,可用性低,不稳定。

    好,既然我们已经深刻体会到了系统耦合的痛苦,那么现在就来看看,系统拆分后带来的好处:

    首先,系统拆分了以后,会感觉整个世界都清爽了。

    几十万行代码的系统,假设拆分成20个服务,平均每个服务就1-3万行代码,每个服务部署到单独的机器上。20个工程,就用20个git仓库代码,20个开发人员,每个人维护自己的那个服务就可以了。

    • 因为是自己独立的代码,跟别人没关系。再也没有代码冲突了,爽!

    • 每次就测试我自己的代码就可以了,爽!

    • 每次就发布我自己的一个小服务就可以了,爽!

    • 技术上想怎么升级就怎么升级,保持接口定义不变,输入输出内容不变就可以了,爽!

    总结起来一句话,分布式系统拆分之后,可以大幅度提升复杂系统大型团队的开发效率。

     

    三、系统如何进行拆分?

     

    一般来说,将系统进行拆分,首先需要对系统整体比较熟悉。可以走多轮拆分的思路,第一次拆分就是将以前的各个大的模块粗粒度的拆分开来。

    比如一个电商系统可以拆分成订单系统、商品系统、店铺系统、会员系统、促销系统、支付系统等等。

    后面可能每个系统又变得越来越复杂了,比如说订单系统又可以进一步拆分出来购物车系统,库存系统,价格系统等。

    总得来说就是基于领域驱动设计的思想以及实战经验总结,同时参考业界一些常规做法,大家讨论着来进行拆分,逐步优化,多轮拆分,小步快跑,最终达到一个比较好的状态。

     

    四、分布式之后带来的技术挑战?

     

    首先就是分布式服务框架的选用,目前国内来讲主流的还是dubbo与spring cloud。

    我们来思考一下,使用服务框架主要用来解决什么问题呢?如果不用dubbo或者spring cloud是否可以做分布式架构呢?

    不用dubbo或者spring cloud等服务框架当然也是可以的,但是这就需要自己处理很多事情了。

    比如,各个子系统走restful接口调用,那么就是http调用,这时比如传送过去一个对象,就要自己搞成一个json,然后一次调用失败后重试怎么做?

    另外,一般来说都是集群部署,目标系统有多个实例,那么自己还要写一个负载均衡算法,如何每次随机从多个目标机器中挑选一个来调用?

    还有,如果目标系统扩容新部署了一个实例,或者服务器故障下线了一个实例,如何动态让调用方感知到呢? 诸如此类的很多问题,如果不用服务框架的话,自己这么瞎搞,会遇到各种各样的问题。

    上述过程,用一张图给大家呈现一下:

    https://img3.mukewang.com/5d121f8e0001639706750281.jpg

    如果选用了某一个分布式服务框架,就需要深入的掌握这个框架的使用与底层原理,比如 dubbo 就需要搞明白以下的一些问题:

    1. dubbo的工作原理?

    2. dubbo支持的序列化协议?

    3. dubbo的负载均衡和高可用策略?动态代理策略?

    4. dubbo的SPI思想?

    5. 如何基于dubbo进行服务治理、服务降级、失败重试以及超时重试?

    6. dubbo服务接口的幂等性如何设计(比如不能重复扣款,不能重复生成订单,不能重复创建卡号)?

    7. dubbo服务接口请求的顺序性如何保证?

    8. 如何自己设计一个类似dubbo的rpc框架?

    使用spring cloud也是一样,比如eureka的工作原理?feign声明式调用的原理?等等各种底层原理要搞懂。

    还有其它一些走分布式架构后常见的要解决的技术问题:

    1. 分布式会话

    2. 分布式锁

    3. 分布式事务

    4. 分布式搜索

    5. 分布式缓存

    6. 分布式消息队列

    7. 统一配置中心

    8. 分布式存储,数据库分库分表

    9. 限流、熔断、降级等。

    以上这些问题,往深了说,每一个点都需要可能 N 篇文章来详细阐述,这里没法逐一展开,后面我们会继续通过一些文章,聊一聊这些分布式架构下的各种技术问题。

    展开全文
  • 现在的架构很多,各种各样的,如高并发架构、异地多活架构、容器化架构、微服务架构、高可用架构、弹性化架构等,还有和这些架构相关的管理型的技术方法,如 DevOps、应用监控、自动化运维、SOA 服务治理、去 IOE ...

    现在的架构很多,各种各样的,如高并发架构、异地多活架构、容器化架构、微服务架构、高可用架构、弹性化架构等,还有和这些架构相关的管理型的技术方法,如 DevOps、应用监控、自动化运维、SOA 服务治理、去 IOE 等等,还有很多。

    那什么是分布式系统?分布式系统是支持分布式处理的软件系统,是由通信网络互联的多处理机体系结构上执行任务的系统。包括分布式操作系统、分布式程序设计语言及其编译系统、分布式文件系统分布式数据库系统等,当然这些也是分布式的关键技术。

    使用分布式系统主要有:

    1.增大系统容量。我们的业务量越来越大,而要能应对越来越大的业务量,一台机器的性能已经无法满足了,我们需要多台机器才能应对大规模的应用场景。所以,我们需要垂直或是水平拆分业务系统,让其变成一个分布式的架构。

    2.加强系统可用。我们的业务越来越关键,需要提高整个系统架构的可用性,这就意味着架构中不能存在单点故障。这样,整个系统不会因为一台机器出故障而导致整体不可用。所以,需要通过分布式架构来冗余系统以消除单点故障,从而提高系统的可用性。

    3.因为模块化,所以系统模块重用度更高

    4.因为软件服务模块被拆分,开发和发布速度可以并行而变得更快

    5.系统扩展性更高

    6.团队协作流程也会得到改善

    分布式系统的类型有三种:

    1.分布式处理,但只有一个总数据库,没有局部数据库

    2.分层式处理,每一层都有自己的数据库

    3.充分分散的分布式网络,没有中央控制部分,各节点之间的联系方式又可以有多种,如松散的联接,紧密的联接,动态的联接,广播通知式的联接等

    然后来对比一下单体应用和分布式架构的优缺点:

    1.从上面的表格可以看到,分布式系统虽然有一些优势,但也存在一些问题

    2.架构设计变得复杂(尤其是其中的分布式事务)

    3.部署单个服务会比较快,但是如果一次部署需要多个服务,部署会变得复杂

    4.系统的吞吐量会变大,但是响应时间会变长

    5.运维复杂度会因为服务变多而变得很复杂

    6.架构复杂导致学习曲线变大

    7.测试和查错的复杂度增大

    8.技术可以很多样,这会带来维护和运维的复杂度

    9.管理分布式系统中的服务和调度变得困难和复杂


    所以总结一下,分布式系统架构的难点在于系统设计,以及管理和运维。所以分布式系统架构在解决了一些问题的同时,也增加了其他的问题,这就需要不断的再用各种各样的技术跟手段去解决这些新增的问题。后续会跟上分布式系统架构的搭建以及使用。

    Hadoop伪分布式集群搭建使用

    Hadoop HA 高可用关键搭建


    展开全文
  • 分布式系统架构设计

    千次阅读 2018-11-01 16:14:23
    一,主流架构模型 SOA架构和微服务架构 SOA架构  SOA全称(Service Oriented Architecture) 中文意思是"面向服务的架构",他是一种设计方法,其中包含多个服务,服务之间通过相互依赖最终提供一系列的...

    一,主流架构模型 SOA架构和微服务架构

    SOA架构

           SOA全称(Service Oriented Architecture) 中文意思是"面向服务的架构",他是一种设计方法,其中包含多个服务,服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统中。各个服务之间通过网络调用

           跟SOA相提并论的还有一个ESB(企业服务总线),简单来说ESB就是一根管道,用来连接各个服务节点。为了集成不同系统,不同协议的服务,ESB做了消息的转化解释和路由工作,让不同的服务互联互通。

    系统初期

    系统后期

    SOA架构,使用ESB

    SOA所解决的核心问题

        1.系统集成:站在系统的角度,解决企业系统间的通信问题,把原先散乱,无规则的系统间的网状结构,梳理成规则,可治理的系统间星形结构,这一步往往需要引入一些产品,比如ESB,以及技术规范,服务管理规范;这一步解决的核心问题是【有序】

        2.系统的服务化:站在功能的角度,把业务逻辑抽象成可复用可组装的服务,通过服务的编排和实现业务的快速再生,目的:把原先固有的业务功能变为通用的业务服务,实现业务逻辑的快速复用,这步解决的核心问题是【复用】

           3.业务的服务化:站在企业的角度,把企业只能抽象成可复用 可组装的服务,把原先职能化的企业架构转为变为服务花的企业架构,进一步提升企业的对外服务能力,前两步都是技术层面来解决系统调用,系统功能复用的问题,第三步 则是以业务驱动把一个业务单元封装成一项服务,这一步解决的核心问题是【高效】。

    微服务架构 

           微服务架构和SOA架构类似,微服务架构是在SOA上做的升华,微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”,原有的单个业务系统会拆分为多个可以独立开发设计运行的小应用。这些小应用之间通过服务完成交互和集成。

           组件表示一个可以独立更换和升级的单元,像 PC机中的 CPU 内存,显卡 等 独立且可以更换升级而不影响其他单元,如果我们把PC机作为组件以服务的方式构建,那么这台PC只需要维护主板和一些必要的外部设备,CPU ,内存,硬盘 都是以组件方式提供服务,PC需要调用CPU做计算机处理,只需要知道CPU这个组件的地址即可。

           微服务特征

          1.通过服务实现组件化

          2.按业务能力来划分服务和开发团队

          3.去中心化

          4.基础设施自动化(devops ,自动化部署)

    SOA 架构和微服务架构的区别

           1,微服务不在强调传统的SOA架构里面比较重的ESB企业服务总线,同时SOA的思想进入到单个业务系统内部实现真正的组件化。

           2,Docker 容器技术的出现,为微服务提供了便利的条件,比如更小的部署单元,每个服务都可以通过类似的Node或者Spring boot 等技术跑在自己的进程中。

           3,SOA 注重的系统集成方面,而微服务关注的是完全分离。

    二. 分布式架构的基本理论 CAP,BASE 以及应用

           首先了解下一致性的问题

           强一致性:

           以客户端的角度来看,多并发访问时更新过的数据,要求数据能被后续的访问看到,就是 强一致性,例如 数据库的事务

           弱一致性:

           以客户端的角度来看,多并发访问时更新过的数据,如果能容忍后续的访问可以看到部分或者全部看不到,这就是 弱一致性,例如: 银行转账(一般是两小时或者24小时内到账)

           最终一致性 :

           以客户端的角度来看,多并发访问时更新过的数据,如果经过一段时间后要求能访问到更新后的数据 ,这就是 最终一致性,例如: 银行转账(一般是两小时或者24小时内到账)

           最终一致性是弱一致性的一个特例,是若一致性中非常推崇的一种一致性模型,也是业界在大型分布式系统的数据一致性上比较用的多的模型

            cap原理中,有三个要素  

    • 一致性(Consistency)
    • 可用性(Availability)
    • 分区容错性(Partition tolerance)

           CAP原理指的是这三个要素最多只能同时实现两点,不能三者兼顾,因此在设计分布式系统架构时,必须做出取舍,而对于分布式系统 分区容错性 是最基本要求,否则就失去价值,因此设计分布式系统,就是在一致性 C和可用性A中去一个平衡,对于大多数web应用,其实并不需要强一致性,因此牺牲一致性而换取高可用性,是目前多数分布式系统设计的方向。

          一致性: 所有节点上的数据时刻保持同步

          可用性:每个请求都能接受一个相应,无论响应成功或失败

          分区容错: 系统应该持续提供服务,即使系统内部(某个节点分区)有消息丢失。比如交换机失败,网址网络被分成几个子网,形成脑裂,服务器发生网络延迟或死机,导致某些server与集群中的其他机器失去联系。

          CAP并不是一个普适性的原理和指导思想,他仅仅使用于原子读写的NoSql场景中,并不适用于数据库系统。

    BASE理论

           从前面的分析中知道,在分布式系统下,CAP并不适合数据库事务(因为更新一些错误的数据而导致失败,无论使用什么样的高可用方案都是徒劳,因为数据发生了无法修正的错误)。此外XA事务()虽然保证了数据库在分布式系统下的ACID(原子性,一致性,隔离性,持久性)特性,但也带来了性能的代价,对于并发和响应时间要求比较高的电商平台来说,很难接受的。

           eBay尝试了另外一条完全不同的路,放宽了数据库事务的ACID的要求,提出一套名为BASE的新准则。BASE全称是Basically available soft-state Eventually Consistent 系统基本可用 软状态 数据最终一致性,相对CAP来说,他大大的降低了我们对系统的要求。

           Basically available(基本可用),在分布式系统出现不可预知的故障时,允许瞬时部分可用性
          1. 比如我们在淘宝上搜索商品,正常情况下是在0.5s 内返回查询结果,但是由于后端的系统故障导致查询响应时间变成了2s
          2. 再比如数据库采用分片模式,100W 个用户数据分在5个数据库实例上,如果破坏了一个实例,那么可用性还有80%,也就是80%的用户都可以登录,系统仍然可用做技术人的指路明灯,做职场生涯的精神导师
          3. 电商大促时,为了应对访问量激增,部分用户可能会被引导到降级页面,服务层也可能只提供降级服务。这就是损失部分可用性的体现
           soft-state(软状态). 表示系统中的数据存在中间状态,并且这个中间状态的存在不会影响系统的整体可用性,也就是表示系统允许在不同节点的数据副本之间进行数据同步过程中存在延时; 比如订单状态,有一个待支付、支付中、支付成功、支付失败, 那么支付中就是一个中间状态,这个中间状态在支付成功以后,在支付表中的状态同步给订单状态之前,中间会存在一个时间内的不一致。

           Eventually consistent(数据的最终一致性),表示的是所有数据副本在一段时间的同步后最终都能达到一个一直的状态,因此最终一致性的本质是要保证数据最终达到一直,而不需要实时保证系统数据的强一致

           BASE 理论的核心思想是:即使无法做到强一致性,但每个应用都可以根据自身业务特点,采用适当的方式来使系统达到最终一致性

    什么是分布式架构下的高可用设计

    1,避免单点故障

             a. 负载均衡技术(failover ,选址,硬件负载,软件负载,去中心化负载(gossip(redis-cluster))

             b. 热备 linux HA

             c. 多机房(同城灾备,异地灾备)

    2,应用的高可用

            a. 故障监控(系统监控(cpu,内存)、链路监控、日志监控)自动预警

            b. 应用的容错设计 (服务降级,限流) 自我保护能力

            c. 数据量 (数据分片,读写分离)

    分布式架构下的可伸缩设计

        垂直伸缩  提升硬件能力

        水平伸缩 增加服务节点(服务器)

    加速静态内容访问速度的CDN

          CDN是Content Delivery Network的缩写,表示的是内容的分发网络,CDN的作用是把用户需要的内容分发到离用户最近的地方,这样可以使用户能够快速获取所需要的内容。CDN其实就是一种网络缓存,能够把一些相对稳定的资源放到距离用户最近的地方,一方面节省整个广域网的带宽消耗,另一方面可以提升用户的访问速度,改进用户体验,一般会把静态资源文件(图片,脚本,静态页面等)存放在CDN中。

           

    1.当用户访问网站时,URL经过本地DNS解析,DNS系统会最终将域名的解析权交割CNAME指向的CDN专用DNS服务器

    2.CDN的DNS服务器将CDN的全局负载均衡设备ip 地址放回用户

    3,用户想CDN的全局负载均衡设备泛起内容URL访问请求

    4,CDN全局负载均衡设备根据用户IP地址,以及用户请求的内容URL选在一台用户所属区域的区域负载均衡设备,告诉用户向这台设备发起请求

    5. 区域负载均衡设备为用户选择一台合适的缓存服务器提供服务,选择的依据包括:根据IP地址,判断一台服务器距离用户最近

    根据用户所请求的URL中携带的内容名称,判断那一台服务器上有用户所需要的内容,查询各个服务器当前的负载状况,判断那一台服务器尚有服务能力,基于上述条件综合分析之后,区域负载均衡设备会向全局负载均衡设备返回一台缓存服务器的IP地址

    6.全局负载均衡设备会把服务器的IP返回给用户

    用户向缓存服务器发起请求,缓存服务器响应用户请求,将用户所需内容传送到用户终端,如果这台缓存服务器上并没有用户想要的内容,而区域均衡设备依然将他分配给用户,那么这台服务器就要向她的上一级缓存服务器请求内容,直至追溯到网站的源服务器将内容拉到本地。

    什么情况下使用CDN

    最适合那些不会经常变化的内容,比如 图片 js文件 css
     

    展开全文
  • 集中式 vs. 分布式系统架构

    万次阅读 2017-04-25 18:44:45
     随着计算机系统规模变得越来越大,将所有业务单元集中部署在一个或者若干个大型机 上的体系结构物,已经越来越不能满足当今计算机系统,尤其是大型互联网系统的快速发展,各种灵活多变的系统架构模型层出不穷。...

    一、前言

           随着计算机系统规模变得越来越大,将所有业务单元集中部署在一个或者若干个大型机 上的体系结构物,已经越来越不能满足当今计算机系统,尤其是大型互联网系统的快速发展,各种灵活多变的系统架构模型层出不穷。同时,随着微型计算机的出 现,越来越多廉价的PC机成为了各大IT企业架构的首选,分布式的处理方式越来越受到业界的青睐----计算机系统正在经历一场前所未有的从集中式到分布 式架构的变革。

    从集中式到分布式

           自从20世纪60年代大型主机被发明出来以后,凭借其超强的计算和I/O处理能力 以及在稳定性和安全性方面的卓越表现,在很长一段时间内,大型主机引领了计算机行业以及商业计算领域的发展。在大型主机的研发上最知名的当属IBM,其主 导研发的革命性产品System/360系列大型主机,是计算机发展史上的一个里程碑,与波音707和福特T型车齐名,被誉为20世纪最重要的三大商业成 就,IT界进入了大型主机时代。

           伴随着大型主机时代的到来,集中式的计算机系统架构也成为了主流。在那个时候,由 于大型主机卓越的性能和良好的稳定性,其在单机处理能力方面的优势非常明显,使得IT系统快速进入了集中式处理阶段,其对应的计算机系统称为集中式系统。 但从20世纪80年代以来,计算机系统向网络化和微型化的发展日趋明显,传统的集中式处理模型越来越不能适应人们的需求,具体表现在:

           1、大型主机的人才培养成本非常高,通常一台大型主机汇集了大量精密的计算机组件,操作非常复杂,这对一个运维人员掌握其技术细节提出了非常高的要求

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

           3、集中式有非常明显的单点问题,大型主机虽然在性能和稳定性方面表现卓越,但并 不代表其永远不会出故障。一旦一台大型主机出现了故障,那么整个系统将处于不可用的状态,后果相当严重。最后,随着业务的不断发展,用户访问量迅速提高, 计算机系统的规模也在不断扩大,在单一大型主机上进行扩容往往比较困难

           4、随着PC机性能的不断提升和网络技术的快速普及,大型主机的市场份额变得越来越小,很多企业开始放弃原来的大型主机,而改用小型机和普通PC服务器来搭建分布式计算机

           对业内新闻比较关注的,一定知道阿里巴巴在2009年发起了一项"去IOE"运动。 因为阿里巴巴从2008年开始各项业务都进入了井喷式的发展阶段,这对于后台IT系统的计算与存储能力提出了非常高的要求,一味地针对小型机和高端存储进 行不断扩容,无疑会产生巨大的成本。同时,集中式的系统架构体系也存在着诸多单点问题,完全无法满足互联网应用爆炸式的发展需求。因此,为了解决业务快速 发展给IT系统带来的巨大挑战,从2009年开始,阿里集团启动了"去IOE"计划,其电商系统开始正式迈入了分布式系统时代。

    二、集中式系统架构

           所谓集中式系统就是指由一台或多台主计算机组成中心节点,数据集中存储于这个中心 节点中,并且整个系统的所有业务单元都集中部署在这个中心节点上,系统所有的功能均由其集中处理。也就是说,集中式系统中,每个终端或客户端及其仅仅负责 数据的录入和输出,而数据的存储与控制处理完全交由主机来完成。

           集中式系统最大的特点就是部署结构简单,由于集中式系统往往基于底层性能卓越的大型主机,因此无需考虑如何对服务进行多个节点的部署,也就不用考虑多个节点之间的分布式协作问题。

    三、分布式系统架构

           在《分布式系统概念与设计》注 一书中,对分布式系统做了如下定义:

           分布式系统是一个硬件或软件组件分布在不同的网络计算机上,彼此之间仅仅通过消息传递进行通信和协调的系统。

           严格地讲,同一个分布式系统中的计算机在空间部署上是可以随意分布的,这些计算机可能被放在不同的机柜上,也可能在不同的机房中,甚至分布在不同的城市。无论如何,一个标准的分布式系统在没有任何特定业务逻辑约束的情况下,都会有以下几个特征:

    1、分布性

           分布式系统中的多台计算机都会在空间上随意分布,同时,及其的分布情况也会随时变动

    2、对等性

           分布式系统中的计算机没有主/从之分,既没有控制整个系统的主机,也没有被控制的 从机,组成分布式系统的所有节点都是对等的。副本(Replica)是分布式系统最常见的概念之一,指的是分布式系统对数据和服务提供的一种冗余方式。在 常见的分布式系统中,为了对外提高可用的服务,我们往往会对数据和服务进行副本处理。数据副本是指在不同的节点上持久化同一份数据,当某一个节点上存储的 数据丢失时,可以从副本上读取到该数据,这是解决分布式系统数据丢失问题最为有效的手段。另一类副本是服务副本,指多个节点提供同样的服务,每个节点都有 能力接收来自外部的请求并进行相应的处理

    3、并发性

           在一个计算机网络中,程序运行过程中的并发性操作是非常常见的行为,例如同一个分布式系统的多个节点,可能会并发地操作一些共享的资源,诸如数据库或分布式存储等,如何准确并高效地协调分布式并发操作也成为了分布式系统架构与设计中最大的挑战之一

    4、缺乏全局时钟 

           一个典型的分布式系统是由一系列空间上随意分布的多个进程组成的,具有明显的分布性,这些进程之间通过交换消息来进行相互通信。因此,在分布式系统中,很难定义两个事件究竟谁先谁后,原因就是因为分布式系统缺乏一个全局的始终控制序列

    5、故障总是会发生

           组成分布式系统的所有计算机,都有可能发生任何形式的故障。一个被大量工程实践过 的黄金定理是:任何在设计阶段考虑到的异常情况,一定会在系统实际运行中发生,并且,在系统实际运行中还会遇到很多在设计时未考虑到的异常故障。所以,除 非需求指标允许,在系统设计时不能放过任何异常情况

    6、处理单点故障

           在整个分布式系统中,如果某个角色或者功能只有某台单机在支撑,那么这个节点称为单点,其发生的故障称为单点故障,也就是通常说的SPoF(Single Point of Failure),避免单点而对关键就是把这个功能从单机实现变为集群实现,当然,这种变化一般会比较困难,否则就不会有单点问题了。如果不能把单点变为集群实现,那么一般还有两种选择:

    (1)给这个单点做好备份,能够在出现问题时进行恢复,并且尽量做到自动恢复

    (2)降低单点故障的影响范围

    四、集中式与分布式系统架构之间的比较

           目前,在IT系统架构设计中,对于服务器的配置方案主要有两种。

           1. 分布式,即根据业务功能、模块设计或行政部门及机构的不同,采用相对分散的中小型服务器;

           2. 集中式,即将所需的主机资源集中到少数的几台大型服务器中。

           这两种方式,在投资成本、业务支撑及扩展能力、维护管理、方案拓展等方面,存在着比较显著的差异。 

    1. 业务支撑及扩展能力

           采用三层结构设计的系统中,数据库层和应用层一般支持横向和纵向两种扩展方式。其中,横向指通过增加服务器台数来扩展某一层次的处理能力,纵向指通过对单台主机的CPU、内存等配件扩充来提高某一层次的处理能力。

           分散式结构下,由于单台主机的处理能力比较有限,所以数据库层和应用层将主要依赖于横向扩充方式来支撑业务的扩展。横向扩充方式的实现,并不等同于简单地增加机器,有两个前提必须要满足。一是多台数据库服务器必须能够并行运行,这就要求使用并行版数据库软件。二是应用系统必须基于并行数据访问方式进行开发。在实际地使用中,由于并行版数据库软件使用较难、维护费用高、应用软件大多没有基于并行方式开发等原因,横向扩充方式实现起来相对较难。当业务处理需求发展到一定程度时,单台主机的处理能力,尤其是数据库服务的地处理能力,往往成为制约整体业务扩充能力的薄弱环节。

           集中式结构下,除了可以采用横向方式进行扩充外,由于单台主机具备较好的扩充能力,因此可以采用纵向方式进行处理能力的扩充。纵向扩充方式,仅涉及硬件配件的增加,数据库软件和应用软件不需调整,实现起来相对容易。

    2. 投资成本 

    (1)机房建设成本

           采用分散方式进行系统建设,一般需要的主机数量从数台到数十台不等。这些主机,都需要基本的机房占地(包括主机自身面积和每台四周一米左右的维护空间)、承重设计、电力供应、制冷需求。累计到一起之后,通常对机房的基本建设提出很大的需求。尤其对于一些保密性要求较高的中心机房,机房建设成本往往不是以平面面积进行衡量,而是以立方面积进行计量的。这种情况下,每增加一台主机设备,将导致机房基本构建成本的大幅度上升。而采用集中方式进行系统建设,所需要的主机和存储设备大幅度减少,相应对占地面积、承重设计、电力供应、制冷设备等基本建设方面的要求都大大降低,从减少了机房建设成本。

    (2)硬件成本 

           过去,在硬件成本的采购上,采用集中式结构通常会比采用分散式结构投资略大一些。现在,随着主机上分区技术的普遍采用,主机的CPU、内存等资源能够很好地加以均衡和利用,减少每台机器的“浪费”空间和资源,两种结构的投资差异不大,甚至常常出现分散式的投资比集中式的投资更大的情况。

    (3)软件成本 

           集中式使用的CPU总数通常比分散式少。系统软件、数据库软件、应用软件等软件产品的采购费用是与CPU个数成正比的。因此,采用集中式,能够节约软件采购成本。

    (4)运行成本 

           集中式结构的运行成本较低。由于采用较少的设备,在机房个数、机房空间、电源功率、机房制冷、保修费用等方面,集中式都比分散式相对节约。

    3. 使用灵活性 

           分散式结构中,所有主机的功能单一,若需要变换功能,需要对系统进行较大调整。集中模式下,各分区的功能可以根据需要进行调整,如果将来有业务扩充或者功能增加时,实现起来比较容易。相比而言,集中模式的灵活性更强。

    4. 资源利用有效性 

           分散式结构下,每台主机的资源被限制用于某一个固定的功能。当某台主机资源紧张时,即使其它主机还有大量的空闲资源,也无法调配给这台主机使用。只能通过系统升级的方式解决问题。而集中模式下,主机资源可以在同一台主机的不同分区之间动态调配。当某个分区资源紧张时,如果同一主机的其它分区上有空闲资源,可以随时动态调配给这个分区使用。另一方面,分散模式需要对每台主机都配置本地磁带机、光驱、显卡、显示器等设备。而集中模式则可以根据需要对每台主机只配置一套这类设备。  因此,集中模式对系统资源的利用更加有效。

    5. 维护管理 

           由于集中式采用服务器数量比分散式少,可以减少硬件的故障点,从而减少硬件维护的工作量,降低系统管理的繁琐程度。  当然,由于设备相对比较集中,单台设备故障后的影响范围也就较大。因此,分散式结构下,单台设备故障导致的运行风险相对较小。集中式下,对选用主机的高可靠性要求更高。

    6. 方案拓展 

           数据处理中心建立后,随之而来的,就是对灾难备份的考虑。在这个方面,分散式结构下,要建立灾难备份系统,难度相对较大。由于设备数量多、地点可能分散、平台不一定一致,对灾备技术的选择比较受限制,可选方案相对较少,甚至没有可选方案。而集中式结构下,能够实现灾备的方式,相对较多。  另一方面,采用分散式结构,灾备中心需要配置的备份设备比较多,投资相对更大。

           综上所述,分散式和集中式两种模式,各有利弊。对于大型的数据处理中心,通常集中式更为适合。


    参考文献:https://wenku.baidu.com/view/7c9081e2524de518964b7d4e.html

    参考博客:http://www.cnblogs.com/szlbm/p/5588541.html


    展开全文
  • 分布式系统架构经典资料

    千次阅读 2018-06-28 10:47:30
    前段时间,我写了一系列分布式系统架构方面的文章(拉到文末看目录),有很多读者纷纷留言讨论相关的话题,还有读者留言表示对分布式系统架构这个主题感兴趣,希望我能推荐一些学习资料。 就像我在前面的文章中多次...
  • 二、为什么要走分布式系统架构? 三、系统如何进行拆分? 四、分布式之后带来的技术挑战? 一、什么是分布式系统? 在谈分布式系统架构前,我们先来看看,什么是分布式系统? 假设原来我们有一个系统,...
  • 什么是分布式架构

    千次阅读 2019-02-26 22:03:20
    分布式系统(distributed system)是建立在网络之上的软件系统。 内聚性是指每一个数据库分布节点高度自治,有本地的数据库管理系统。 透明性是指每一个数据库分布节点对用户的应用来说都是透明的,看不出是本地...
  • 分布式系统架构设计

    万次阅读 2018-07-03 23:17:15
    中文意思为 面相服务的架构,他是一种设计方法,轻重包含多个服务,服务之间通过相互依赖最终提供一系列的功能, 一个服务通常以独立的形式存在与操作系统进程中,各个服务之间通过网络调用,跟SOA相提并论的还有ESB...
  • 浅析分布式系统 WeTest导读 我们常常会听说,某个互联网应用的服务器端系统多么牛逼,比如QQ、微信、淘宝。那么,一个互联网应用的服务器端系统,到底牛逼在什么地方?为什么海量的用户访问,会让一个服务器端...
  • 分布式微服务架构体系详解

    万次阅读 多人点赞 2018-07-10 23:30:02
    在最初系统架构的搭建,或者当现有架构已到达瓶颈需要进行架构演进时,很多架构师、运维工程师会考虑是否需要搭建微服务架构体系。虽然很多文章都说微服务架构是复杂的、会带来很多分布式的问题,但只要我们了解这些...
  • 聊聊分布式系统架构

    千次阅读 2018-06-27 21:34:24
    学习分布式系统架构也是如此,只要找到这张网的纲,就能更有效率地做好架构和工程。本文首发于陈皓在极客时间 APP 上开设的《左耳听风》专栏,推荐订阅。 写在前面 最近几年,我们一直在谈论各式各样的架构,如高...
  • 从前端到后端、从高效交互到负载均衡、从网络传输到Web服务器、从高并发到高可用……本书囊括了分布式系统的整个技术体系,内容详实、结构清晰,能帮助读者理解和掌握分布式系统架构设计的难点和调优方案。...
  • 分布式系统架构

    2020-09-20 11:54:33
  • 大规模分布式系统架构与设计实战.完整版.pdf 详细介绍大规模分布式系统常用技术与架构
  • 分布式系统架构、微服务架构等架构区别分布式系统架构、微服务架构等架构区别分布式系统架构什么是分布式系统架构分布式系统架构的优缺点微服务系统架构什么是微服务系统架构?微服务系统架构的优缺点 分布式系统...
  • 现在的架构很多,如高并发架构、异地多活架构、容器化架构、微服务架构、高可用架构、弹性化架构等,还有和这些架构相关的管理型的技术方法,如 DevOps、应用监控、自动化运维、SOA 服务治理、去 IOE 等等。...
  • 高可用分布式系统架构

    千次阅读 2019-09-18 16:23:32
    最近画了张分布式系统架构图,请教下各位小伙伴,不足之处还望指出来。
  • 大型互联网分布式系统架构技术要点 解决问题的通用思路是将分而治之(divide-and-conquer),将大问题分为若干个小问题,各个击破。在大型互联网的架构实践中,无一不体现这种思想。 架构目标 低成本:任何公司...
  • 转载于:https://www.cnblogs.com/yaoyuan2/p/10218064.html
  • 引言 最近几年,大家一直在讨论各式各样的架构,如:高并发架构、异地多活架构、容器化架构、微服务架构、高可用架构、弹性化...分布式系统架构的目的 首先,我们需要搞清楚的是为什么需要分布式系统,而不是传统...

空空如也

1 2 3 4 5 ... 20
收藏数 358,990
精华内容 143,596
关键字:

分布式系统架构