分布式架构_分布式架构设计 - CSDN
精华内容
参与话题
  • 现在的架构很多,各种各样的,如高并发架构、异地多活架构、容器化架构、微服务架构、高可用架构、弹性化架构等,还有和这些架构相关的管理型的技术方法,如 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 高可用关键搭建


    展开全文
  • 什么是分布式架构

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

    分布式系统(distributed system)是建立在网络之上的软件系统。

    内聚性是指每一个数据库分布节点高度自治,有本地的数据库管理系统。

    透明性是指每一个数据库分布节点对用户的应用来说都是透明的,看不出是本地还是远程。

     

    在分布式数据库系统中,用户感觉不到数据是分布的,即用户不须知道关系是否分割、有无副本、数据存于哪个站点以及事务在哪个站点上执行等。

    简单来讲:在一个分布式系统中,一组独立的计算机展现给用户的是一个统一的整体,就好像是一个系统似的。

    分布式系统作为一个整体对用户提供服务,而整个系统的内部的协作用户来说是透明的,用户就像是在使用一个MySQL一样。

    如分布式MySQL中间件-Mycat,来处理大并发大数据量的构架。

    分布式架构的应用

    有 分布式文件系统,分布式缓存系统,分布式数据库,分布式WebService,分布式计算

    我们来举例说明:

    分布式文件系统: 出名的有 Hadoop 的HDFS ,还有 google的 GFS , 淘宝的 TFS 等

    分布式缓存系统:memcache , hbase , mongdb 等

    分布式数据库 : MySQL , Mariadb, PostgreSQL 等

    以分布式MySQL数据库中间件MyCat 为例子,

    MySQL 在现在电商以及互联网公司的应用非常多,一个是因为他的免费开源,另外一个原因是因为分布式系统

    的水平可扩展性,随着移动互联网用户的暴增,互联网公司,像淘宝,天猫,唯品会等电商都采用分布式系统应对

    用户的高并发量以及大数据量的存储。

    而在Mycat的商业案例中,有对中国移动的账单结算项目中,应用实时处理高峰期每天2亿的数据量,

    在对物联网的项目中,实现处理高达26亿的数据量,并提供实时查询的接口。

    通过对MyCat的学习,加深分布式系统架构的理解,

    以及分布式相关的技术,分布式一致性ZooKeeper服务, 高可用HAProxy/keepalived等相关应用。

    1> 集群 与 分布式

    2> 负载均衡

    3> 分布式相关的高可用、容灾等名词解释

    4> Mycat 中间件学习

     

    首先推荐4本书

    大型分布式网站架构设计与实践

    http://item.jd.com/11529266.html

    大型网站技术架构:核心原理与案例分析

    http://item.jd.com/11322972.html

    大型网站系统与Java中间件实践

    http://item.jd.com/11449803.html

    分布式Java应用:基础与实践

    http://item.jd.com/10144196.html

    貌似都是4位阿里人写的,一本一本的看吧,绝对会增强你的内功。


    分布式架构的演进

    初始阶段架构

    初始阶段 的小型系统 应用程序、数据库、文件等所有的资源都在一台服务器上通俗称为LAMP

    特征:
    应用程序、数据库、文件等所有的资源都在一台服务器上。

     

    应用服务和数据服务分离

    好景不长,发现随着系统访问量的再度增加,webserver机器的压力在高峰期会上升到比较高,这个时候开始考虑增加一台webserver

    特征:
    应用程序、数据库、文件分别部署在独立的资源上。

     

    使用缓存改善性能

    特征:
    数据库中访问较集中的一小部分数据存储在缓存服务器中,减少数据库的访问次数,降低数据库的访问压力。

    描述:
    系统访问特点遵循二八定律,即80%的业务访问集中在20%的数据上。
    缓存分为本地缓存和远程分布式缓存,本地缓存访问速度更快但缓存数据量有限,同时存在与应用程序争用内存的情况。


    作者:知乎用户
    链接:https://www.zhihu.com/question/22764869/answer/31277656
    来源:知乎
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
     

    使用应用服务器集群

    在做完分库分表这些工作后,数据库上的压力已经降到比较低了,又开始过着每天看着访问量暴增的幸福生活了,突然有一天,发现系统的访问又开始有变慢的趋势了,这个时候首先查看数据库,压力一切正常,之后查看webserver,发现apache阻塞了很多的请求,而应用服务器对每个请求也是比较快的,看来 是请求数太高导致需要排队等待,响应速度变慢

    特征:
    多台服务器通过负载均衡同时向外部提供服务,解决单台服务器处理能力和存储空间上限的问题。

    描述:
    使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源,提升系统的并发处理能力,使得服务器的负载压力不再成为整个系统的瓶颈。

     

    数据库读写分离

    享受了一段时间的系统访问量高速增长的幸福后,发现系统又开始变慢了,这次又是什么状况呢,经过查找,发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈,导致了系统变慢

    特征:
    多台服务器通过负载均衡同时向外部提供服务,解决单台服务器处理能力和存储空间上限的问题。

    描述:
    使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源,使得服务器的负载压力不在成为整个系统的瓶颈。

     

    反向代理和CDN加速

    特征:
    采用CDN和反向代理加快系统的 访问速度。

    描述:
    为了应付复杂的网络环境和不同地区用户的访问,通过CDN和反向代理加快用户访问的速度,同时减轻后端服务器的负载压力。CDN与反向代理的基本原理都是缓存。

     

    分布式文件系统和分布式数据库

    随着系统的不断运行,数据量开始大幅度增长,这个时候发现分库后查询仍然会有些慢,于是按照分库的思想开始做分表的工作

    特征:
    数据库采用分布式数据库,文件系统采用分布式文件系统。

    描述:
    任何强大的单一服务器都满足不了大型系统持续增长的业务需求,数据库读写分离随着业务的发展最终也将无法满足需求,需要使用分布式数据库及分布式文件系统来支撑。
    分布式数据库是系统数据库拆分的最后方法,只有在单表数据规模非常庞大的时候才使用,更常用的数据库拆分手段是业务分库,将不同的业务数据库部署在不同的物理服务器上。

     

    使用NoSQL和搜索引擎

    特征:
    系统引入NoSQL数据库及搜索引擎。

    描述:
    随着业务越来越复杂,对数据存储和检索的需求也越来越复杂,系统需要采用一些非关系型数据库如NoSQL和分数据库查询技术如搜索引擎。应用服务器通过统一数据访问模块访问各种数据,减轻应用程序管理诸多数据源的麻烦。


    作者:知乎用户
    链接:https://www.zhihu.com/question/22764869/answer/31277656
    来源:知乎
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
     

    业务拆分

    特征:
    系统上按照业务进行拆分改造,应用服务器按照业务区分进行分别部署。

    描述:
    为了应对日益复杂的业务场景,通常使用分而治之的手段将整个系统业务分成不同的产品线,应用之间通过超链接建立关系,也可以通过消息队列进行数据分发,当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。

    纵向拆分:
    将一个大应用拆分为多个小应用,如果新业务较为独立,那么就直接将其设计部署为一个独立的Web应用系统

    纵向拆分相对较为简单,通过梳理业务,将较少相关的业务剥离即可。

    横向拆分:将复用的业务拆分出来,独立部署为分布式服务,新增业务只需要调用这些分布式服务

    横向拆分需要识别可复用的业务,设计服务接口,规范服务依赖关系。

    分布式服务

    特征:
    公共的应用模块被提取出来,部署在分布式服务器上供应用服务器调用。

    描述:
    随着业务越拆越小,应用系统整体复杂程度呈指数级上升,由于所有应用要和所有数据库系统连接,最终导致数据库连接资源不足,拒绝服务。

    作者:知乎用户
    链接:https://www.zhihu.com/question/22764869/answer/31277656
    来源:知乎
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
     

    Q:分布式服务应用会面临哪些问题?

    A:
    (1) 当服务越来越多时,服务URL配置管理变得非常困难,F5硬件负载均衡器的单点压力也越来越大。
    (2) 当进一步发展,服务间依赖关系变得错踪复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师都不能完整的描述应用的架构关系。
    (3) 接着,服务的调用量越来越大,服务的容量问题就暴露出来,这个服务需要多少机器支撑?什么时候该加机器?
    (4) 服务多了,沟通成本也开始上升,调某个服务失败该找谁?服务的参数都有什么约定? 
    (5) 一个服务有多个业务消费者,如何确保服务质量?
    (6) 随着服务的不停升级,总有些意想不到的事发生,比如cache写错了导致内存溢出,故障不可避免,每次核心服务一挂,影响一大片,人心慌慌,如何控制故障的影响面?服务是否可以功能降级?或者资源劣化? 
     

    Java分布式应用技术基础

    分布式服务下的关键技术:消息队列架构

    消息对列通过消息对象分解系统耦合性,不同子系统处理同一个消息

    分布式服务下的关键技术:消息队列原理

    分布式服务下的关键技术:服务框架架构


    服务框架通过接口分解系统耦合性,不同子系统通过相同的接口描述进行服务启用
    服务框架是一个点对点模型
    服务框架面向同构系统
    适合:移动应用、互联网应用、外部系统
     

    分布式服务下的关键技术:服务框架原理

    分布式服务下的关键技术:服务总线架构

    服务总线同服务框架一样,均是通过接口分解系统耦合性,不同子系统通过相同的接口描述进行服务启用
    服务总线是一个总线式的模型
    服务总线面向同构、异构系统
    适合:内部系统
     

    分布式服务下的关键技术:服务总线原理

    分布式架构下系统间交互的5种通信模式

    request/response模式(同步模式):客户端发起请求一直阻塞到服务端返回请求为止。

    Callback(异步模式):客户端发送一个RPC请求给服务器,服务端处理后再发送一个消息给消息发送端提供的callback端点,此类情况非常合适以下场景:A组件发送RPC请求给B,B处理完成后,需要通知A组件做后续处理。

    Future模式:客户端发送完请求后,继续做自己的事情,返回一个包含消息结果的Future对象。客户端需要使用返回结果时,使用Future对象的.get(),如果此时没有结果返回的话,会一直阻塞到有结果返回为止。

    Oneway模式:客户端调用完继续执行,不管接收端是否成功。

    Reliable模式:为保证通信可靠,将借助于消息中心来实现消息的可靠送达,请求将做持久化存储,在接收方在线时做送达,并由消息中心保证异常重试。

    五种通信模式的实现方式-同步点对点服务模式

    五种通信模式的实现方式-异步点对点消息模式1

    五种通信模式的实现方式-异步点对点消息模式2

    五种通信模式的实现方式-异步广播消息模式

    分布式架构下的服务治理
    服务治理是服务框架/服务总线的核心功能。所谓服务治理,是指服务的提供方和消费方达成一致的约定,保证服务的高质量。服务治理功能可以解决将某些特定流量引入某一批机器,以及限制某些非法消费者的恶意访问,并在提供者处理量达到一定程度是,拒绝接受新的访问。

    基于服务框架Dubbo的服务治理-服务管理
    道你的系统,对外提供了多少服务,可以对服务进行升级、降级、停用、权重调整等操作
    可以知道你提供的服务,谁在使用,因业务需求,可以对该消费者实施屏蔽、停用等操作

    基于服务框架Dubbo的服务治理-服务监控


    可以统计服务的每秒请求数、平均响应时间、调用量、峰值时间等,作为服务集群规划、性能调优的参考指标。

    基于服务框架Dubbo的服务治理-服务路由

    基于服务框架Dubbo的服务治理-服务保护

    基于服务总线OSB的服务治理-功能介绍

    基于服务总线OSB的服务治理

    Q:Dubbo到底是神马?
    A:

    淘宝开源的高性能和透明化的RPC远程调用服务框架
    SOA服务治理方案

    Q:Dubbo原理是?
    A:

    -结束-

     

    原文地址:https://www.cnblogs.com/my376908915/p/6813321.html

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

    千次阅读 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
     

    展开全文
  • 分布式微服务架构体系详解

    万次阅读 多人点赞 2019-07-05 10:17:34
    虽然很多文章都说微服务架构是复杂的、会带来很多分布式的问题,但只要我们了解这些问题,并找到解法,就会有种拨开云雾的感觉。 微服务架构也不是完美的,世上没有完美的架构,微服务架构也是随着业务、团队成长而...

    课程介绍

    微服务架构的技术体系、社区目前已经越来越成熟。在最初系统架构的搭建,或者当现有架构已到达瓶颈需要进行架构演进时,很多架构师、运维工程师会考虑是否需要搭建微服务架构体系。虽然很多文章都说微服务架构是复杂的、会带来很多分布式的问题,但只要我们了解这些问题,并找到解法,就会有种拨开云雾的感觉。

    微服务架构也不是完美的,世上没有完美的架构,微服务架构也是随着业务、团队成长而不断演进的。最开始可能就几个、十几个微服务,每个服务是分库的,通过 API Gateway 并行进行服务数据合并、转发。随着业务扩大、不断地加入搜索引擎、缓存技术、分布式消息队列、数据存储层的数据复制、分区、分表等。

    本课程会一一解开微服务架构下分布式场景的问题,以及通过对于一些分布式技术的原理、模型和算法的介绍,来帮助想要实施微服务架构的工程师们知其然并知其所以然。并且,本课程通过对分布式问题的体系化梳理,结合一些方案的对比选型,可以让工程师们一览微服务的知识图谱。

    注:为了方便初学者理解微服务实践,以及掌握怎样在微服务中使用 DDD(Domain-Driven Design)思想,在本课程第 05 课中讲解了 Demo 示例,该示例是基于 Spring Boot、Spring Cloud Eureka 技术写的,Microservice 代码详见这里Gateway 代码详见这里

    专家推荐

    近年来随着互联网的快速发展,尤其是移动互联网以及云计算的迅猛发展,对于软件交付与迭代速度和效率的要求在不断提高。微服务架构凭借其简单清晰、灵活可扩展、独立部署等优势,越来越成为了分布式架构中的主流。相关的书籍和课程也层出不穷,但更多还是集中在基本理论介绍和一个简单的示例上。本系列课程内容融合了作者多年的实践经验,将微服务架构下的一些经典的分布式问题和场景逐一展开,结合最新的技术潮流,理论结合实际,深入剖析讲解,并且给出了很多对于具体实践选型非常有益的建议。可以说,该课程内容融合了作者从阿里巴巴到创业公司这一路走来所积累的精华,是微服务及分布式领域难得的佳作。

    ——阿里巴巴技术专家,荣博

    作者介绍

    李静瑶,2011 年毕业于中南大学(校优秀毕业生、优秀学生干部),毕业后入职阿里巴巴集团,在职期间主要负责淘宝网营销产品线的研发工作,曾担任试用中心产品线 PM。2015 年开始,在终点网络科技公司担任后端架构师,以及参与 Android、iOS 等客户端研发。现就职于赤金信息科技有限公司,担任 CTO 职位。从零搭建基于 Docker 容器技术的微服务分布式企业集群,深度的 DDD 思想践行者。个人博客:https://blog.csdn.net/lijingyao8206/

    课程内容

    导读:微服务架构下的分布式概览

    微服务架构的演变

    微服务是一种服务间松耦合的、每个服务之间高度自治并且使用轻量级协议进行通信的可持续集成部署的分布式架构体系。这一句包含了微服务的特点,微服务架构和其他架构有什么区别?以下对比一些常见的架构。

    单体架构

    单体架构是最简单的软件架构,常用于传统的应用软件开发以及传统 Web 应用。传统 Web 应用,一般是将所有功能模块都打包(jar、war)在一个 Web 容器(JBoss、Tomcat)中部署、运行。随着业务复杂度增加、技术团队规模扩大,在一个单体应用中维护代码,会降低开发效率,即使是处理一个小需求,也需要将所有机器上的应用全部部署一遍,增加了运维的复杂度。

    SOA 架构

    当某一天使用单体架构发现很难推进需求的开发、以及日积月累的技术债时,很多企业会开始做单体服务的拆分,拆分的方式一般有水平拆分和垂直拆分。垂直拆分是把一个应用拆成松耦合的多个独立的应用,让应用可以独立部署,有独立的团队进行维护;水平拆分是把一些通用的,会被很多上层服务调用的模块独立拆分出去,形成一个共享的基础服务,这样拆分可以对一些性能瓶颈的应用进行单独的优化和运维管理,也在一定程度上防止了垂直拆分的重复造轮子。

    SOA 也叫面向服务的架构,从单体服务到 SOA 的演进,需要结合水平拆分及垂直拆分。SOA 强调用统一的协议进行服务间的通信,服务间运行在彼此独立的硬件平台但是需通过统一的协议接口相互协作,也即将应用系统服务化。举个易懂的例子,单体服务如果相当于一个快餐店,所有的服务员职责都是一样的,又要负责收银结算,又要负责做汉堡,又要负责端盘子,又要负责打扫,服务员之间不需要有交流,用户来了后,服务员从前到后负责到底。SOA 相当于让服务员有职责分工,收银员负责收银,厨师负责做汉堡,保洁阿姨负责打扫等,所有服务员需要用同一种语言交流,方便工作协调。

    微服务和 SOA

    微服务也是一种服务化,不过其和 SOA 架构的服务化概念也是有区别的,可以从以下几个关键字来理解:

    • 松耦合:每个微服务内部都可以使用 DDD(领域驱动设计)的思想进行设计领域模型,服务间尽量减少同步的调用,多使用消息的方式让服务间的领域事件来进行解耦。
    • 轻量级协议:Dubbo 是 SOA 的开源的标准实现之一,类似的还有像 gRPC、Thrift 等。微服务更倾向于使用 Restful 风格的 API,轻量级的协议可以很好地支持跨语言开发的服务,可能有的微服务用 Java 语言实现,有的用 Go 语言,有的用 C++,但所有的语言都可以支持 Http 协议通信,所有的开发人员都能理解 Restful 风格 API 的含义。
    • 高度自治和持续集成:从底层的角度来说,SOA 更加倾向于基于虚拟机或者服务器的部署,每个应用都部署在不同的机器上,一般持续集成工具更多是由运维团队写一些 Shell 脚本以及提供基于共同协议(比如 Dubbo 管理页面)的开发部署页面。微服务可以很好得和容器技术结合,容器技术比微服务出现得晚,但是容器技术的出现让微服务的实施更加简便,目前 Docker 已经成为很多微服务实践的基础容器。因为容器的特色,所以一台机器上可以部署几十个、几百个不同的微服务。如果某个微服务流量压力比其他微服务大,可以在不增加机器的情况下,在一台机器上多分配一些该微服务的容器实例。同时,因为 Docker 的容器编排社区日渐成熟,类似 Mesos、Kubernetes 及 Docker 官方提供的 Swarm 都可以作为持续集成部署的技术选择。

    其实从架构的演进的角度来看,整体的演进都是朝着越来越轻量级、越来越灵活的应用方向发展,甚至到近两年日渐成熟起来的 Serverless(无服务)架构。从单体服务到分层的服务,再到面向服务、再到微服务甚至无服务,对于架构的挑战是越来越大。

    微服务架构和分布式

    微服务架构属于分布式系统吗?答案是肯定的。微服务和 SOA 都是典型的分布式架构,只不过微服务的部署粒度更细,服务扩展更灵活。

    理解微服务中的分布式

    怎样理解微服务中的分布式?举个招聘时某同学来面试的例子。A 同学说,目前所在公司在做从单应用到微服务架构迁移,已经差不多完成了。提到微服务感觉就有话题聊了,于是便问“是否可以简单描述下服务拆分后的部署结构、底层存储的拆分、迁移方案?”。于是 A 同学说,只是做了代码工程结构的拆分,还是原来的部署方式,数据库还是那个库,所有的微服务都用一个库,分布式事务处理方式是“避免”,尽量都同步调用……于是我就跟这位同学友好地微笑说再见了。

    微服务的分布式不仅仅是容器应用层面的分布式,其为了高度自治,底层的存储体系也应该互相独立,并且也不是所有的微服务都需要持久化的存储服务。一个“手机验证码”微服务可能底层存储只用一个 Redis;一个“营销活动搭建页面”微服务可能底层存储只需要一个 MongoDB。

    微服务中的分布式场景除了服务本身需要有服务发现、负载均衡,微服务依赖的底层存储也会有分布式的场景:为了高可用性和性能需要处理数据库的复制、分区,并且在存储的分库情况下,微服务需要能保证分布式事务的一致性。

    课程背景

    微服务架构的技术体系、社区目前已经越来越成熟,所以在初期选择使用或者企业技术体系转型微服务的时候,需要了解微服务架构中的分布式的问题:

    • 在所有服务都是更小单元的部署结构时,一个请求需要调动更多的服务资源,怎样获得更好的性能?
    • 当业务规模增大,需要有地理分布不同的微服务集群时,其底层的数据存储集群是多数据中心还是单数据集群?
    • 数据存储如何进行数据复制?
    • 业务数据达到大数据量时怎样进行数据的分区?
    • 分布式事务怎样保证一致性?
    • 不同程度的一致性有什么差别?
    • 基于容器技术的服务发现怎么处理?
    • 应该用哪些 RPC 技术,用哪些分布式消息队列来完成服务通信和解耦?
    • 那么多的分布式技术框架、算法、服务应该选哪个才适合企业的业务场景?

    本课程从微服务不得不面对和解决的分布式问题出发,包含分布式技术的一系列理论以及架构模型、算法的介绍,同时结合技术选型和实践应用,提供一系列解决方案的梳理。相信阅读完整个课程,你会对微服务的分布式问题有个系统地理解。本课程会对微服务的分布式场景问题一一击破,为你提供解决思路。

    课程内容

    本课程示例代码地址如下:

    分布式系统的问题

    • 引出分布式系统的可能问题:节点故障、网络延迟,结合错误检测的可行方案进行介绍;
    • 分布式中的时间和顺序的问题,以及标量时钟和向量时钟的实现。

    分布式数据存储

    • 分布式数据存储的技术选型、关系型数据库以及一些流行的 NoSQL 技术介绍(MongoDB、Redis、Neo4j 及 Cassandra 等);
    • 分布式存储技术使用的数据结构,了解底层数据存储原理(HashTable、SSTable、LSMTree、BTree 等);
    • 各个存储方案使用的场景以及对比。

    数据复制

    • 对于大规模存储集群,需要进行数据库的复制、排除单点故障;
    • 数据复制的模型和实现以及几种复制日志的实现方式;
    • 主备同步、主主复制、多数据中心的数据复制方案;
    • 数据复制中的读写一致性问题以及写冲突问题的解决;
    • 介绍以 MySQL 为例延伸集群数据复制方案。

    数据分区

    • 当单个领域模型维度的数据已经到一定规模时,需要进行数据分区,减轻单库压力。数据分区和分表又有哪些不同?数据分区可以如何实现?
    • 以 MySQL 的分区策略为例介绍不同分区策略的实现。
    • 数据分区后,请求的路由有哪些解决方案?会展开介绍不同的方案又有什么差别。

    服务发现和服务通信

    • 基于容器技术的微服务体系,怎样选择服务发现、负载均衡的技术实现?不同的服务发现的技术有什么区别,如何选型?
    • 为了达到松耦合的目的以及基于 DDD 思想,微服务之间减少服务调用可以通过哪些技术实现?API Gateway 可以用哪些技术框架实现?远程调用可以有哪些技术框架?怎样提高同步通信的性能?
    • 分布式的消息队列都有哪些开源、商业实现?应该怎样选择适合的消息队列?
    • 使用 DDD 思想应该如何应对服务通信,如何在实践中应用 DDD?

    分布式存储集群的事务

    • 理解分布式中的事务以及本地事务的基础概念;
    • 分布式存储的隔离级别以及各个 DB 支持的隔离方案的实现原理;
    • 以 MySQL InnoDB 中的 MVCC 为例看并发控制的在 MySQL 的实现,学习存储系统对于分布式事务的实现思想。

    分布式一致性

    • 了解分布式系统的一致性有哪些问题以及一致性的几种实现程度的模型:线性一致性(强一致性)、顺序一致性及因果一致性、最终一致性;
    • 分布式一致性相关的理论 CAP(CA、CP、AP 的相关算法)的介绍以及适合用于哪些实践;
    • 介绍 FLP 不可能结果,以及 BASE 理论。

    分布式事务实践

    • 了解微服务中分布式事务的问题;
    • 介绍强一致性的实践:二阶段、三阶段。2PC、3PC 的优缺点和限制,XA 协议的介绍和实践方案,以及最终一致性实践:TCC 模型和实践方案;
    • 分布式锁的实现模型和实践方案;
    • 基于微服务下的分布式事务实践案例分析。

    共识问题

    • 了解为什么分布式场景下有共识问题;
    • 介绍共识算法和全局消息广播的实现,公式算法的基础:leader 选举和 quorum 算法,以及一些已实现的算法的介绍和对比:VSR、Raft、Paxos、ZAB;
    • 共识算法在微服务体系的应用场景介绍:服务发现、一致性 kv 存储(Etcd、Zk)以及技术的选型如何权衡一致性的追求和性能。

    架构设计

    • 了解了很多分布式的问题和解决方案之后,回归微服务架构模型、技术选型、再回顾下微服务的弊端和特点;
    • 微服务体系的架构要素分析:安全、伸缩性、性能、可用性、扩展性;
    • 结合团队、业务场景的 DDD 实践和总结。

    课程寄语

    • 如果你是一位开发工程师,相信阅读完本系列课程,将会了解很多分布式系统的理论知识,同时也会理解一些分布式存储、中间件技术的原理,对工作中的分布式架构会有体系化的清晰认知。
    • 如果你是一位架构师,本系列课程提供了对于分布式系统问题的全面梳理,以及一些技术背后的理论,结合实践和目前业界先进的方案,对于技术选型和架构搭建提供了参考。

    点击了解更多《案例上手分布式微服务架构》

    第01课:分布式系统的问题

    前言

    无论是 SOA 或者微服务架构,都是必须要面对和解决一些分布式场景下的问题。如果只是单服务、做个简单的主备,那么编程则会成为一件简单幸福的事,只要没有 bug,一切都会按照你的预期进行。然而在分布式系统中,如果想当然的去按照单服务思想编程和架构,那可能会收获很多意想不到的“惊喜”:网络延迟导致的重复提交、数据不一致、部分节点挂掉但是任务处理了一半等。在分布式系统环境下编程和在单机器系统上写软件最大的差别就是,分布式环境下会有很多很“诡异”的方式出错,所以我们需要理解哪些是不能依靠的,以及如何处理分布式系统的各种问题。

    理想和现实

    微服务架构跟 SOA 一样,也是服务化的思想。在微服务中,我们倾向于使用 RESTful 风格的接口进行通信,使用 Docker 来管理服务实例。我们的理想是希望分布式系统能像在单个机器中运行一样,就像客户端应用,再坏的情况,用户只要一键重启就可以重新恢复,然而现实是我们必须面对分布式环境下的由网络延迟、节点崩溃等导致的各种突发情况。

    在决定使用分布式系统,或者微服务架构的时候,往往是因为我们希望获得更好的伸缩性、更好的性能、高可用性(容错)。虽然分布式系统环境更加复杂,但只要能了解分布式系统的问题以及找到适合自己应用场景的方案,便能更接近理想的开发环境,同时也能获得伸缩性、性能、可用性。

    分布式系统的可能问题

    分布式系统从结构上来看,是由多台机器节点,以及保证节点间通信的网络组成,所以需要关注节点、网络的特征。

    (1)部分失败

    在分布式环境下,有可能是节点挂了,或者是网络断了,如下图:

    part failure

    如果系统中的某个节点挂掉了,但是其他节点可以正常提供服务,这种部分失败,不像单台机器或者本地服务那样好处理。单机的多线程对象可以通过机器的资源进行协调和同步,以及决定如何进行错误恢复。但在分布式环境下,没有一个可以来进行协调同步、资源分配以及进行故障恢复的节点,部分失败一般是无法预测的,有时甚至无法知道请求任务是否有被成功处理。

    所以在开发需要进行网络通讯的接口时(RPC 或者异步消息),需要考虑到部分失败,让整个系统接受部分失败并做好容错机制,比如在网络传输失败时要能在服务层处理好,并且给用户一个好的反馈。

    (2)网络延迟

    网络是机器间通信的唯一路径,但这条唯一路径并不是可靠的,而且分布式系统中一定会存在网络延迟,网络延迟会影响系统对于“超时时间”、“心跳机制”的判断。如果是使用异步的系统模型,还会有各种环节可能出错:可能请求没有成功发出去、可能远程节点收到请求但是处理请求的进程突然挂掉、可能请求已经处理了但是在 Response,可能在网络上传输失败(如数据包丢失)或者延迟,而且网络延迟一般无法辨别。

    即使是 TCP 能够建立可靠的连接,不丢失数据并且按照顺序传输,但是也处理不了网络延迟。对于网络延迟敏感的应用,使用 UDP 会更好,UDP 不保证可靠传输,也不会丢失重发,但是可以避免一些网络延迟,适合处理音频和视频的应用。

    (3)没有共享内存、锁、时钟

    分布式系统的节点间没有共享的内存,不应理所当然认为本地对象和远程对象是同一个对象。分布式系统也不像单机器的情况,可以共享同一个 CPU 的信号量以及并发操作的控制;也没有共享的物理时钟,无法保证所有机器的时间是绝对一致的。时间的顺序是很重要的,夸张一点说,假如对于一个人来说,从一个时钟来看是 7 点起床、8 点出门,但可能因为不同时钟的时间不一致,从不同节点上来看可能是 7 点出门、8 点起床。

    在分布式环境下开发,需要我们能够有意识地进行问题识别,以上只是举例了一部分场景和问题,不同的接口实现,会在分布式环境下有不同的性能、扩展性、可靠性的表现。下面会继续上述的问题进行探讨,如何实现一个更可靠的系统。

    概念和处理模型

    对于上述分布式系统中的一些问题,可以针对不同的特征做一些容错和处理,下面主要看一下错误检测以及时间和顺序的处理模型。在实际处理中,一般是综合多个方案以及应用的特点。

    错误检测

    对于部分失败,需要一分为二的看待。

    节点的部分失败,可以通过增加错误检测的机制,自动检测问题节点。在实际的应用中,比如有通过 Load Balancer,自动排除问题节点,只将请求发送给有效的节点。对于需要有 Leader 选举的服务集群来说,可以引入实现 Leader 选举的算法,如果 Leader 节点挂掉了,其余节点能选举出新的 Leader。实现选举算法也属于共识问题,在后续文章中会再涉及到几种算法的实现和应用。

    网络问题:由于网络的不确定性,比较难说一个节点是否真正的“在工作”(有可能是网络延迟导致的错误),通过添加一些反馈机制可以在一定程度确定节点是否正常运行,比如:

    • 健康检查机制,一般是通过心跳检测来实现的,比如使用 Docker 的话,Consul、Eureka 都有健康检查机制,当发送心跳请求发现容器实例已经无法回应时,可以认为服务挂掉了,但是却很难确认在这个 Node/Container 中有多少数据被正确的处理了。
    • 如果一个节点的某个进程挂了,但是整个节点还可以正常运行。在使用微服务体系中是比较常见的,一台机器上部署着很多容器实例,其中个容器实例(即相当于刚才描述挂掉的进程)挂掉了,可以有一个方式去通知其他容器来快速接管,而不用等待执行超时。比如 Consul 通过 Gossip 协议进行多播,关于 Consul,可以参考这篇 Docker 容器部署 Consul 集群 内容。在批处理系统中,HBase 也有故障转移机制。

    在实际做错误检测处理时,除了需要 节点、容器 做出积极的反馈,还要有一定的重试机制。重试的实现可以基于网络传输协议,如使用 TCP 的 RTT;也可以在应用层实现,如 Kafka 的 at-least-once 的实现。基于 Docker 体系的应用,可以使用 SpringCloud 的 Retry,结合 Hytrix、Ribbon 等。对于需要给用户反馈的应用,不太建议使用过多重试,根据不同的场景进行判断,更多的时候需要应用做出积极的响应即可,比如用户的“个人中心页面”,当 User 微服务挂了,可以给个默认头像、默认昵称,然后正确展示其他信息,而不是反复请求 User 微服务。

    时间和顺序

    在分布式系统中,时间可以作为所有执行操作的顺序先后的判定标准,也可以作为一些算法的边界条件。在分布式系统中决定操作的顺序是很重要的,比如对于提供分布式存储服务的系统来说,Repeated Read 以及 Serializable 的隔离级别,需要确定事务的顺序,以及一些事件的因果关系等。

    物理时钟

    每个机器都有两个不同的时钟,一个是 time-of-day,即常用的关于当前的日期、时间的信息,例如,此时是 2018 年 6 月 23 日 23:08:00,在 Java 中可以用 System.currentTimeMillis() 获取;另一个是 Monotonic 时钟,代表着单调递增的时间,一般是测量时间间距,在 Java 中调用 System.nanoTime() 可以获得 Monotonic 时间,常常用于测量一个本地请求的返回时间,比如 Apache commons 中的 StopWatch 的实现。

    在分布式环境中,一般不会使用 Monotonic,测量两台不同的机器的 Monotonic 的时间差是无意义的。

    不同机器的 time-of-day 一般也不同,就算使用 NTP 同步所有机器时间,也会存在毫秒级的差,NTP 本身也允许存在前后 0.05% 的误差。如果需要同步所有机器的时间,还需要对所有机器时间值进行监控,如果一个机器的时间和其他的有很大差异,需要移除不一致的节点。因为能改变机器时间的因素比较多,比如无法判断是否有人登上某台机器改变了其本地时间。

    虽然全局时钟很难实现,并且有一定的限制,但基于全局时钟的假设还是有一些实践上的应用。比如 Facebook Cassandra 使用 NTP 同步时间来实现 LWW(Last Write Win)。Cassandra 假设有一个全局时钟,并基于这个时钟的值,用最新的写入覆盖旧值。当然时钟上的最新不代表顺序的最新,LWW 区分不了实际顺序;另外还有如 Google Spanner 使用 GPS 和原子时钟进行时间同步,但节点之间还是会存在时间误差。

    逻辑时钟

    在分布式系统中,因为全局时钟很难实现,并且像 NTP 同步过程,也会受到网络传输时间的影响,一般不会使用刚才所述的全局同步时间,当然也肯定不能使用各个机器的本地时间。对于需要确认操作执行顺序的时候,不能简单依赖一个基于 time-of-day 的 timestamps,所以需要一个逻辑时钟,来标记一些事件顺序、操作顺序的序列号。常见的方式是给所有操作加上递增的计数器。

    这种所有操作都添加一个全局唯一的序列号的方式,提供了一种全局顺序的保证,全局顺序也包含了因果顺序一致的概念。关于分布式一致性的概念和实现会在后续文章详细介绍,我们先将关注点回归到时间和顺序上。下面看两种典型的逻辑时钟实现。

    (1)Lamport Timestamps

    Lamport timestamps 是 Leslie Lamport 在 1978 年提出的一种逻辑时钟的实现方法。Lamport Timestamps 的算法实现,可以理解为基于每个节点的一对值(NodeId,Counter)的全局顺序的同步。在集群中的每个节点(Node)都有一个唯一标识,并且每个 Node 都持有一个本地的对于所有操作顺序的一个 Counter(计数器)。

    Lamport 实现的核心思想就是把事件分成三类(节点内处理的事件、发送事件、接收事件):

    • 如果一个节点处理一个事件,节点 counter +1。
    • 如果是发送一个消息事件,则在消息中带上 counter 值。
    • 如果是接收一个消息事件,则更新 counter = max(本地 counter,接收的消息中带的 counter) +1。

    简单画了个示例如下图:

    lamport timestamps example

    初始的 counter 都是 0,在 Node1 接收到请求,处理事件时 counter+1(C:1表示),并且再发送消息带上 C:1。

    在 Node1 接受 ClientA 请求时,本地的 Counter=1 > ClientA 请求的值,所以处理事件时 max(1,0)+1=2(C:2),然后再发送消息,带上 Counter 值,ClientA 更新请求的最大 Counter 值 =2,并在下一次对 Node2 的事件发送时会带上这个值。

    这种序列号的全局顺序的递增,需要每次 Client 请求持续跟踪 Node 返回的 Counter,并且再下一次请求时带上这个 Counter。lamport 维护了全局顺序,但是却不能更好的处理并发。在并发的情况下,因为网络延迟,可能导致先发生的事件被认为是后发生的事件。如图中红色的两个事件属于并发事件,虽然 ClientB 的事件先发出,但是因为延迟,所以在 Node 1 中会先处理 ClientA,也即在 Lamport 的算法中,认为 Node1(C:4) happens before Node1(C:5)。

    Lamport Timestamps 还有另一种并发冲突事件:不同的 NodeId,但 Counter 值相同,这种冲突会通过 Node 的编号的比较进行并发处理。比如 Node2(C:10)、Node1(C:10) 是两个并发事件,则认为 Node2 的时间顺序值 > Node1 的序列值,也就认为 Node1(C:10) happens before Node2(C:10)。

    所以可见,Lamport 时间戳是一种逻辑的时间戳,其可以表示全局的执行顺序,但是无法识别并发,以及因果顺序,并发情况无法很好地处理 偏序

    (2)Vector Clock

    Vector Clock 又叫向量时钟,跟 Lamport Timestamps 比较类似,也是使用 SequenceNo 实现逻辑时钟,但是最主要的区别是向量时钟有因果关系,可以区分两个并发操作,是否一个操作依赖于另外一个。

    Lamport Timestamps 通过不断把本地的 counter 更新成公共的 MaxCounter 来维持事件的全局顺序。Vector Clock 则各个节点维持自己本地的一个递增的 Counter,并且会多记录其他节点事件的 Counter。通过维护了一组 [NodeId,Counter] 值来记录事件的因果顺序,能更好得识别并发事件,也即,Vector Clock 的 [NodeId,Counter] 不仅记录了本地的,还记录了其他 Node 的 Counter 信息。

    Vector Clock 的 [NodeId,Counter] 更新规则:

    • 如果一个节点处理一个事件,节点本地的逻辑时钟的 counter +1。
    • 当节点发送一个消息,需要包含所有本地逻辑时钟的一组 [NodeId,Counter] 记录值。
    • 接受一个事件消息时, 更新本地逻辑时钟的这组 [NodeId,Counter] 值:
      • 让这组 [NodeId,Counter] 值中每个值都是 max(本地 counter,接收的消息中的counter)。
      • 本地逻辑时钟 counter+1。

    如下图简单示意了 Vector Clock 的时间顺序记录:

    Vector clock example

    三个 Node,初始 counter 都是 0。NodeB 在处理 NodeC 的请求时,记录了 NodeC 的 Counter=1,并且处理事件时,本地逻辑时钟的 counter=0+1,所以 NodeB 处理事件时更新了本地逻辑时钟为 [B:1,C:1]。在事件处理时,通过不断更新本地的这组 Counter,就可以根据一组 [NodeId,Counter] 值来确定请求的因果顺序了,比如对于 NodeB,第二个处理事件 [A:1,B:2,C:1] 早于第三个事件:[A:1,B:3,C:1]。

    在数值冲突的时候,如图中红色箭头标记的。NodeC 的 [A:2,B:2,C:3] 和 NodeB[A:3,B:4,C:1]。C:3 > C:1、B:2 < B:4,种情况认为是没有因果关系,属于同时发生。

    Vector Clock 可以通过各个节点的时间序列值的一组值,识别两个事件的先后顺序。Vector 提供了发现数据冲突的方式,但是具体怎样解决冲突需要由发现冲突的节点决定,比如可以将并发冲突抛给 Client 决定,或者用 Quorum-NRW 算法进行读取修复(Read Repair)。

    Amazon Dynamo 就是通过 Vector Clock 来做并发检测的一个很好的分布式存储系统的例子。对于复制节点的数据冲突使用了 Quorum NRW 决议,以及读修复(Read Repair)处理最新更新数据的丢失,详细实现可以参考这篇论文 Dynamo: Amazon’s Highly Available Key-value Store ,Dynamo 是典型的高可用、可扩展的,提供弱一致性(最终一致性)保证的分布式 K-V 数据存储服务。后续文章再介绍 Quorums 算法时,也会再次提到。Vector Clock 在实际应用中,还会有一些问题需要处理,比如如果一个上千节点的集群,那么随着时间的推移,每个 Node 将需要记录大量 [NodeId,Counter] 数据。Dynamo 的解决方案是通过添加一个 timestamp 记录每个 Node 更新 [NodeId,Counter] 值的时间,以及一个设定好的阈值,比如说阈值是 10,那么本地只保存最新的 10 个 [NodeId,Counter] 组合数据。

    小结

    本文引出了一些分布式系统的常见问题以及一些基础的分布式系统模型概念,微服务的架构目前已经被更广泛得应用,但微服务面临的问题其实也都是经典的分布式场景的问题。本文在分布式系统的问题中,主要介绍了关于错误检测以及时间和顺序的处理模型。

    关于时间和顺序的问题处理中,没有一个绝对最优的方案,Cassandra 使用了全局时钟以及 LWW 处理顺序判定;Dynamo 使用了 Vector clock 发现冲突,加上 Quorum 算法处理事件并发。这两个存储系统都有很多优秀的分布式系统设计和思想,在后续文章中会更详细的介绍数据复制、一致性、共识算法等。

    参考资料

    点击了解更多《案例上手分布式微服务架构》

    第02课:数据存储

    前言

    微服务架构下,很适合用 DDD(Domain-Drive Design)思维来设计各个微服务,使用领域驱动设计的理念,工程师们的关注点需要从 CRUD 思维中跳出来,更多关注通用语言的设计、实体以及值对象的设计。至于数据仓库,会有更多样化的选择。分布式系统中数据存储服务是基础,微服务的领域拆分、领域建模可以让数据存储方案的选择更具灵活性。

    不一定所有的微服务都需要有一个底层的关系型数据库作为实体对象实例的存储。以一个简单的电商系统为例:“用户微服务”和“商品微服务”都分别需要关系型数据库存储结构化的关联数据。但比如有一个“关联推荐微服务“需要进行用户购买、加购物车、订单、浏览等多维度的数据整合,这个服务不能将其他所有订单,用户、商品等服务的数据冗余进来,这种场景可以考虑使用图形数据库。又比如有一个“验证码微服务”,存储手机验证码、或者一些类似各种促销活动发的活动码、口令等,这种简单的数据结构,而且读多写少,不需长期持久化的场景,可以只使用一个 K-V(键值对)数据库服务。

    本文先简单介绍下适合微服务架构体系的一些分布式数据存储方案,然后深入介绍下这些存储服务的数据结构实现,知其然知其所以然。后续文章会继续介绍分布式数据存储的复制、分区。

    数据存储类型介绍

    不同的数据存储引擎有着不同的特征,也适合不同的微服务。在做最初的选型时,需要先根据对整体业务范围的判断,选择尽量普适于大多数微服务的存储。例如,初创型企业,需要综合考虑成本节约以及团队的知识掌握度等问题,MySQL 是比较常见的选择,电商类型的微服务应用更适合 InnoDB 引擎(事务、外键的支持、行锁的性能),虽然 InnoDB 的读性能会比 MyISAM 差,但是读场景有很多可以优化的方案,如搜索引擎、分布式缓存、本地缓存等。

    下面会以不同场景为例,整理一部分常用的数据存储引擎,实际的企业应用中会针对不同场景、服务特征综合使用多种存储引擎。

    关系型数据库

    存储结构化数据,以及需要更多维度关联,需要给用户提供丰富的实时查询场景时,应该使用关系型数据库。从开源以及可部署高可用性集群的方面来看,MySQLPostgreSQL 都是不错的选择。PostgreSQL 的历史更为悠久,两者都有很多大互联网公司如 Twitter、Facebook、Yahoo 等部署着大规模分布式存储集群,集群的复制、分区方案会在后续文章详细介绍。

    NoSQL

    NoSQL 即 Not Only SQL,其概念比关系型数据库更新,NoSQL 为数据的查询提供了更灵活、丰富的场景。下面简单列举了一些 NoSQL 数据库及其应用场景。工程师不一定需要掌握所有的 NoSQL 数据库的细节,对于不同的领域模型的设计,能有更多的灵感会更好。

    KeyValue 存储

    KeyValue 可以说是 NoSQL 中比较简单的一族,大多数操作只有 get()、put(),基础的数据格式也都是简单的 Key-Value。

    目前比较流行的键值存储服务有 RedisMemcached 以及上篇文中提到的 Dynamo。其中 Redis 有 Redis Cluster 提供了支持 Master 选举的高可用性集群。Dynamo 也有分布式高可用集群,基于 Gossip 协议的节点间故障检测,以及支持节点暂时、永久失效的故障恢复,这两者为了保证高可用以及性能,牺牲了强一致性的保证,但是都支持最终一致性。Memcached 提供了高性能的纯基于内存的 KV 存储,并且提供 CAS 操作来支持分布式一致性,但 Memcached 没有官方提供的内置集群方案,需要使用一些代理中间件,如 Magento 来部署集群。

    在实际选择时,如果需要高速缓存的性能并且可以接受缓存不被命中的情况,以及可以接受 Memcached 服务实例重启后数据全部丢失,可以选择 Memcached。用 Memcached 做二级缓存来抗住一些高 QPS 的请求是很适合的,比如对于一些 Hot 商品的信息,可以放到 Memcached 中,缓解 DB 压力。

    如果既需要有数据持久化的需求,也希望有好的缓存性能,并且会有一些全局排序、数据集合并等需求,可以考虑使用 Redis。Redis 除了支持 K-V 结构的数据,还支持 list、set、hash、zset 等数据结构,可以使用 Redis 的 SET key value 操作实现一些类似手机验证码的存储,对于需要按照 key 值排序的 kv 数据可以用 ZADD key score member。利用 Redis 的单线程以及持久化特性,还可以实现简单的分布式锁,具体可以参考笔者之前写的这篇 《基于 Redis 实现分布式锁实现》 文章。

    文档型数据库

    面向文档的数据库可以理解成 Value 是一个文档类型数据的 KV 存储,如果领域模型是个文件类型的数据、并且结构简单,可以使用文档型数据库,比较有代表性的有 MongoDBCouchDB。MongoDB 相比可用性,更关注一致性,Value 存储格式是内置的 BSON 结构,CouchDB 支持内置 JSON 存储,通过 MVCC 实现最终一致性,但保证高可用性。

    如果你需要的是一个高可用的多数据中心,或者需要 Master-Master,并且需要能承受数据节点下线的情况,可以考虑用 CouchDB。如果你需要一个高性能的,类似存储文档类型数据的 Cache 层,尤其写入更新比较多的场景,那就用 MongoDB 吧。另外,2018 年夏天可以期待下,MongoDB 官方宣布即将发布的 4.0 版本,支持跨副本集(Replica set)的 ACID 事务,4.2 版本将支持跨集群的事务,详情可以关注 MongoDB 的 Beta 计划

    图形数据库

    在现实世界中,一个图形的构成主要有“点”和“边”,在图形数据库中也是一样,只不过点和边有了抽象的概念,“点”代表着一个实体、节点,“边”代表着关系。开源的 Neo4j 是可以支持大规模分布式集群的图形数据库。一般被广泛用于道路交通应用、SNS 应用等,Neo4j 提供了独特的查询语言 CypherQueryLanguage

    为了直观了解 Neo4j 的数据结构,可以看下这个示例(在运行 Neo4j 后,官方的内置数据示例),图中绿色节点代表“Person”实体,中间的有向的剪头连线就是代表节点之间的关系“Knows”。

    eo4j example query

    通过以下 CQL 语句就可以查询所有 Knows、Mike 的节点以及关系:

    MATCH p=()-[r:KNOWS]->(g) where g.name ='Mike' RETURN p LIMIT 25 

    neo4j example res

    以上只是单个点和单维度关系的例子,在实际中 Person 实体间可能还存在 Follow、Like 等关系,如果想找到 Knows 并且 Like Mike,同时又被 Jim Follow 的 Person。在没有图形数据库的情况下,用关系型数据库虽然也可以查询各种关联数据,但这需要各种表 join、union,性能差而且需要写很多 SQL 代码,用 CQL 只要一行即可。

    在 SpringBoot 工程中,使用 Springboot-data 项目,可以很简单地和 Neo4j 进行集成,官方示例可以直接 checkout 查看 java-spring-data-neo4j

    文档数据库一般都是很少有数据间的关联的,图形数据库就是为了让你快速查询一切你想要的关联。如果想更进一步了解 Neo4j,可以直接下载 Neo4j 桌面客户端,一键启动、然后在浏览器输入 http://localhost:7474/browser/ 就可以用起来了。

    列族数据库

    列族数据库一般都拥有大规模的分布式集群,可以用来做灵活的数据分析、处理数据报表,尤其适合写多读少的场景。列族和关系型数据库的差别,从应用角度来看,主要是列族没有 Schema 的概念,不像关系型数据库,需要建表的时候定义好每个列的字段名、字段类型、字段大小等。

    列族数据库中目前比较广泛应用的有 Hbase,Hbase 是基于 Google BigTable 设计思想的开源版。BigTable 虽然没开源,但是其论文 Bigtable: A Distributed Storage System for Structured Data 提供了很多设布式列族 DB 的实现逻辑。另外 Facebook Cassandra 也是一个写性能很好的列族数据库,其参考了 Dynamo 的分布式设计以及 BigTable 的数据存储结构,支持最终一致性,适合跨地域的多数据中心的分布式存储。不过 Cassandra 中文社区相对薄弱,国内还是 Hbase 的集群更为广泛被部署。

    存储服务的数据结构

    在了解了一些分布式数据存储的产品之后,为了能更深地理解,下面会对分布式存储引擎的一些常用数据结构做进一步介绍。一台计算机,可以作为数据存储的地方就是内存、磁盘。分布式的数据存储就是将各个计算机(Node)的内存和磁盘结合起来,不同类型的存储服务使用的核心数据结构也会不同。

    哈希表

    哈希表是一种比较简单 K-V 存储结构,通过哈希函数将 Key 散列开,Key 哈希值相同的 Value 一般会以单链表结构存储。哈希表查找效率很高,常用于内存型存储服务如 Memcached、Redis。Redis 除了哈希表,因为其支持的操作的数据类型很多,所以还有像 Skiplist、SDS、链表等存储结构,并且 Redis 的哈希表结构可以通过自动再哈希进行扩容。

    哈希表一般存储在内存中,随着哈希表数据增多,会影响查询效率,并且内存结构也没法像磁盘那样可以持久化以及进行数据恢复。Redis 默认提供了 RDB 持久化方案,定时持久化数据到 RDB。用 RDB 来做数据恢复、备份是很合适的方案,但是因为其定期执行,所以无法保证恢复数据的一致性、完整性。Redis 还支持另一种持久化方案——基于 AOF(Append Only File) 方式,对每一次写操作进行持久化,AOF 默认不启用,可以通过修改 redis.conf 启用,AOF 增加了 IO 负荷,比较影响写性能,适合需要保证一致性的场景。

    SSTable

    在我们平常在 Linux 上分析日志文件的时候,比如用 grep、cat、tail 等命令,其实可以想象成在 Query 一个持久化在磁盘的 log 文件。我们可以用命令轻松查询以及分析磁盘文件,查询一个记录的时间复杂度是 O(n) 的话(因为要遍历文件),查询两个记录就是 2*O(n),并且如果文件很大,我们没法把文件 load 到内存进行解析,也没法进行范围查询。

    SSTable(Sorted String Table) 就解决了排序和范围查询的问题,SSTable 将文件分成一个一个 Segment(段),不同的 Segment File 可能有相同的值,但每个 Segement File 内部是按照顺序存储的。不过虽然只是将文件分段,并且按照内容顺序(Sorted String)存储可以解决排序,但是查询磁盘文件的效率是很低的。

    为了能快速查询文件数据,可以在内存中附加一个 KV 结构的索引:(key-offset)。key 值是索引的值并且也是有序的,Offset 指向 Segment File 的实际存储位置(地址偏移)。

    如下图简单画了一个有内存 KV 存储的 SSTable 数据结构:

    memtable sstable exm

    这个 k-v 结构的存储结构又叫 Memtable,因为 Memtable 的 key 也是有序的,所以为了实现内存快速检索,Memtable 本身可以使用红黑树、平衡二叉树、skip list 等数据结构来实现。Ps:B-Tree、B+Tree 的结构适合做大于内存的数据的索引存储(如 MySQL 使用 B+ 树实现索引文件的存储),所以其更适合磁盘文件系统,一般不会用来实现 Memtable。

    SSTable 也是有些局限性的,内存的空间是有限的,随着文件数越来越多,查询效率会逐渐降低。为了优化查询,可以将 Segment File 进行合并,减少磁盘 IO,并且一定程度持久化 Memtable(提高内存查询效率)——这就是 LSM-tree(Log-structured Merge-Tree)。LSM-tree 最初由 Google 发布的 Bigtable 的设计论文 提出,目前已经被广泛用于列族数据库如 HBase、Cassandra,并且 Google 的 LevelDB 也是用 LMS-tree 实现,LevelDB 的 Memtable 使用的是 skip list 数据结构。

    这种提供 SSTable 合并、压缩以及定期 flush Memtable 到磁盘的优化,使 LMS-tree 的写入吞吐量高,适合高写场景。下面以 Cassandra 为例介绍下 LMS-tree 的典型数据流。

    (1)Cassandra LMS-tree 写

    数据先写到 Commit Log 文件中(Commit Log 用 WAL 实现)WAL 保证了故障时,可以恢复内存中 Memtable 的数据。

    数据顺序写入 Memtable 中。

    随着 Memtable Size 达到一定阀值或者时间达到阀值时,会 flush 到 SSTable 中进行持久化,并且在 Memtable 数据持久化到 SSTable 之后,SSTables 都是不可再改变的

    后台进程会进行 SSTable 之间的压缩、合并,Cassendra 支持两种合并策略:对于多写的数据可以使用 SizeTiered 合并策略(小的、新的 SSTable 合并到大的、旧的 SSTable 中),对于多读的数据可以使用 Leveled 合并策略(因为分层压缩的 IO 比较多,写多的话会消耗 IO),详情可以参考 when-to-use-leveled-compaction

    (2)Cassandra LMS-tree 读

    先从 Memtable 中查询数据。

    Bloom Filter 中读取 SStable 中数据标记,Bloom Filter 可以简单理解为一个内存的 set 结构,存储着被“删除”的数据,因为刚才介绍到 SSTable 不能改变,所以一些删除之后的数据放到这个 set 中,读请求需要从这个标记着抛弃对象们的集合中读取“不存在”的对象,并在结果中过滤。对于 SSTables 中一些过期的,会在合并时被清除掉。

    从多个 SSTables 中读取数据。

    合并结果集、返回。另外,对于“更新”操作,是直接更新在 Memtable 中的,所以结果集会优先返回 Memtable 中的数据。

    BTree、B + Tree

    BTree 和 B + Tree 比较适合磁盘文件的检索,一般用于关系型数据库的索引数据的存储,如 Mysql-InnoDB、PostgreSQL。为了提高可用性,一般 DB 中都会有一个 append-only 的 WAL(一般也叫 redo-log)用来恢复数据,比如 MySQL InnoDB 中用 binlog 记录所有写操作,binlog 还可以用于数据同步、复制。

    使用 Btree、B+Tree 的索引需要每个数据都写两次,一次写入 redo-log、一次将数据写入 Tree 中对应的数据页(Page)里。LMS-tree 结构其实需要写入很多次,因为会有多次的数据合并(后台进程),因为都是顺序写入,所以写入的吞吐量更好,并且磁盘空间利用率更高。而 B 树会有一些空的 Page 没有数据写入、空间利用率较低。读取的效率来说,Btree 更高,同样的 key 在 Btree 中存储在一个固定的 Page 中,但是 LSM-tree 可能会有多个 Segment File 中存储着同个 Key 对应的值。

    小结

    本篇介绍了很多分布式存储服务,在实际的开发中,需要结合领域服务的特点选择。有的微服务可能只需要一个Neo4j,有的微服务只需要 Redis。微服务的架构应该可以让领域服务的存储更加灵活和丰富,在选择时可以更加契合领域模型以及服务边界。

    文章后半部分介绍了部分存储服务的数据结构。了解了实现的数据结构可以让我们更深刻理解存储引擎本身。从最简单的 append-only 的文件存储,再到哈希表、SSTable、BTree,基本涵盖了目前流行的存储服务的主流数据结构。如果想深入理解 LSM-tree,可以读一下 BigTable 的那篇经典论文。

    除了数据库服务,像 Lucene 提供了全文索引的搜索引擎服务,也使用了类似 SSTable 的结构。对于用 Docker 部署 Elasticsearch 集群的实践可以参考下之前写的 Elasticsearch 实践(一)用 Docker 搭建 Elasticsearch 集群Elasticsearch 实践(二)用 Docker 搭建 Elasticsearch 集群

    参考资料

    第03课:数据复制
    第04课:数据分区
    第05课:服务发现和服务通信
    第06课:分布式存储系统的事务
    第07课:分布式一致性
    第08课:分布式事务实践
    第09课:共识问题
    第10课:架构设计理念

    阅读全文: http://gitbook.cn/gitchat/column/5b444ae694c0f60b4ec4a68c

    展开全文
  • 传统架构到分布式架构

    千次阅读 2018-07-17 00:11:00
    架构拆分的演变:   1.传统项目的架构: 特点:  1) all in one(所有模块在一起,技术也不分层),  注:像05年06年那会儿,就是这样,把代码写在jsp里面,那时候还没有分层的概念,把所有的东西都写在...
  • 由于分布式系统所涉及到的领域众多,知识庞杂,很多新人在最初往往找不到头绪,不知道从何处下手来一步步学习分布式架构。 本文试图通过一个最简单的、常用的分布式系统,来阐述分布式系统中的一些基本问题。 ...
  • 分布式架构的漫谈

    千次阅读 2018-06-21 19:30:02
    一,计算机发展史概述   1946 年情人节(2.14) , 世界上第一台电子数字计算机诞生在美国宾夕法尼亚大学大学,它的名字是:ENIAC; 这台计算机占地170平米、重达30吨,每秒可进行5000次加法运算。...
  • 分布式架构概述及设计

    千次阅读 2019-08-15 21:50:06
    随着越来越多的人参与到互联网的浪潮来,曾经的单体应用架构越来越无法满足需求,所以,分布式集群架构出现,也因此,分布式搭建开发成为了Web开发者必掌握的技能之一。那什么是分布式呢?怎么实现分布式以及怎么...
  • 分布式架构的几种实现方式

    万次阅读 2018-07-27 08:51:48
    在开始说套路之前,大家先思考一个问题,为什么要进行分布式架构? 大多数的开发者大多数的系统可能从来没接触过分布式系统,也根本没必要进行分布式系统架构,为什么?因为在访问量或者QPS没有达到单台机器的性能...
  • 理解分布式服务架构

    千次阅读 2019-10-13 16:14:05
    分布式服务架构诞生背景: 在一个不断发展的大型应用中,新的业务需求和功能不断增加,技术也在不断演进,不同团队构建的功能子系统采用的技术架构五花八门,子系统之间的开发、部署和运维模式也存在较大差异。如果...
  • 分布式架构基本概念分布式架构及意义如何将应用从单机扩展到分布式大型分布式架构演进过程构建分布式架构的重要因素CDN加速静态文件访问分布式存储分布式搜索引擎应用发布与监控应用容灾及机房规划系统动态扩容...
  • 分布式架构设计详细流程:主要讲解分布式架构的发展流程,分布式架构详细设计以及分布式架构设计过程中需要的组件
  • 一、什么是分布式架构 1.不同的业务(功能模块)分散部署在不同的服务器 2.每个子系统负责一个或者多个不同的业务模块 3.服务之间可以相互交互与通信 4.分布式设计对用户透明 5.可以发展为集群分布式系统架构...
  • 银行核心系统如何应用分布式架构

    万次阅读 2018-07-25 11:16:14
    相对于主机集中式架构,以X86 和云计算为基础、以数据切分为特征的现代分布式架构在扩展性、低成本、降低运行风险等方面的优势明显,已经成为主流的联机交易系统架构方案。 3401 相对于主机集中式架构,以X86 和...
  • 数据库分布式架构巧设计

    千次阅读 2017-12-14 11:04:47
    数据库分布式架构巧设计 摘要: 在阿里云生态日,袋鼠云首席数据库架构师赵晓宏分享了《高容量大并发数据库服务——数据库分布式架构设计》。他从分布式需求、拆分原则、拆分难点及解决方案、数据库规范设计、...
  • 集群、分布式架构与SOA架构

    千次阅读 2019-05-15 16:38:45
    集群、分布式架构与SOA架构 1)传统开发 500并发量 存在的问题: 1、功能耦合度高 2、系统维护成本高 3、如果并发量大,无法解决高并发的问题 1000并发 存在的问题: 1、系统无法有效进行水平扩展...
  • (重点)深入理解Java分布式架构

    万次阅读 2018-01-18 17:33:13
    什么是分布式架构 分布式系统(distributed system)是建立在网络之上的软件系统。 内聚性是指每一个数据库分布节点高度自治,有本地的数据库管理系统。 透明性是指每一个数据库分布节点对用户的应用来说都是透明...
  • 分布式架构的演进过程(详细版)

    千次阅读 2018-05-24 14:10:02
    分布式架构的演进过程一.分布式架构的发展历史 1946年,世界上第一台电子计算机在美国的宾夕法尼亚大学诞生,它的名字是:ENICAC ,这台计算机的体重比较大,计算速度也不快,但是而代表了计算机时代的到来,再以后的...
  • 云计算分布式架构简介

    千次阅读 2018-09-02 18:42:46
    分布式架构设计相当于集中式架构。集中式机构是由一台或多台主机组成的中心节点。 简介集中式架构的优劣势: 优势:开发部署运维方便,事务处理方便,没有分布式协作。 劣势:可用性低,一旦服务器宕机,系统立即...
  • 分布式架构的实现

    2018-08-23 13:47:33
    分布式架构的实现   1、概述 在传统的B/S 架构的系统里,技术架构往往是一个工程项目,各个逻辑分层都是该工程的业务逻辑模块,但是有些网站,如电商系统或全国性服务平台,用户群庞大,网站并发量高,且需求...
1 2 3 4 5 ... 20
收藏数 396,224
精华内容 158,489
关键字:

分布式架构