架构设计

架构设计

部署方式

集中式

所谓集中式系统就是指由一台或多台主计算机组成中心节点，数据集中存储在这个中心节点中，并且整个系统的所有业务单元都集中部署在这个中心节点上，系统所有功能均有其集中处理。在集中式系统中，每个终端或客户端机器仅仅负责数据的录入和输出，而数据存储与控制处理完全由主机来完成。

集中式系统最大特点就是部署结构简单，集中式系统往往基于底层性能卓越的大型主机，因此无需考虑如何对服务进行多个节点的部署，也就不用考虑多个节点之间的分布式协作问题。

分布式

分布式系统定义：一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。

分布式通信

单播（点对点）

定义：单播在发送者和每一接收者之间实现点对点网络连接。如果一台发送者同时给多个接收者传输相同的数据，也必须相应的复制多份的相同数据包。如果有大量主机希望获得数据包的同一份拷贝时，将导致发送者负担沉重、延迟长、网络拥塞，为保证一定的服务质量需增加硬件和带宽。

单播优点：

1）服务器及时响应客户机的请求

2）服务器针对每个客户不同的请求发送不同的数据，容易实现个性化服务。

单播缺点：

1）服务器针对每个客户机发送数据流，服务器流量=客户机数量*客户机流量，在客户数量大、每个客户机流量大的流媒体应用中服务器不堪重负。

2）现有的网络带宽是金字塔结构，城际省际主干带宽仅仅相当于其所有用户带宽之和的5%。如果全部使用单播协议，将造成网络主干不堪重负。现在的P2P应用就已经使主干经常阻塞。而将主干扩展20倍几乎是不可能。

组播

组播在发送者和每一接收者之间实现点对点网络连接。如果一台发送者同时给多个的接收者传输相同的数据，也只需复制一份的相同数据包。它提高了数据传送效率，减少了骨干网络出现拥塞的可能性。

组播的优点：

1）需要相同数据流的客户端加入相同的组共享一条数据流，节省了服务器的负载。具备广播所具备的优点。

2）由于组播协议是根据接受者的需要对数据流进行复制转发，所以服务端的服务总带宽不受客户接入带宽的限制。IP协议允许有亿6千多万个组播，所以其提供的服务可以非常丰富。

3）此协议和单播协议一样允许在Internet宽带网上传输。

组播的缺点：
1）与单播协议相比没有纠错机制，发生丢包错包后难以弥补，但可以通过一定的容错机制和QOS加以弥补。
2）现行网络虽然都支持组播的传输，但在客户认证、QOS等方面还需要完善，这些缺点在理论上都有成熟的解决方案，只是需要逐步推广应用到现存网络当中。

IP网络的多播一般通过多播IP地址来实现。多播IP地址就是D类IP地址，即224.0.0.0至239.255.255.255之间的IP地址。IP组播地址前四位均为1110。
八位组（1） 八位组（2） 八位组（3） 八位组（4）
1110XXXX XXXXXXXX XXXXXXXX XXXXXXXX
单播可以看作仅包括一台机器群组的组播；广播可以看作包含了所有机器群组的组播.组播出现时间最晚但同时具备单播和广播的优点，最具有发展前景。

广播

广播是指在IP子网内广播数据包，所有在子网内部的主机都将受到这些数据包。广播意味着网络向子网每一个主机都投递一份数据包，不论这些主机是否乐于接收该数据包。所以广播的使用范围非常小，只在本地子网内有效，通过路由器和交换机网络设备控制广播传输。

广播的优点：

1）网络设备简单，维护简单，布网成本低廉

2）由于服务器不用向每个客户机单独发送数据，所以服务器流量负载极低。

广播缺点：

1）无法针对每个客户的要求和时间及时提供个性化服务

2）网络允许服务器提供数据的带宽有限，客户端的最大带宽=服务总带宽。

3）广播禁止允许在Internet宽带网上传输。

分布式存储

副本一致性

由于在大数据领域，数据的安全不再由硬件来保证，而是通过软件手段，通过同时将数据写入到多个副本中，来确保数据的安全。数据库在同时向多个副本写入记录时，如何确保每个副本数据一致，称为“数据一致性”

