精华内容
下载资源
问答
  • 分布式架构

    2018-05-28 09:35:37
    分布式架构体系描述 分布式架构体系描述 分布式架构体系描述 分布式架构体系描述 分布式架构体系描述 分布式架构体系描述 分布式架构体系描述 分布式架构体系描述 分布式架构体系描述 分布式架构体系描述 分布式架构...
  • 一、分布式架构学习路线图 二、计算机软件发展历史 三、技术架构演进史 架构演进一:早期雏形 架构演进二:数据库开发(LAMP特长) 架构演进三: javaweb的雏形 架构演进四: javaweb的集群发展​ 架构演进五: ...

    目录

    一、分布式架构学习路线图

    二、计算机软件发展历史

    三、技术架构演进史

    架构演进一: 早期雏形

    架构演进二: 数据库开发(LAMP特长)

    架构演进三:  javaweb的雏形

    架构演进四:  javaweb的集群发展​

    架构演进五:  javaweb的分布式发展

    架构演进六:  javaweb的微服务发展​

    集群与分布式的区别


    一、分布式架构学习路线图

    JAVA中的高并发终于写完了,在思考之后的专题些什么。朋友之前说让我总结下分布式相关的知识吧。但分布式是一个系统设计理念,牵扯到的东西太多了。顾整理了一下大概的学习路线,后续开始按照路线的模块去更(未必按顺序),以下知识点如果都能掌握,说明你基本上在JAVA上很能吃的开了。只只想吐槽以下,JAVA要学的东西太多了╮(╯▽╰)╭。

    据统计,人的阅读时间在20分钟以内是能够达到全身心投入的,顾文章单张篇幅以后会尽量缩短,但更新会尽量相应频繁一些。

    二、计算机软件发展历史

    首先我们了解下计算机软件的发展历史,大概总结概括,分为c/s时代,web1.0时代和web2.0时代。

    c/s时代:富客户端方案。卖软件可赚钱。​例如 qq、影音、游戏。

    1.0时代:主要是单向信息的发布,即信息门户---广大浏览器客户端​ ,互联网内容是由少数编辑人员(或站长)定制的。

    表是三大门户,新浪/网易/搜狐。新浪以新闻+广告为主,网易拓展游戏为主,搜狐延伸门户矩阵​​

    2.0时代:注重用户的交互。每个人都是内容的供稿者。 RSS订阅扮演一个很重要的作用。​​

    例如:博客、播客、维基、P2P下载、社区、分享服务

    时至今日,互联网的形式演变已经变成全员参与,老少皆宜的活动。因此,互联网相关的技术也是要求越来越高,参与人数的增加也让系统的负担越来越大。

    三、技术架构演进史

    以下为2017年天猫双11的交易指标。那么大的数据量,那么快的处理请求,显然单台机器,单个服务绝对是无法支撑的。

    那么怎么办呢,我们将原本单台部署,单台处理的服务,需要进行拆分以及部署到不同的服务器中去,使其用多台机器去处理,分担压力。但是我们又要保证系统的完整性。这就是分布式的设计。接下来我们看下服务架构的演进史。

    架构演进一: 早期雏形

    特征:应用程序主要做静态文件读取,返回内容给浏览器。

    架构演进二: 数据库开发(LAMP特长)

    特征:应用程序主要主要读取数据表值,填充html模块。业务逻辑简单,写sql

    架构演进三:  javaweb的雏形

    特征:tomcat + servlet + jsp + mysql。一个war包打天下​

    项目结构:ssh/ssm三层结构。

    架构演进四:  javaweb的集群发展​

    特征:硬件机器的横向复制,对整个项目结构无影响。

    架构演进五:  javaweb的分布式发展

    特征:将Service层单独分离出去,成为一个单独的项目jar。单独运行。​Web服务器通过rpc框架,对分离出去的service进行调用。

    架构演进六:  javaweb的微服务发展​

    特征:从业务角度,细分业务为微服务,每一个微服务是一个完整的服务(从http请求到返回)。​在微服务内部,将需要对外提供的接口,包装成rpc接口,对外部开放。

    集群与分布式的区别

    我在面试的时候,发现很多同学会把集群和分布式混淆,其实他俩完全是两个东西

    分布式:纵向拆分,一个业务分拆多个子业务,部署在不同的服务器上。主要是业务层面拆分,进行业务解耦,从而提高服务高可用以及高性能。
    集群:横向复制,同一个业务,部署在多个服务器上,前面通过负载均衡,起到分担压力的作用。而且这些服务器中,即使有一两个宕机也不会影响到整体业务。

    本章主要讲了一下高性能架构的学习路线,以及技术演进史。集群和分布式的区别。那么有一些问题留给大家。单机系统拆分成分布式和微服务,可能会遇到哪些问题,又该如何解决?大家先思考一下,下篇给大家解答。

    其他阅读   

    并发编程十一java8新增的并发特性

    并发编程专题—从入门到精通

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

    2018-07-01 17:35:19
    分布式架构设计分布式架构设计分布式架构设计分布式架构设计分布式架构设计分布式架构设计分布式架构设计分布式架构设计分布式架构设计分布式架构设计分布式架构设计分布式架构设计分布式架构设计分布式架构设计...
  • 从本专题我们开始进入分布式专题,分布式作为互联网企业技术人员必备的...1.了解分布式架构中的相关概念 2.初始分布式架构及意义 3.分布式架构的发展过程和历史 4.分布式架构的演进过程 5.构建分布式架构最重要的因素

    前言

    从本节开始我们正式进入分布式专题,分布式作为互联网企业技术人员必备的技能之一,涉及面非常广,可以说整个互联网架构就是围绕分布式的各个环节进行展开的!

    相信同学们对于高内聚、低耦合、高并发、高吞吐、低延迟等等这些词汇定不会陌生。设计出这一套合理的分布式系统往往考验着工程师的不单单是过硬的基础知识与底层设计,更多的是对于分布式架构的理解与经验!

    在本节,我将带大家追根溯源,从计算机发展历史起步,到为何要提出分布式系统,最后了解一下成熟的互联网分布式架构的演进过程!

    本节重点内容:

    1. 了解分布式架构中的相关概念
    2. 初始分布式架构及意义
    3. 分布式架构的发展过程和历史
    4. 分布式架构的演进过程
    5. 构建分布式架构最重要的因素

    分布式架构的发展历史

    1946 年情人节(2.14) , 世界上第一台电子数字计算机诞生在美国宾夕法尼亚大学大学,它的名字是:ENIAC; 这台计算机占地 170 平米、重达 30 吨,每秒可进行 5000 次加法运算。第一台电子计算机诞生以后,意味着一个日新月异的 IT 时代的到来。一方面单台计算机的性能每年都在提升:从最早的 8 位 CPU 到现在的 64 位 CPU;从早期的 MB 级内存到现在的 GB 级别内存;从慢速的机械存储到现在的固态 SSD 硬盘存储。

    tips:冯诺依曼模型
    在这里插入图片描述
    ENIAC 之后,电子计算机便进入了 IBM 主导的大型机时代,IBM 大型机之父吉恩.阿姆达尔被认为是有史以来最伟大的计算机设计师之一。1964 年 4 月 7 日,在阿姆达尔的带领下,历时三年,耗费 50 亿美元,第一台 IBM 大型机 SYSTEM/360 诞生。这使得 IBM 在 20 实际 50~60 年代统治整个大型计算机工业,奠定了 IBM 计算机帝国的江山。

    • IBM 大型机曾支撑美国航天登月计划

    • IBM 主机一直服务于金融等核心行业的关键领域

    由于高可靠性和超强的计算能力,即便在 X86 和云计算飞速发展的情况下,IBM 的大型机依然牢牢占据着一定的高端市场份额,20 世纪 80 年代,在大型机霸主的时代,计算机架构同时向两个方向发展

    1. 以 CISC (微处理器执行的计算机语言指令集) CPU 为架构的价格便宜的面向个人的 PC

    2. 以 RISC (精简指令集计算机) CPU 为架构的价格昂贵的面向企业的小型 UNIX 服务器

    分布式架构发展的里程碑

    大型主机的出现。凭借着大型机超强的计算和 I/O 处理能力、稳定性、安全性等,在很长一段时间内,大型机引领了计算机行业及商业计算领域的发展。而集中式的计算机系统架构也成为了主流。随着计算机的发展,这种架构越来越难以适应人们的需求,比如说

    1. 由于大型主机的复杂性,导致培养一个能够熟练运维大型主机的人的成本很高

    2. 大型主机很贵,一般只有土豪(政府、金融、电信)才能用得起

    3. 单点问题,一台大型主机出现故障,那么整个系统将处于不可用状态。而对于大型机的使用群体来说,这种不可用导致的损失是非常大的

    4. 科技在进步,技术在进步。PC 机性能不断提升,很多企业放弃大型机改用小型机及普通 PC 来搭建系统架构

    阿里巴巴在 2009 年发起了一项"去 IOE"运动

    IOE 指的是 IBM 小型机、Oracle 数据库、EMC 的高端存储 2009 年“去 IOE”战略透露,到 2013 年 5 月 17 日最后一台 IBM 小型机在支付宝下线。

    为什么要去 IOE?

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

    传统的商业数据库软件(Oracle,DB2),多以集中式架构为主,这些传统数据库软件的最大特点就是将所有的数据都集中在一个数据库中,依靠大型高端设备来提供高处理能力和扩展性。集中式数据库的扩展性主要采用向上扩展(Scale up)的方式,通过增加 CPU,内存,磁盘等方式提高处理能力。这种集中式数据库的架构,使得数据库成为了整个系统的瓶颈,已经越来越不适应海量数据对计算能力的巨大需求

    分布式系统的意义

    1. 升级单机处理能力的性价比越来越低

    单机的处理能力主要依靠 CPU、内存、磁盘。通过更换硬件做垂直扩展的方式来提升性能,成本会越来越高。

    1. 单机处理能力存在瓶颈

    单机处理能力存在瓶颈,CPU、内存都会有自己的性能瓶颈,也就是说就算你是土豪不惜成本去提升硬件,但是硬件的发展速度和性能是有限制的。

    1. 稳定性和可用性这两个指标很难达到

    单机系统存在可用性和稳定性的问题,这两个指标又是我们必须要去解决的

    分布式架构的常见概念

    集群

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

    在这里插入图片描述

    分布式

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

    在这里插入图片描述

    节点

    节点是指一个可以独立按照分布式协议完成一组逻辑的程序个体。在具体的项目中,一个节点表示的是一个操作系统上的进程。

    副本机制

    副本(replica/copy)指在分布式系统中为数据或服务提供的冗余。

    数据副本指在不同的节点上持久化同一份数据,当出现某一个节点的数据丢失时,可以从副本上读取到数据。数据副本是分布式系统中解决数据丢失问题的唯一手段。

    服务副本表示多个节点提供相同的服务,通过主从关系来实现服务的高可用方案

    中间件

    中间件位于操作系统提供的服务之外,又不属于应用,他是位于应用和系统层之间为开发者方便的处理通信、输入输出的一类软件,能够让用户关心自己应用的部分。

    架构的发展过程

    一个成熟的大型网站系统架构并不是一开始就设计的非常完美,也不是一开始就具备高性能、高可用、安全性等特性,而是随着用户量的增加、业务功能的扩展逐步完善演变过来的。在这个过程中,开发模式、技术架构等都会发生非常大的变化。而针对不同业务特征的系统,会有各自的侧重点,比如像淘宝这类的网站,要解决的是海量商品搜索、下单、支付等问题;

    像腾讯,要解决的是数亿级别用户的实时消息传输;百度所要解决的是海量数据的搜索。每一个种类的业务都有自己不同的系统架构。我们简单模拟一个架构演变过程。

    我们以 javaweb 为例,来搭建一个简单的电商系统,从这个系统中来看系统的演变历史;要注意的是,接下来的演示模型,关注的是数据量、访问量提升,网站结构发生的变化, 而不是具体关注业务功能点。其次,这个过程是为了让大家更好的了解网站演进过程中的一些问题和应对策略。假如我们系统具备以下功能:

    • 用户模块:用户注册和管理

    • 商品模块:商品展示和管理

    • 交易模块:创建交易及支付结算

    阶段一,单应用架构

    在这里插入图片描述

    网站的初期也可以认为是互联网发展的早起,我们经常会在单机上跑我们所有的程序和软件。

    把所有软件和应用都部署在一台机器上,这样就完成一个简单系统的搭建,这个时候的讲究的是效率。

    阶段二,应用服务器和数据库服务器分离

    随着网站的上线,访问量逐步上升,服务器的负载慢慢提高,在服务器还没有超载的时候,我们应该做好规划,提升网站的负载能力。假如代码层面的优化已经没办法继续提高,在不提高单台机器的性能,增加机器是一个比较好的方式,投入产出比非常高。这个阶段增加机器的主要目的是讲 web 服务器和数据库服务器拆分,这样不仅提高了单机的负载能力,也提高了容灾能力
    在这里插入图片描述

    阶段三,应用服务器集群

    应用服务器负载告警,如何让应用服务器走向集群

    随着访问量的继续增加,单台应用服务器已经无法满足需求。在假设数据库服务器还没有遇到性能问题的时候,我们可以增加应用服务器,通过应用服务器集群将用户请求分流到各个服务器中,从而继续提升负载能力。此时多台应用服务器之间没有直接的交互,他们都是依赖数据库各自对外提供服务
    在这里插入图片描述

    架构发展到这个阶段,各种问题也会慢慢呈现

    1. 用户请求由谁来转发到具体的应用服务器

    2. 用户如果每次访问到的服务器不一样,那么如何维护 session
      在这里插入图片描述

    阶段四,数据库压力变大,数据库读写分离

    架构演变到这里,并不是终点。上面我们把应用层的性能拉上来了,但是数据库的负载也在慢慢增大,那么怎么去提高数据库层面的负载呢?有了前面的思路以后,自然会想到增加服务器。但是假如我们单纯的把数据库一分为二,然后对于后续数据库的请求,分别负载到两台数据库服务器上,那么一定会造成数据库不统一的问题。所以我们一般先考虑读写分离的方式

    在这里插入图片描述

    这个架构的变化会带来几个问题

    1. 主从数据库之间的数据同步;可以使用 mysql 自带的 master-slave 方式实现主从复制

    2. 对应数据源的选择 ; 采用第三方数据库中间件,例如 mycat

    阶段五,使用搜索引擎缓解读库的压力

    数据库做读库的话,尝尝对模糊查找效率不是特别好,像电商类的网站,搜索是非常核心的功能,即便是做了读写分离,这个问题也不能有效解决。那么这个时候就需要引入搜索引擎了使用搜索引擎能够大大提高我们的查询速度,但是同时也会带来一些附加的问题,比如维护索引的构建。
    在这里插入图片描述

    阶段六,引入缓存机制缓解数据库的压力

    随着访问量的持续增加,逐渐出现许多用户访问统一部分内容的情况,对于这些热点数据,没必要每次都从数据库去读取,我们可以使用缓存技术,比如 memcache、redis 来作为我们应用层的缓存;另外在某些场景下,比如我们对用户的某些 IP 的访问频率做限制,那这个放内存中又不合适,放数据库又太麻烦,这个时候可以使用Nosql 的方式比如 mongDB 来代替传统的关系型数据库

    在这里插入图片描述

    阶段七,数据库的水平/垂直拆分

    我们的网站演进的变化过程,交易、商品、用户的数据都还在同一个数据库中,尽管采取了增加缓存,读写分离的方式,但是随着数据库的压力持续增加,数据库的瓶颈仍然是个最大的问题。因此我们可以考虑对数据的垂直拆分和水平拆分

    垂直拆分:把数据库中不同业务数据拆分到不同的数据库

    在这里插入图片描述

    水平拆分:把同一个表中的数据拆分到两个甚至跟多的数据库中

    水平拆分的原因是某些业务数据量已经达到了单个数据库的瓶颈,这时可以采取讲表拆分到多个数据库中

    在这里插入图片描述

    阶段八,应用的拆分

    随着业务的发展,业务越来越多,应用的压力越来越大。工程规模也越来越庞大。这个时候就可以考虑讲应用拆分,按照领域模型讲我们的用户、商品、交易拆分成多个子系统

    在这里插入图片描述

    这样拆分以后,可能会有一些相同的代码,比如用户操作,在商品和交易都需要查询,所以会导致每个系统都会有用户查询访问相关操作。这些相同的操作一定是要抽象出来,否则就会是一个坑。所以通过走服务化路线的方式来解决

    在这里插入图片描述

    那么服务拆分以后,各个服务之间如何进行远程通信呢?

    通过 RPC 技术,比较典型的有:webservice、hessian、http、RMI等等

    前期通过这些技术能够很好的解决各个服务之间通信问题,but,互联网的发展是持续的,所以架构的演变和优化还在持续

    在这里插入图片描述

    成熟的互联网架构模型:
    https://www.processon.com/view/5f72a468637689435f222b0e

    前面我们讲过经典理论-冯.诺依曼体系,计算机硬件由运算器、控制器、存储器、输入设备、输出设备五大部分组成。不管架构怎么变化,计算机仍没有跳出该体系的范畴;

    • 输入设备的变化

    在分布式系统架构中,输入设备可以分两类,第一类是互相连接的多个节点,在接收其他节点传来的信息作为该节点的输入;另一种就是传统意义上的人机交互的输入设备了输出设备的变化

    输出和输入类似,也有两种,一种是系统中的节点向其他节点传输信息时,该节点可以看作是输出设备;另一种就是传统意义上的人际交互的输出设备,比如用户的终端

    • 控制器的变化

    在单机中,控制器指的是 CPU 中的控制器,在分布式系统中,控制器主要的作用是协调或控制节点之间的动作和行为;比如硬件负载均衡器;LVS 软负载;规则服务器等

    • 运算器

    在分布式系统中,运算器是由多个节点来组成的。运用多个节点的计算能力来协同完成整体的计算任务

    • 存储器

    在分布式系统中,我们需要把承担存储功能的多个节点组织在一起,组成一个整体的存储器;比如数据库、redis(key-value 存储)

    分布式系统的难点

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

    • 三态

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

    • 分布式事务

    这是一个老生常谈的问题,我们都知道事务就是一些列操作的原子性保证,在单机的情况下,我们能够依靠本机的数据库连接和组件轻易做到事务的控制,但是分布式情况下,业务原子性操作很可能是跨服务的,这样就导致了分布式事务,例如 A 和 B 操作分别是不同服务下的同一个事务操作内的操作,A 调用 B,A 如果可以清楚的知道 B 是否成功提交从而控制自身的提交还是回滚操作,但是在分布式系统中调用会出现一个新状态就是超时,就是 A 无法知道 B 是成功还是失败,这个时候 A 是提交本地事务还是回滚呢?其实这是一个很难的问题,如果强行保证事务一致性,可以采取分布式锁,但是那样会增加系统复杂度而且会增大系统的开销,而且事务跨越的服务越多,消耗的资源越大,性能越低,所以最好的解决方案就是避免分布式事务。

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

    • 负载均衡

    每个服务单独部署,为了达到高可用,每个服务至少是两台机器,因为互联网公司一般使用可靠性不是特别高的普通机器,长期运行宕机概率很高,所以两台机器能够大大降低服务不可用的可能性,这正大型项目会采用十几台甚至上百台来部署一个服务,这不仅是保证服务的高可用,更是提升服务的 QPS,但是这样又带来一个问题,一个请求过来到底路由到哪台机器?路由算法很多,有 DNS 路由,如果 session 在本机,还会根据用户 id 或则 cookie 等信息路由到固定的机器,当然现在应用

    服务器为了扩展的方便都会设计为无状态的,session 会保存到专有的 session 服务器,所以不会涉及到拿不到 session 问题。那路由规则是随机获取么?这是一个方法,但是据我所知,实际情况肯定比这个复杂,在一定范围内随机,但是在大的范围也会分为很多个域,例如如果为了保证异地多活的多机房,夸机房调用的开销太大,肯定会优先选择同机房的服务,这个要参考具体的机器分布来考虑。

    • 一致性

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

    • 故障的独立性

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

    后记

    本节相关推荐书籍:

    点击下载:《大型网站系统与JAVA中间件实践》提取码:nzot

    更多架构知识,欢迎关注本套系列文章Java架构师成长之路

    展开全文
  • 服务端分布式架构: 客户端的分布式架构: 分布式系统:   服务端分布式架构: ①起初的时候,多个user直接访问同一台服务器,当用户量暴增的时候,单台服务器无法承受这么大的压力,所以会增加服务器,但是...

    目录

    服务端分布式架构:

    客户端的分布式架构:

    分布式系统:


     

    服务端分布式架构:

    ①起初的时候,多个user直接访问同一台服务器,当用户量暴增的时候,单台服务器无法承受这么大的压力,所以会增加服务器,但是服务器之间的端口号是不能重用的,而且用户默认端口是固定的,所以不同的服务器要使用不同的端口号来监听请求,但是用户并不知道端口号改变了,依然往原来的端口号发送数据,所以增加了一层负载均衡器,负载均衡器使用原来的服务端口,来监听用户的的请求,用户访问的都是负载均衡器(实际上用户并不会感受到)由负载均衡器来分配用户请求到达哪个服务器,从而避免某一台服务器的压力过大。而且这样做还有一个好处,如果用户访问又增加,可以直接增加服务器,而不需要修改其他的服务器(解耦合)。

    ②多台服务器也会产生新的问题,即第一次请求是写数据,写在了server1里面,第二次请求被负载到了server2,数据如何同步,我们最直觉的做法是,server1和server2之间的数据相互拷贝,一起开始的集群就是这么做的,但是这涉及到了两个进程之间的数据通信,非常的慢,这是不能容忍的,后来出现了RPC技术,这门技术非常的难,以至于很难普及,所以后来出现了Spring技术,也就是出现了缓存服务器,也就是上面的图片。 如此一来,数据都写到了缓存里面,数据一致性的问题就解决了。

    这里上面的架构中,也会有一定的问题,如果访问量太大了的话,负载均衡器承受不了。那么这个问题如何解决呢?这就引出了客户端的负载均衡。

    客户端的分布式架构:

    在服务端负载均衡的基础上,我们去掉了负载均衡器,增加了注册中心,我们提供服务的每台服务器都要在注册中心中完成注册,此时如果用户来访问服务器,会先到达注册中心,有注册中心告诉用户哪些服务器在提供服务,然后有用户自己来决定去访问那台服务器。这样一来之前负载均衡所承担的调度压力就分担到了用户自己的机器上,这样的设计堪称perfect。实际上这里的调度中心就是zookeeper,而zookeeper也是可以组成一个集群的。

    分布式系统:

    接下来我么介绍一下分布式系统,那什么是分布式系统呢?

    把一个完整的系统拆分成了一个又一个的子系统,叫做分布式系统,来分别运行

    ①在非分布式的设计中,订单和管理在同一台服务器中(这里我们以电商为例),这里用户的订单的访问量一定比电商的管理的访问量大,那么订单的访问一定会对管理带来影响,因为大量的用户访问订单的时候,就会分配很多栈空间,而机器的内存是有限的,管理能够分配到的内存就会减少;此时我们很容易想到,再加一台服务器(注意是服务器,不是物理机),这边一台处理订单的业务,另外一台处理管理的业务,这两个可以在同一台机器上,(比如两个不同的tomcat),那么这个时候订单会不会影响到管理呢?仍然会,因为服务器1和服务器2共用一个机器,该机器的cpu 是有限的资源,所以有必然会产生有影响;那好,我们将两者放在不同的机器上,那么此时订单会不会影响管理呢?

    答案是,仍然会,因为此时订单会占用大量网络资源,所以,两台机器应该放置在不同的网络中。如此一来我们不同的服务要设置不同的机器,而且这些机器不能在同一个网络中。这样我们能够很好地支持很大的并发量。另外在需要增加服务的时候,我们直接机器就OK了,并不会对之前的服务器带来影响,我们降低了耦合度。(如图增加了财务,物流) 

    ②这就引出了分布式系统,把一个完整的系统拆分成了一个又一个的子系统,叫做分布式系统,来分别运行。但是这样也带来了一个巨大的问题,各个子系统之间如何进行通信呢?当用户下了订单之后,通知财务结账完成之后,通知物流开始发货,如果各个子系统之间是这样通信的话,会增加耦合性,违背了OCP的开发原则,(比如,我增加一台财务的服务器,订单的服务器中和财务的通信地址至少需要修改,这是不合理的)所以此时,我们引出第三方:

    ③如果此时订单生成了,就会在这个第三方中产生一个消息,而财务和物流定时从这个第三方中取消息,而这时候财务只关心订单消息,而物流只关心财务消息。所以这个第三方还需要将各种消息区分开来,所以这个第三方也被称作是消息系统,在大数据中使用的kafka就是一个消息系统。

    如果你想要了解关于消息系统方面的文章,可以看kafka相关的文章

    以上就完成了我对于分布式的理解阐述。

    展开全文
  • 分布式架构

    2020-04-10 11:05:26
    分布式架构
  • 第一章微服务分布式架构设计原理 本章按照架构分布式微服务的顺序对其进行讲解并以实例形式介绍如何编写分布式微服务的代码每个微服务的架构都先从微服务的注册微服务间的通信开始然后编写每个微服务的持久化缓存等...
  • 分布式架构设计.docx

    2021-06-27 14:23:33
    分布式架构设计
  • 分布式架构设计详细流程:主要讲解分布式架构的发展流程,分布式架构详细设计以及分布式架构设计过程中需要的组件
  • 分布式架构基础讲义

    2018-01-04 11:22:08
    分布式架构基础讲义,主要介绍了分布式架构 负载均衡 缓存 数据库 分布式计算 性能优化等内容
  • 分布式架构技术总结

    2017-06-15 13:32:17
    讲解了分布式架构的发展形成,分布式架构需要的技术,需要注意的问题。
  • 信息学院-分布式架构演进过程 信息学院-分布式架构演进过程 信息学院-分布式架构演进过程
  • 主流分布式架构

    千次阅读 2019-09-30 16:42:10
    本文我们来聊一聊目前主流的分布式架构以及分布式架构中常见理论以及如何才能设计出高可用的分布式架构好了。分布式架构中,SOA和微服务架构是最常见两种分布式架构,而且目前服务网格的概念也越来越火了。那我们...

    一、前言

    本文我们来聊一聊目前主流的分布式架构以及分布式架构中常见理论以及如何才能设计出高可用的分布式架构好了。分布式架构中,SOA和微服务架构是最常见两种分布式架构,而且目前服务网格的概念也越来越火了。那我们本文就先从这些常见架构开始。

    二、SOA架构解析

    SOA 全称是: Service Oriented Architecture,中文释义为 “面向服务的架构”,它是一种设计理念,其中包含多个服务, 服务之间通过相互依赖最终提供一系列完整的功能。各个服务通常以独立的形式部署运行,服务之间 通过网络进行调用。架构图如下:

    跟 SOA 相提并论的还有一个 ESB(企业服务总线),简单来说 ESB 就是一根管道,用来连接各个服务节点。ESB的存在是为了集成基于不同协议的不同服务,ESB 做了消息的转化、解释以及路由的工作,以此来让不同的服务互联互通; 随着我们业务的越来越复杂,会发现服务越来越多,SOA架构下,它们的调用关系会变成如下形式:

    很显然,这样不是我们所想要的,那这时候如果我们引入ESB的概念,项目调用就又会很清晰,如下:

    SOA所要解决的核心问题

    系统间的集成 : 我们站在系统的角度来看,首先要解决各个系统间的通信问题,目的是将原先系统间散乱、无规划的网状结构,梳理成规整、可治理的星形结构,这步的实现往往需要引入一些概念和规范,比如 ESB、以及技术规范、服务管理规范; 这一步解决的核心问题是有序

    系统的服务化 : 我们站在功能的角度,需要把业务逻辑抽象成可复用、可组装的服务,从而通过服务的编排实现业务的快速再生,目的是要把原先固有的业务功能抽象设计为通用的业务服务、实现业务逻辑的快速复用;这步要解决的核心问题是复用

    业务的服务化 : 我们站在企业的角度,要把企业职能抽象成可复用、可组装的服务,就要把原先职能化的企业架构转变为服务化的企业架构,以便进一步提升企业的对外服务的能力。“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。而本步骤,则是以业务驱动把一个业务单元封装成一项服务。要解决的核心问题是 高效

    三、微服务(Microservices)架构解析

    微服务架构和 SOA 架构非常类似,微服务只是的 SOA 升华,只不过微服务架构强调的是“业务需要彻底的组件化及服务化”,原单个业务系统会被拆分为多个可以独立开发、设计、部署运行的小应用。这些小应用间通过服务化完成交互和集成。 组件表示的就是一个可以独立更换和升级的单元,就像 PC 中的 CPU、内存、显卡、硬盘一样,独立且可以更换升级而不影响其他单元。若我们把 PC 中的各个组件以服务的方式构建,那么这台 PC 只需要维护主板(可以理解为ESB)和一些必要的外部设备就可以。CPU、内存、硬盘等都是以组件方式提供服务,例如PC 需要调用 CPU 做计算处理,只需知道 CPU 这个组件的地址就可以了。

    微服务的特征

    1. 通过服务实现组件化
    2. 业务能力来划分服务和开发团队
    3. 去中心化
    4. 基础设施自动化(devops、自动化部署)

    四、SOA 和微服务架构的差别

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

    Docker容器技术的出现,为微服务提供了非常便利的条件,比如更小的部署单元,每个服务可以通过类似 Spring Boot 或者 Node 等技术独立运行。

    还有一个点大家应该可以分析出来,SOA 注重的是系统集成,而微服务关注的是完全分离

    五、服务网格(Service Mesh)架构解析

    17 年年底,非侵入式的 Service Mesh 技术慢慢走向了成熟。Service Mesh ,中文释义“服务网格”,作为服务间通信的基础设施层在系统中存在。如果要用一句话来解释什么叫 Service Mesh,我们可以将它比作是应用程序或者说微服务间的 TCP/IP,负责服务间的网络调用、熔断、限流和监控。我们都知道在编写应用程序时程序猿一般都无须关心 TCP/IP 这一层(比如提供 HTTP 协议的 Restful 应用),同样如果使用服务网格我们也就不需要关系服务间的那些原来是由应用程序或者其他框架实现的事情(熔断、限流、监控等),现在只要交给 Service Mesh 就可以了。服务网格架构图如下:

    目前流行的 Service Mesh 开源软件有 LinkerdEnvoyIstio,而最近 Buoyant(开源 Linkerd 的公司)又发布了基于 Kubernetes 的 Service Mesh 开源项目 Conduit

    关于微服务和服务网格的区别,我这样理解:微服务更注重服务之间的生态,专注于服务治理等方面,而服务网格更专注于服务之间的通信,以及和 DevOps 更好的结合等

    服务网格的特征

    1. 应用程序间通讯的中间层
    2. 轻量级网络代理
    3. 应用程序无感知
    4. 解耦应用程序的重试/超时、监控、追踪和服务发现

    六、分布式架构的基本理论

    在说 CAP、BASE 理论之前,我们先要了解下分布式一致性的问题。 实际上对于不同业务的服务,我们对数据一致性的要求是不一样的,如 12306,它要求数据的严格一致性, 不能把票卖给用户以后却发现没有座位了;再比如银行转账, 我们通过银行转账的时候,一般都会收到一个提示 : 转账申请将会在 24 小时内到账。实际上这个场景满足的是最终钱只要转账成功了即可,同时如果钱没汇出去还要保证资金不丢失。所以说,用户在使用不同的服务的时候对数据一致性的要求是不一样的。

    关于分布式一致性问题

    分布式系统中要解决的一个非常重要的问题就是数据的复制。 在我们的日常开发经验中,相信大多数开发人员都遇过这样的问题 : 在做数据库读写分离的场景中,假设客户端 A 将系统中的一个值 V 由 V1 变更为 V2,但客户端 B 无法立即读取到 V 的最新值,而需要在一段时间之后才能读取到。这再正常不过了,因为数据库复制之间存是在延时的。

    所谓分布式一致性的问题,就是指在分布式环境中引入数据复制机制后,不同数据节点之间可能会出现的、且无法依靠计算机应用程序自身解决的数据不一致的情况。简单来说, 数据一致性就是指在对一个副本数据进行变更的时候,必须确保也能够更新其它的副本,否则不同副本之间的数据将出现不一致。 那么如何去解决这个问题呢?按照正常的思路,我们可能会想到既然是网络延迟导致的问题,那么我们就把同步动作进行阻塞,用户 2 在查询的时候必须要等数据同步完成以后再来做。但这个方案会非常影响性能。如果同步的数据比较多或比较频繁,那么阻塞操作可能会导致整个新系统不可用。故我们没有办法找到一种既能够满足数据一致性、 又不影响系统性能的方案,所以就诞生了一个一致性的级别:

    强一致性 : 这种一致性级别是最符合用户直觉的,它要求系统写入的是什么,读出来的也要是什么,用户体验好,但实现起来往往对系统的性能影响较大。
    弱一致性 : 这种一致性级别约束了系统在写入成功后, 不保证立即可以读到写入的值,也不保证多久之后数据 能够达到一致,但会尽可能地保证到某个时间级别(如秒级别)后,数据能够达到一致状态。
    最终一致性 : 最终一致性其实是弱一致性的一个特例,系统会保证在一定时间内,能够达到数据一致的状态。这里之所以将最终一致性单独提出来,是因为它是弱一致性中非常推崇的一种一致性模型,也是业界在大型分布式系统的数据一致性上用的比较多的一致性模型。

    CAP 理论

    它是一个经典的分布式系统理论。CAP 理论告诉我们 : 一个分布式系统不可能同时满足一致性(C:Consistency)、可用性(A:Availability)及分区容错性(P:Partition tolerance) 这三个基本要求,最多只能同时满足其中两项。CAP 理论在互联网界有着广泛的知名度,也被称为“帽子理论”,它是 由 Eric Brewer 教授在 2000 年举行的 ACM 研讨会提出的 一个著名猜想: 一致性(Consistency)、可用性(Availability)、分区容错 (Partition-tolerance)三者无法在分布式系统中被同时满足,并且最多只能满足两个!

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

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

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

    分区是导致分布式系统可靠性问题的固有特性,从本质上来看,CAP 理论的准确描述不应该是从 3 个特性中选取两个,所以我们只能被迫适应,根本没有选择权。CAP 并不是一个普适性原理和指导思想,它仅适用于原子读写的 NoSql 场景中,并不适用于数据库系统。

    BASE 理论

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

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

    Basically Available(基本可用)

    表示在分布式系统出现不可预 知的故障时,允许瞬时部分可用性

    比如我们在淘宝上搜索商品,正常情况下是在 0.5s 内返回查询结果,但是由于后端的系统故障导致查询响应时间变成了 2s

    再比如数据库采用分片模式,100W 个用户数据分在 5 个数据库实例上,如果破坏了一个实例,那么可用性还 有 80%,也就是 80%的用户都可以登录,系统仍然可用

    电商大促时,为了应对访问量激增,部分用户可能会被 引导到降级页面,服务层也可能只提供降级服务。这就 是损失部分可用性的体现

    Soft-state(软状态).

    表示系统中的数据存在中间状态,并 且这个中间状态的存在不会影响系统的整体可用性,也就 是表示系统允许在不同节点的数据副本之间进行数据同步 过程中存在延时; 比如订单状态,有一个待支付、支付中、 支付成功、支付失败, 那么支付中就是一个中间状态,这 个中间状态在支付成功以后,在支付表中的状态同步给订 单状态之前,中间会存在一个时间内的不一致。

    Eventually consistent(数据的最终一致性)

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

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

    七、分布式架构下的高可用设计

    避免单点故障

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

    热备(linux HA)

    多机房(同城灾备、异地灾备)

    应用的高可用性

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

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

    数据量(数据分片、读写分离)

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

    垂直伸缩

    提升硬件能力

    水平伸缩

    增加服务器

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

    CDN 全称是 Content Delivery Network,中文释义是内容分发网络。CDN 的作用是把用户需要的内容分发到离用户最近的地方进行响应,这样用户能够快速获取所需要的内容。 CDN 本质上就是一种网络缓存技术,能够把一些相对稳定的资源放到距离最终用户较近的地方,一方面可以节省整个广域网的带宽消耗,另外一方面也可以提升用户的访问速度、改善用户体验。现实系统中我们一般会把静态的文件(图片、脚本、静态页面等)放到 CDN 中。

    当用户访问网站页面上的内容 URL,经过本地 DNS 系统解析,DNS 系统最终会将域名的解析权交给 CNAME 指向的 CDN 专用 DNS 服务器。

    CDN 的 DNS 服务器将 CDN 的全局负载均衡设备 IP 地址返回用户。

    用户向 CDN 的全局负载均衡设备发起内容 URL 访问请求。

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

    区域负载均衡设备会为用户选择一台合适的缓存服务器提供服务。

    选择的依据包括 : 根据用户 IP 地址,判断哪一台服务器距离用户最近。根据用户所请求的 URL 中携带的内容名称,判断哪一台服务器上有用户所需内容;查询各个服务器当前的负载情况,判断哪一台服务器上有服务能力。基于以上条件的综合分析之后,区域负载均衡设备会向全局负载均衡设备返回一台缓存服务器的 IP 地址。

    局负载均衡设备把服务器的 IP 地址返回给用户。

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

    什么情况下用 CDN?

    最适合的是那些不会经常变化的内容,比如图片,js 文件, CSS 文件,图片文件包括程序模板中CSS 文件中用到的背景图片,还有就是作为网站内容组成部分的那些图片等等。

    灰度发布

    我们的应用即使经过了测试部门的测试,也仍然很难全面覆盖用户的使用场景,为了保证万无一失,我们在进行发布的时候一般都会采用灰度发布,也就是会对新应用进行分批发布,逐步扩大新应用在整个及集群中的比例直到最后全部完成。灰度发布是说针对新应用在用户体验方面完全无感知。

    灰度发布系统的作用在于,可以根据自己的配置,来将用 户的流量导到新上线的系统上,来快速验证新的功能, 而一旦出问题,也可以马上的回滚发布,简单的说,就是一套 A/BTest 系统.

    八、总结

    通过本文,我们就对主流的SOA架构、微服务架构、服务网格架构做了解析,然后知道了分布式架构中的几个基本理论,然后还分析了如何设计出高可用的分布式架构。

    转自:https://mp.weixin.qq.com/s?__biz=MzU3MTE2NzExMA==&mid=2247484383&idx=1&sn=a8b9e6a941d1498f224e6c55fb7e0a4c&chksm=fce51b36cb929220ebcb76033335b50fa9421a2c3c54ac501dfc34123584d7bb3b27a9fd8fb0&scene=21#wechat_redirect

    展开全文
  • 分布式架构说明

    2018-04-18 23:13:28
    分布式架构设计说明,很详细的讲解了分布式相关的知识以及规则。
  • 分布式架构概述

    2016-11-30 15:26:16
    分布式架构概述
  • SOA分布式架构设计

    2021-03-02 13:39:17
    本文档表述了平台SOA的分布式架构设计,并通过使用多种视图以及模拟项目运营中所需要的解决流量,资源负载的各个主要方面的解决方案,以满足系统的开发需求和文档备案。本文档记录并表述了系统架构的设计人员对系统...
  • 大型网站分布式架构

    2018-10-12 15:07:54
    大型网站分布式架构,有其他诸多学习资源,
  • redis 分布式架构代码

    2016-09-27 10:26:41
    redis 分布式架构代码
  • 分布式架构和集群架构的区别

    万次阅读 2021-03-15 12:04:14
    分布式架构和集群架构的区别分布式架构集群架构 分布式架构 分布式架构是每个服务器都是运行不同的程序,提供的功能不一样,相互协作形成一个完整的生态,再对外提供服务,各个服务器之间有存在相互通信调用的情况,...
  • Redis分布式架构

    2018-07-21 16:58:42
    redis的三种分布式架构介绍,从主从模式、哨兵模式,再到集群模式
  • 58同城的分布式架构存储实践 , 58同城的分布式架构存储实践, 58同城的分布式架构存储实践, 58同城的分布式架构存储实践
  • 主要介绍了Python自定义主从分布式架构,结合实例形式分析了主从分布式架构的结构、原理与具体的代码实现技巧,需要的朋友可以参考下

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 524,281
精华内容 209,712
关键字:

分布式架构