转载

分布式系统架构设计

编辑推荐:

文章主要介绍了主流架构模型: SOA架构和微服务架构及分布式架构的基本理论 CAP，BASE 以及应用。

来自于csdn，,由火龙果软件Anna编辑、推荐。

主流架构模型 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中

分布式系统架构设计