传统的关系型数据库对于运行环境–硬件要求都比较高，例如Oracle会建议用户使用小型机+共享存储作为数据库的运行环境，DB2 DPF也同样建议用户采用更好的服务器+高端存储来搭建数据库的运行环境。所以在数据存储安全的技术要求下，传统关系型数据库更多是依赖硬件的技术来保障数据的安全性。

因为关系型数据库的数据安全是基于硬件来保障，并且数据也不会通过同时存储多份来保障数据的安全，所以关系型数据库的用户默认认为数据存储是一致的。

---

分布式文件系统和分布式数据库基本上都是通过Multi-Paxos或者Raft分布式共识算法在多个数据副本之间同步事务提交日志。

当Leader被选举出来后，所有的事务操作都必须要经过Leader处理。这些事务操作成功后，将会被按顺序写入到LOG中，每个LOG都包含一个index编号。

日志复制主要的作用就是用来保证节点的数据一致性与高可用性。

分布式计算

分布式计算是一种计算方法，和集中式计算是相对的。

随着计算技术的发展，有些应用需要非常巨大的计算能力才能完成，如果采用集中式计算，需要耗费相当长的时间来完成。

分布式计算将该应用分解成许多小的部分，分配给多台计算机进行处理。这样可以节约整体计算时间，大大提高计算效率。

幂等性

保证多次调用接口返回结果的一致性。

实际场景：就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。

全局唯一ID

如果使用全局唯一ID，就是根据业务的操作和内容生成一个全局ID，在执行操作前先根据这个全局唯一ID是否存在，来判断这个操作是否已经执行。如果不存在则把全局ID，存储到存储系统中，比如数据库、redis等。如果存在则表示该方法已经执行。

从工程的角度来说，使用全局ID做幂等可以作为一个业务的基础的微服务存在，在很多的微服务中都会用到这样的服务，在每个微服务中都完成这样的功能，会存在工作量重复。另外打造一个高可靠的幂等服务还需要考虑很多问题，比如一台机器虽然把全局ID先写入了存储，但是在写入之后挂了，这就需要引入全局ID的超时机制。

使用全局唯一ID是一个通用方案，可以支持插入、更新、删除业务操作。但是这个方案看起来很美但是实现起来比较麻烦，下面的方案适用于特定的场景，但是实现起来比较简单。

---

UUID

UUID的全称是Universally Unique Identifier，通用唯一识别码。具体可以看维基百科的介绍：https://en.wikipedia.org/wiki/Universally_unique_identifier

UUID是一个128bit的数字，用于标志计算机的信息，虽然UUID不能保证绝对不重复，但重复的概率小到可以被忽略。UUID的生成没有什么规律，为了保证UUID的唯一性，规范定义了包括网卡MAC地址、时间戳、名字空间（Namespace）、随机或伪随机数、时序等元素，以及从这些元素生成UUID的算法。这也就意味着：

128bit，占据了太多的内存空间
生成的ID不是人可以看懂的
无法保证ID的递增，某些场景需要按前后排序 无法满足。

这是一个在线生成UUID的网站：https://www.uuidgenerator.net/ 你可以直观感受一下UUID。

---

Snowflake

这是Twitter的一个开源项目，它是一个分布式ID的生成算法，它会产生一个long类型的唯一ID，其核心算法是：

时间部分：41bit作为毫秒数，大概可以使用69.7年
机器编号部分：10bit作为机器编号，支持1024个机器实例。
毫秒内的序列号：12bit，一毫米可以生成4096个序列号

网上有各种语言实现的Snowflake算法的实现，有兴趣的阅读一下实现代码。

实际上，redis 或是 mongoDB 的全局ID生成器的算法和Snowflake算法大同小异。这是基于redis的分布式ID生成器实现：https://github.com/hengyunabc/redis-id-generator

它的核心思想是：

使用41 bit来存放时间，精确到毫秒，可以使用41年。
使用12 bit来存放逻辑分片ID，最大分片ID是4095
使用10 bit来存放自增长ID，意味着每个节点，每毫秒最多可以生成1024个ID

