精华内容
参与话题
问答
  • 现在的架构很多,各种各样的,如高并发架构、异地多活架构、容器化架构、微服务架构、高可用架构、弹性化架构等,还有和这些架构相关的管理型的技术方法,如 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-07-27 08:51:48
    在开始说套路之前,大家先思考一个问题,为什么要进行分布式架构? 大多数的开发者大多数的系统可能从来没接触过分布式系统,也根本没必要进行分布式系统架构,为什么?因为在访问量或者QPS没有达到单台机器的性能...

    今天小蕉跟大伙一起聊聊分布式系统的架构的套路。在开始说套路之前,大家先思考一个问题,为什么要进行分布式架构?

    大多数的开发者大多数的系统可能从来没接触过分布式系统,也根本没必要进行分布式系统架构,为什么?因为在访问量或者QPS没有达到单台机器的性能瓶颈的时候,根本没必要进行分布式架构。那如果业务量上来了,一般会怎么解决呢?

    首先考虑的就是机器升级。机器配置的垂直扩展,首先要找到当前性能的瓶颈点,是CPU,是内存,是硬盘,还是带宽。砸钱加CPU,砸钱换SSD硬盘,砸钱换1T内存,这通常是解决问题最直接也最高效的方法。带宽不够?加带宽,1G不够用100G。CPU 8核不够?搞32核96核。这是绝大多数公司能思考到的第一个方案,也是最高效最快最安全的方法,立竿见影。

    其次就是系统拆分,将所提供服务的主流程以及支线流程梳理出来,按照流程进行系统拆分。如同一棵树,核心业务作为主干流程,其他系统按照需要进行拆分,如同树的开枝散叶。所采取的方式有这么一些,按前后端进行拆分,按照领域拆分,按团队拆分,当然通常来说这些拆分基本都要跟着组织架构走。

    再不行就进行技术升级,更换更加高效或者场景适合的技术。比如从 Oracle 更换到HBase。从A数据库连接池更换到B数据库连接池。技术的变革对于业务量的支持也是非常巨大的,同一台机器不同的技术,效能发挥的程度可以说有天壤之别。

    最后的最后手段才会考虑分布式架构,实在是砸不出这么多钱了,实在是没办法了。因为分布式架构肯定会带来非常多非常多的一致性问题,原本只需要访问一台机器,现在需要访问N台,那么这N台机器的一致性怎么保证,以前撑死搞个主从备份就算完了,定时同步一下数据就好,现在N台设备的数据怎么管理,甚至这个集群本身怎么管理,都会成为一个致命的问题。

    所以只有等业务量到达一定程度了,单台机器扛不住了,才会开始堆钱升级机器,系统拆分,换技术,继续堆钱升级机器,系统拆分...周而复始,发现成本太高或者技术已经到达上线了。最后没办法,就选择分布式架构了。

    但是分布式架构的优势也是明显的,用一群低廉的设备,来提供一个高性能高吞吐量的稳定的系统,下面开始说说常见的分布式集群的架构。

    1、纯负载均衡形式

    在集群前面,前置一个流量分发的组件进行流量分发,整个集群的机器提供无差别的服务,这在常见的 web 服务器中是最最常见的。目前比较主流的方式就是整个集群机器上云,根据实时的调用量进行云服务器弹性伸缩。常见的负载均衡有硬件层面的 F5、软件层面的 nginx 等。

    2、领导选举型

    整个集群的消息都会转发到集群的领导这里,是一种 master-slavers,区别只是这个 master 是被临时选举出来的,一旦 master 宕机,集群会立刻选举出一个新的领导,继续对外提供服务。使用领导选举型架构的典型的应用有 ElasticSearch,zookeeper。

    3、区块链型

    整个集群的每一个节点都可以进行记录,但是记录的内容要得到整个集群 N 个机器的认可才是合法的。典型的应用有 Bit Coin,以及 Hyperledger。

    4、master-slaver型

    整个集群以某台 master 为中枢,进行集群的调度。交互是这样,一般会把所有的管理类型的数据放到 master 上,而把具体的数据放到 slaver 上,实际进行调用的时候,client 先调用 master 获取数据所存放的 server 的 信息,再自行跟 slave 进行交互。典型的系统有 Hadoop。集群,HBase 集群,Redis 集群等。

    5、规则型一致性Hash

    这种架构类型一般出现在数据库分库分表的设计中。按照规则进行分库分表,在查询之前使用规则引擎进行库和表的确认,再对具体的应用进行访问。为什么要用一致性 Hash ?其实用什么都可以,只是对于这类应用来说一致性 Hash 比较常见而已。

    好了,至此,已经把我所知道的大部分分布式集群的套路说完了,总结一下。

    1、升级机器配置是最直接的升级方式。不到万不得已不会使用分布式

    2、分布式的核心就是业务拆分以及流量分发。

     

    原文:https://mp.weixin.qq.com/s?__biz=MzI1NDQ3MjQxNA==&mid=2247484852&idx=1&sn=9d900f39f777856e768441b0ef67b8f9&chksm=e9c5fc05deb27513dcab822e00d53769cca0f863210c77c3a46a858d2aabf8ccf50b3c43e18e&scene=21#wechat_redirect

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

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

    引言

    随着越来越多的人参与到互联网的浪潮来,曾经的单体应用架构越来越无法满足需求,所以,分布式集群架构出现,也因此,分布式搭建开发成为了Web开发者必掌握的技能之一。那什么是分布式呢?怎么实现分布式以及怎么处理分布式带来的问题呢?本系列文章就来源于对分布式各组件系统的学习总结,包含但不限于Zookeeper、Dubbo、消息队列(ActiveMQ、Kafka、RabbitMQ)、Nosql(Redis、MongoDB)、Niginx、分库分表MyCat、Netty等内容。作为跟大多数人一样的学习使用者,而非布道者,个人理解难免会有偏差或是其它错误,希望各位读者不吝指教。

    正文

    一、什么是分布式

    简单的说,“分工协作,专人做专事”就是分布式的概念。就好比你是你们公司唯一的码农,那么前后端都需要你自己来开发(单体架构),但随着业务的增长,你确实忙不过来了,老板给你招来了一个前端,那么你就只需要专注后端开发就行了(分布式)。但是软件的分布式搭建远远不像现实例子中这么简单,需要考虑和处理很多方面的问题,我们先了解以下几个常见的概念:

    • 集群:你们公司业务增长的非常快,老板发现你一个后端忙不过来了,就又招了几个后端开发来协助你,这就是后端集群;再往后,发现前端也忙不过来了,又配备几个前端,就是前端集群。所以也不难看出,将应用拆分后,你可以有针对性地扩展单个服务,做成集群,这就是分布式的好处之一。
    • 节点:这个也非常好理解,一个服务就是一个节点,比如你就是后端集群中的一个节点,而集群本身也可以看成是整个应用的一个集群节点。
    • 副本:副本就是为服务和数据提供的冗余,保证高可用。
    • 中间件:为开发者提供便利,屏蔽复杂的底层的一类框架组件。如服务管理通信、序列化、负载均衡等组件。
      在这里插入图片描述
      上图就是一个简单的分布式架构,但并不是所有的应用一开始就要设计为分布式架构,因为一开始业务量并不大,没有必要耗费大量的时间和成本去完成一个分布式架构,甚至有可能到最后都用不上,因此在设计时我们应该遵循演进原则,由简入深。下面就来简单分析一下分布式架构的演进过程。

    二、分布式架构的演化过程

    单机版

    以商城为例,为了简单说明,这里就只列出用户、订单、配送服务。
    在这里插入图片描述
    如图,大部分应用最开始都是将应用和数据库放到一台物理机上提供服务,但随着访问量的提升,服务器负载越来越高,我们首先会优化代码、对机器做垂直扩容(内存、容量)等,但单台机器的性能是存在上限的,且对单机扩容的性价比会随着性能的提升越来越低,那我们就会想到增加服务器。

    将应用服务器和数据库服务器分离

    在一开始,我们可能只会增加一台服务器,并将应用和数据库分离:
    在这里插入图片描述

    搭建应用服务器集群

    随着访问量的继续增加,单台应用服务器也无法满足需求了,我们就需要搭建应用服务器集群来对外提供服务了
    在这里插入图片描述
    但是,在搭建应用服务器集群之后,问题就出现了,用户在访问时,应该到哪个服务器上去?如何平均服务器压力?以及用户的session如何维护(A首先访问了1号应用服务器并登陆,但下次请求可能是去到2号服务器,但这台服务器上并没有用户的session信息)?
    我们可以在用户层和应用层之间加上一个负载均衡器来平衡服务器的负载,session可以采取同步的方式,或者增加单独的session共享服务器。

    数据库读写分离

    应用层的问题暂时解决了,但是此时数据库又顶不住了。那该如何做呢?只是简单的增加数据库的服务器拉提供存储和访问能力么?那肯定不行,这样数据就不一致了。所以我们需要将数据库分为读库和写库。查询请求都到读库去,而写入请求都到写库去。
    在这里插入图片描述
    但这样也存在几个问题:

    • 数据如何同步以及同步延迟如何处理?
    • 应用层数据源的选择
    • 大数据查询搜索,可以引入搜索引擎
    • 避免每次访问直接到达数据库,可以引入redis等缓存数据库缓存热点数据

    问题看似都解决了,但是每个数据库都存储的是同样的数据,随着业务继续扩大, 我们就不得不考虑对数据库做水平或垂直拆分:

    • 水平拆分:将同一个表中的数据拆分至多个数据库中
    • 垂直拆分:将不同业务的数据放到不同的数据库中
      在这里插入图片描述

    应用拆分

    业务继续增长,数据库达到瓶颈时可以继续增加服务器解决,但是应用层呢?也只是单纯的增加服务器么?基于二八原则,其实大部分访问量是集中在20%的功能上的,如果我们只是单纯的增加服务器,那么无疑会浪费掉许多的资源,所以我么会想到能不能针对这20%的应用做扩展呢?当然是可以的,只不过我们需要先将应用拆分为多个子系统(一般是根据业务):
    在这里插入图片描述
    随着应用拆分随之而来的问题是,公用的代码如何处理?各服务之间如何通信?公用代码我们不可能放到每个服务中去,而是应该提出来对外提供服务,同时服务之间的调用可以通过RPC或者HTTP方式来实现。

    演化至此,这样的架构就是一个成熟的分布式架构了,但是,架构还是会随着业务和技术的提升不停地演化;而此时你有没有发现这样的一个架构和冯诺伊曼结构很像呢!输入输出设备对应用户和服务之间的输入输出,数据库服务器就像是存储设备,而整个应用层就像是一个CPU(控制器、运算器)。所以,分布式架构可以简单的理解为将多台计算机组成的一台超级计算机。

    三、分布式架构的设计

    在设计分布式架构时,我们需要了解几个基本的概念。

    • 主流架构模型-SOA和微服务
    • CAP和BASE理论
    • DDD(领域驱动设计)

    这些理论限于篇幅原因,这里就不展开详述,读者可自行查阅。下面主要来谈谈分布式架构的高可用设计。

    分布式架构的高可用设计

    在分布式架构中,常常面临的两个矛盾的问题是一致性高可用,这两个是无法同时满足的,那我们舍谁取谁呢?从用户的角度分析,我们宁可获取到旧数据,也不愿意等半天都打不开应用,所以常常是保证高可用,让数据达到最终一致性,那么如何设计高可用的分布式架构呢?主要从以下几个方面:

    • 搭建服务集群,提高负载,避免单点故障。尤其是特别重要的服务,如访问量较高的服务和核心服务(一旦挂掉就会导致整个应用不可用的服务)。
    • 应对灾难,搭建异地灾备,预防地区因发生地震、台风等自然灾害导致地区的集群服务器都不可用。
    • 接口限流以及服务降级。为防止过高的并发量造成服务器负载过高而出现故障,应对接口限流,同时,当某个或多个服务出现故障时,应当服务降级,避免拖累整个应用。比如支付时因网络故障等导致无法支付,但搜索商品和下单仍然可用。
    • 故障监控报警。
    • 服务的可伸缩性,易于水平扩张服务器数量。
    • 使用缓存降低数据库压力。
    • 使用CDN等加速静态资源的访问。

    高可用的分布式架构需要考虑非常多的方面,针对不同的场景有不同的解决方案,而对于不同的公司而言也不需要一应俱全,需要在实践中多思考总结,根据自己的业务情况来设计。

    总结

    本文从理论层面讲述了分布式的基本概念、演化过程,以及设计,从宏观角度搞清楚分布式的起源以及分布式带来的一系列问题,也就能明白各项技术出现的原因以及应用的场景。

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

    千次阅读 2018-11-01 16:14:23
    一,主流架构模型 SOA架构和微服务架构 SOA架构  SOA全称(Service Oriented Architecture) 中文意思是"面向服务的架构",他是一种设计方法,其中包含多个服务,服务之间通过相互依赖最终提供一系列的...
  • 分布式架构:原理,设计与实战,目前公司每个月都要出账,出账就是每个月有要把之前的一个月的账目盘算清楚,做到错误的0容忍,一笔都不能错,错一笔客户都会找你,偏准确性。4个9,5个9并不是说后面设计的,而是在...
  • 1.现在项目架构的特点 2.集群相关说明 3.集群部署的两个问题解决: 使用redis服务器存储session 使用nginx服务器分发请求 4.面向服务的分布式架构
  • 本文以淘宝作为例子,介绍从一百个到千万级并发情况下服务端的架构的演进过程,同时列举出每个演进阶段会遇到的相关技术,让大家对架构的演进有一个整体的认知,文章最后汇总了一些架构设计的原则。 特别说明:本文...
  • 传统架构到分布式架构

    万次阅读 多人点赞 2018-07-17 00:11:00
    架构拆分的演变:   1.传统项目的架构: 特点:  1) all in one(所有模块在一起,技术也不分层),  注:像05年06年那会儿,就是这样,把代码写在jsp里面,那时候还没有分层的概念,把所有的东西都写在...
  • 理解分布式服务架构

    千次阅读 2019-05-14 15:42:46
    分布式服务架构诞生背景: 在一个不断发展的大型应用中,新的业务需求和功能不断增加,技术也在不断演进,不同团队构建的功能子系统采用的技术架构五花八门,子系统之间的开发、部署和运维模式也存在较大差异。如果...
  • 分布式微服务架构体系详解

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

    千次阅读 2017-11-26 23:51:17
    什么是分布式架构 分布式系统(distributed system)是建立在网络之上的软件系统。 内聚性是指每一个数据库分布节点高度自治,有本地的数据库管理系统。 透明性是指每一个数据库分布节点对用户的应用来说都...
  • 上一篇博客简单介绍了分布式的发展历史和基本概念本篇博客则将以电商系统为例,详细介绍分布式发展的过程假设我们的电商系统中只有三个模块:用户模块,交易模块和商品模块阶段一:单应用架构在网站创建初期,经常把...
  • 分布式架构知识体系

    万次阅读 2019-02-15 09:04:01
    点击上方“方志朋”,选择“置顶或者星标”你的关注意义重大!1.问题1、何为分布式何为微服务?2、为什么需要分布式?3、分布式核心理论基础,节点、网络、时间、顺序,一致性?...
  • java分布式(分布式架构

    千次阅读 2020-01-29 10:02:08
    开头的话,架构多半和业务关联在一起,如果只是简单的图书管理系统、选课系统或者什么简单的财务系统,用不着分布式。只有大型公司、高并发的业务才需要分布式的帮助。当然,架构本身要和业务模型紧密配合才能发挥...
  • 你一定要知道的分布式架构演化史|干货满满

    千次阅读 多人点赞 2020-05-12 15:40:52
    分布式架构的发展壮大正是一批批程序员前赴后继,遇到问题并解决问题,不断迭代得到的技术成果,为所有程序员点赞!
  • 一、什么是分布式架构 1.不同的业务(功能模块)分散部署在不同的服务器 2.每个子系统负责一个或者多个不同的业务模块 3.服务之间可以相互交互与通信 4.分布式设计对用户透明 5.可以发展为集群分布式系统架构...
  • 分布式架构与SOA

    万次阅读 多人点赞 2018-01-22 10:40:27
    分布式系统  分布式系统是一个硬件或软件组件分布在不同的网络计算机上,彼此之间仅仅通过消息传递和协调的系统。  简单来说,就是一群独立计算机集合共同对外提供服务,但是对于系统用户来说,就像是一台计算机...
  • 初识分布式架构及意义

    千次阅读 2018-08-07 17:05:46
    分布式的处理方式越来越受到业界的青睐——计算机系统正在经历一场前所未有的从集中式向分布式架构的变革。 集中式与分布式 集中式系统 所谓的集中式系统就是指由一台或多台主计算机组成中心节点,数据集中存储于...
  • 分布式架构的漫谈

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

空空如也

1 2 3 4 5 ... 20
收藏数 414,583
精华内容 165,833
关键字:

分布式架构