分布式系统架构设计

系统后期

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返回给用户

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