去重表

这种方法适用于在业务中有唯一标的插入场景中，比如在以上的支付场景中，如果一个订单只会支付一次，所以订单ID可以作为唯一标识。这时，我们就可以建一张去重表，并且把唯一标识作为唯一索引，在我们实现时，把创建支付单据和写入去去重表，放在一个事务中，如果重复创建，数据库会抛出唯一约束异常，操作就会回滚。

插入或更新

这种方法插入并且有唯一索引的情况，比如我们要关联商品品类，其中商品的ID和品类的ID可以构成唯一索引，并且在数据表中也增加了唯一索引。这时就可以使用InsertOrUpdate操作。在mysql数据库中如下：

insert into goods_category (goods_id,category_id,create_time,update_time)
values(#{goodsId},#{categoryId},now(),now())
on DUPLICATE KEY UPDATE
update_time=now()

多版本控制

这种方法适合在更新的场景中，比如我们要更新商品的名字，这时我们就可以在更新的接口中增加一个版本号，来做幂等

boolean updateGoodsName(int id,String newName,int version);

在实现时可以如下

	
update goods set name=#{newName},version=#{version} where id=#{id} and version<${version}

状态机控制

这种方法适合在有状态机流转的情况下，比如就会订单的创建和付款，订单的付款肯定是在之前，这时我们可以通过在设计状态字段时，使用int类型，并且通过值类型的大小来做幂等，比如订单的创建为0，付款成功为100。付款失败为99

在做状态机更新时，我们就这可以这样控制

update `order` set status=#{status} where id=#{id} and status<#{status}

非功能性需求

高可用

负载均衡

负载均衡方式

1. http重定向
2. dns域名解析（DNS:通过域名获取ip地址的手段）
3. 反向代理
4. IP层负载均衡
5. 链路层的负载均衡

上述五种方式详解

Nginx负载均衡的介绍

1. 轮询（按时间顺序）
2. 权重（指定每个服务的权重比例，weight和访问比率成正比）
3. iphash（访客固定一个后端服务）
4. 最少连接（连接的数量）
5. fair（最短响应时间）

Dubbo内置负载均衡策略

1. RandomLoadBalance:随机负载均衡。随机的选择一个。是Dubbo的默认负载均衡策略。
2. RoundRobinLoadBalance:轮询负载均衡。轮询选择一个。
3. LeastActiveLoadBalance:最少活跃调用数，相同活跃数的随机。活跃数指调用前后计数差。使慢的 Provider 收到更少请求，因为越慢的 Provider 的调用前后计数差会越大。
4. ConsistentHashLoadBalance:一致性哈希负载均衡。相同参数的请求总是落在同一台机器上

限流

限流指的是降低一定时间内的并发访问量 一般两种做法 一种是拉长时间，一种是降低访问QPS（）
一般开发高并发系统常见的限流有：限制总并发数（比如数据库连接池、线程池）、限制瞬时并发数（如nginx的limit_conn模块，用来限制瞬时并发连接数）、限制时间窗口内的平均速率（如Guava的RateLimiter、nginx的limit_req模块，限制每秒的平均速率）；其他还有如限制远程接口调用速率、限制MQ的消费速率。另外还可以根据网络连接数、网络流量、CPU或内存负载等来限流。

限流的必要性

随着应用的访问量越来越高，瞬时流量不可预估，为了保证服务对外的稳定性，限流成为每个应用必备的一道安全防火墙，即使普通的用户也会经常遇到，如微博的限流，抖音的限流，小米抢购的限流…如果没有这道安全防火墙，请求的流量超过服务的负载能力，很容易造成整个服务的瘫痪。
限流需要提前评估好，如果用的不当，可能会导致有些该限制的流量没有被限流，服务被这些过载流量打垮。有些不该限制流量的被限制，被用户抱怨。例如，整体服务的QPS是400/s,如果限流阀值是300，就会导致每秒有100个请求本该接受服务，却被限制访问，如果阀值是500，就会导致每秒有100个请求负载，时间越长累积越多，这些过载的流量就有可能导致整个服务的瘫痪。

限流算法

1、计数器算法

计数器算法是限流算法里最简单也是最容易实现的一种算法。比如我们规定，对于A接口来说，我们1分钟的访问次数不能超过100个。那么我们可以这么做：在一开 始的时候，我们可以设置一个计数器counter，每当一个请求过来的时候，counter就加1，如果counter的值大于100并且该请求与第一个 请求的间隔时间还在1分钟之内，那么说明请求数过多；如果该请求与第一个请求的间隔时间大于1分钟，且counter的值还在限流范围内，那么就重置 counter，具体算法的示意图如下：

但是有一个十分致命的问题，那就是临界问题，我们看下图：

从上图中我们可以看到，假设有一个恶意用户，他在0:59时，瞬间发送了100个请求，并且1:00又瞬间发送了100个请求，那么其实这个用户在 1秒里面，瞬间发送了200个请求。我们刚才规定的是1分钟最多100个请求，也就是每秒钟最多1.7个请求，用户通过在时间窗口的重置节点处突发请求， 可以瞬间超过我们的速率限制。用户有可能通过算法的这个漏洞，瞬间压垮我们的应用。改进方法滑动窗口算法。

2 滑动窗口

滑动窗口，又称rolling window。为了解决这个问题，我们引入了滑动窗口算法。如果学过TCP网络协议的话，那么一定对滑动窗口这个名词不会陌生。下面这张图，很好地解释了滑动窗口算法：

在上图中，整个红色的矩形框表示一个时间窗口，在我们的例子中，一个时间窗口就是一分钟。然后我们将时间窗口进行划分，比如图中，我们就将滑动窗口 划成了6格，所以每格代表的是10秒钟。每过10秒钟，我们的时间窗口就会往右滑动一格。每一个格子都有自己独立的计数器counter，比如当一个请求 在0:35秒的时候到达，那么0:30~0:39对应的counter就会加1。

那么滑动窗口怎么解决刚才的临界问题的呢？我们可以看上图，0:59到达的100个请求会落在灰色的格子中，而1:00到达的请求会落在橘黄色的格 子中。当时间到达1:00时，我们的窗口会往右移动一格，那么此时时间窗口内的总请求数量一共是200个，超过了限定的100个，所以此时能够检测出来触 发了限流。

我再来回顾一下刚才的计数器算法，我们可以发现，计数器算法其实就是滑动窗口算法。只是它没有对时间窗口做进一步地划分，所以只有1格。

由此可见，当滑动窗口的格子划分的越多，那么滑动窗口的滚动就越平滑，限流的统计就会越精确。

3、令牌桶算法

令牌桶算法是比较常见的限流算法之一，大概描述如下：
1）、所有的请求在处理之前都需要拿到一个可用的令牌才会被处理；
2）、根据限流大小，设置按照一定的速率往桶里添加令牌；
3）、桶设置最大的放置令牌限制，当桶满时、新添加的令牌就被丢弃或者拒绝；
4）、请求达到后首先要获取令牌桶中的令牌，拿着令牌才可以进行其他的业务逻辑，处理完业务逻辑之后，将令牌直接删除；
5）、令牌桶有最低限额，当桶中的令牌达到最低限额的时候，请求处理完之后将不会删除令牌，以此保证足够的限流；

4、漏桶算法

漏桶算法其实很简单，可以粗略的认为就是注水漏水过程，往桶中以一定速率流出水，以任意速率流入水，当水超过桶流量则丢弃，因为桶容量是不变的，保证了整体的速率。

两个算法实现一样，方向相反，令牌是匀速流入，漏桶是匀速流出。

基于Redis 实现限流

1、计数算法：
基于redis的incrby 加一和**decrby **操作，来控制分布式系统中计数器。

2、令牌桶算法：
基于 Redis 的 list接口可以实现令牌桶令牌补充和令牌消耗操作。

限流模块

使用最常见的就是Nginx自带两个限流模块：连接数限流模块ngx_http_limit_conn_module 和请求数限流模块ngx_http_limit_req_module；还有openresty的限流模块lua-resty-limit-traffic;

熔断

熔断：

熔断机制是应对雪崩效应的一种微服务链路保护机制。在微服务中，扇出的微服务不可用或者相应时间过长的话会对服务降级，进而熔断该服务节点，快速返回错误信息，释放资源。
而当检测到微服务响应正常后，则恢复调用。

隔离：

这种模式就像对系统请求按类型划分成一个个小岛的一样，当某个小岛被火烧光了，不会影响到其他的小岛。
例如可以对不同类型的请求使用线程池来资源隔离，每种类型的请求互不影响，如果一种类型的请求线程资源耗尽，则对后续的该类型请求直接返回，不再调用后续资源。
这种模式使用场景非常多，例如将一个服务拆开，对于重要的服务使用单独服务器来部署，再或者公司最近推广的多中心。

熔断设计

在熔断的设计主要参考了hystrix的做法。其中最重要的是三个模块：熔断请求判断算法、熔断恢复机制、熔断报警

1. 熔断请求判断机制算法：使用无锁循环队列计数，每个熔断器默认维护10个bucket，每1秒一个bucket，每个blucket记录请求的成功、失败、超时、拒绝的状态，默认错误超过50%且10秒内超过20个请求进行中断拦截。
2. 熔断恢复：对于被熔断的请求，每隔5s允许部分请求通过，若请求都是健康的（RT<250ms）则对请求健康恢复。
3. 熔断报警：对于熔断的请求打日志，异常请求超过某些设定则报警。

隔离设计

隔离的方式一般使用两种

1. 线程池隔离模式：使用一个线程池来存储当前的请求，线程池对请求作处理，设置任务返回处理超时时间，堆积的请求堆积入线程池队列。这种方式需要为每个依赖的服务申请线程池，有一定的资源消耗，好处是可以应对突发流量（流量洪峰来临时，处理不完可将数据存储到线程池队里慢慢处理）
2. 信号量隔离模式：使用一个原子计数器（或信号量）来记录当前有多少个线程在运行，请求来先判断计数器的数值，若超过设置的最大线程个数则丢弃改类型的新请求，若不超过则执行计数操作请求来计数器+1，请求返回计数器-1。这种方式是严格的控制线程且立即返回模式，无法应对突发流量（流量洪峰来临时，处理的线程超过数量，其他的请求会直接返回，不继续去请求依赖的服务）

降级

降级：

降级是指在某些高并发场景下，把某些非核心的业务统统往下调。诸如双11交易时，查看蚂蚁深林，蚂蚁庄园之类的服务，仅仅显示一百条数据。
当然降级的颗粒度 ，可以自由调配，根据实际业务和当前的服务器并发请求。比如说，你也可以限制数据库的跟新与插入，但是允许查询操作。
从RPC的角度来说，我访问的是本地服务的伪装者，而不是应用服务本身。

dubbo的降级方式： Mock 机制

重试

为网络或者其它原因，服务可能会暂时的不可用，这个时候我们希望可以再次对服务进行重试

soga

SOGA: 事件溯源。
什么时候使用这种模式

这种模式在以下几种场景中是最理想的解决方案：

当你想获得数据的“意图”，“目的”或者“原因”的时候。 例如，一个客户的实体改变可能用一系列的类似于”搬家“，”注销账户“或者”死亡“等事件类型。
并发更新数据时候非常需要减少或者完全避免冲突的时候。
当你需要保存已经发生的事件，并且能够重播他们来还原到某个状态、使用这些事件去回滚系统的某些变化或者仅仅是历史或者审查记录的时候。例如 ，当一个任务包括几个步骤，你可能需要执行一个撤销更新的操作然后重播过去的每个步骤来回到稳定的状态。
当使用事件是一些应用程序的某些操作的天然属性，并且需要很少的额外扩展或者实施的时候。
当你需要把插入，更新数据和需要执行这些操作的应用程序解耦开的时候。用这种模式可以提高UI的性能，或者把这些事件分发给其他的监听者，比如有些应用程序或系统，它们在一些事件发生的时候必须做出一些反应。例如，将一个工资系统和一个报销系统结合起来，这样的话当报销系统更新一个事件给事件数据库，数据库对此做出的相应事件就可以被报销系统和工资系统共享。
当要求变更或者——当和CQRS配合使用的时候——你需要适配一个读的模型或者视图来显示数据，而你想要更灵活地改变物化视图的格式和实体数据的时候。
当和CQRS配合使用的时候，并且当一个读模型被更新时能接受数据的最终一致性问题，或者说从一系列的事件序列中生成实体对性能的影响可以被接受。

这种模式在以下几种场景中可能并不适用：

小而简单的，业务逻辑简单或者根本没有业务逻辑，或者领域概念的，一般传统的增删改查（CURD）就能实现功能的业务领域，或者系统。
需要实时一致和实时更新数据的系统。
不需要审查，历史和回滚的系统。
并发更新数据可能性非常小的系统。例如，只增加数据不更新数据的系统。

高性能

池化

池化技术能够减少资源对象的创建次数，提高程序的性能，特别是在高并发下这种提高更加明显。使用池化技术缓存的资源对象有如下共同特点：

1. 对象创建时间长；
2. 对象创建需要大量资源；
3. 对象创建后可被重复使用。

延伸

为什么要使用数据库连接池
连接池的原理是什么
数据库连接池有哪些基本功能
HikariCP对连接池做了哪些优化


1、原先数据库连接效率过于低下，通过池化技术优化。
2、通过共享资源的方式管理连接，复用连接，优化内存以及网络连接消耗
3、提供、分发、创建、销毁、负载
4、FastStatementList代替Arraylist倒序遍历适应实际情况,并发时并发优化threadlocal,简化字节码(实现了FastList数据结构代替ArrayListJIT优化方法内联concurrentBag结构替代Queue结构内部采用了三层优化机制：1Threadloacl避免多线程竞争2CopyOnWriteArrayList多线程竞争通过CAS的方式抢占资源3SynchronousQueue进行阻塞性能优于LinkedBlockingQueue)

批处理

多级缓存

网络

CDN

CDN(Content Delivery Network)是指内容分发网络，也称为内容传送网络

CDN的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求

HTTP缓存

浏览器缓存分为强缓存和协商缓存，浏览器加载一个页面的简单流程如下：

• 浏览器先根据这个资源的http头信息来判断是否命中强缓存。如果命中则直接加在缓存中的资源，并不会将请求发送到服务器。
• 如果未命中强缓存，则浏览器会将资源加载请求发送到服务器。服务器来判断浏览器本地缓存是否失效。若可以使用，则服务器并不会返回资源信息，浏览器继续从缓存加载资源。
• 如果未命中协商缓存，则服务器会将完整的资源返回给浏览器，浏览器加载新资源，并更新缓存。

第一次请求:

第二次请求:

本地

寄存器

CPU<—>寄存器<----->内存

一级缓存

二级缓存

主内存

扩容

读写分离

读写分离是优化，例如优化慢查询，调整不合理的业务逻辑，引入缓存查询等只有确定系统没有优化空间后才考虑读写分离集群

集群

通过多台计算机完成同一个工作，达到更高的效率。
两机或多机内容、工作过程等完全一样。如果一台死机，另一台可以起作用。

可扩展

SOA

SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML（标准通用标记语言的子集）/Web Service技术之后的自然延伸

微服务

迭代方式

敏捷开发

敏捷开发

瀑布式开发

瀑布式开发

驱动方式

驱动方式

领域驱动

测试驱动

设计模式

1. 单库单应用模式：最简单的，可能大家都见过
2. 内容分发模式：目前用的比较多
3. 查询分离模式：对于大并发的查询、业务
4. 微服务模式：适用于复杂的业务模式的拆解
5. 多级缓存模式：可以把缓存玩的很好
6. 分库分表模式：解决单机数据库瓶颈
7. 弹性伸缩模式：解决波峰波谷业务流量不均匀的方法之一
8. 多机房模式：解决高可用、高性能的一种方法

详解