【微服务】—— 微服务组件基本介绍

1. Nacos

【微服务】—— Nacos安装指南
【微服务】—— Nacos设计原理
【微服务】—— Nacos注册中心

1.1 Nacos介绍

• Nacos是Spring Cloud Alibaba架构中最重要的组件。
• Nacos是一个更易于帮助构建云原生应用的动态服务发现、配置和服务管理平台，提供注册中心、配置中心和动态 DNS 服务三大功能。能够无缝对接Spring Cloud、Spring、Dubbo等流行框架。
• nacos和eureka功能对比
  
• nacos支持a（高可用）p（分区容错）和c（一致性）p的切换，默认为ap，eureka仅支持ap，zookeeper仅支持cp

补充

1）CAP理论

Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致

Availability （可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝

Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。
Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务

2）BASE理论

BASE理论是对CAP的一种解决思路，包含三个思想：

• Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
• Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
• Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。
  而分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论：
• AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
• CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态

1.2 nacos能做什么？

• 服务注册发现和服务健康监测：
    Nacos支持基于DNS和基于RPC的服务发现，服务端可以通过SDK或者API进行服务注册，相应的服务消费者可以使用DNS或者Http查找的方式获取服务列表。Nacos同时提供对服务的实时健康检查，阻止向不健康的主机或服务发送请求，与Eureka类似，Nacos也有友好的控制台界面。
• 动态DNS服务：
    支持权重路由，更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务。
• 动态配置服务：
    Nacos支持动态的配置管理，将服务的配置信息分环境分类别外部管理，并且支持热更新。Nacos的配置信息存储在数据库中，支持配置信息的监听和版本回滚。
• 服务及元数据管理：
    Nacos 能让您从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的 SLA （服务等级协议）以及最首要的 metrics 统计数据（默认不开启暴露需要修改配置）。可以搭建搭建prometheus采集Nacos metrics数据也可以搭建搭建grafana图形化展示metrics数据

1.3 引入配置中心为了什么？

• 配置属性的动态刷新
• 配置文件的集中管理

1.4 Nacos心跳机制

心跳:周期性的操作，来表示自己是健康可用的机制
注册到Nacos的微服务项目(模块)都是会遵循这个心跳机制的
心跳机制的目的：
1.是表示当前微服务模块运行状态正常的手段
2.是表示当前微服务模块和Nacos保持沟通和交换信息的机制
默认情况下,服务启动开始每隔5秒会向Nacos发送一个"心跳包",这个心跳包中包含了当前服务的基本信息
Nacos接收到这个心跳包,首先检查当前服务在不在注册列表中,如果不在按新服务的业务进行注册,如果在,表示当前这个服务是健康状态
如果一个服务连续3次心跳(默认15秒)没有和Nacos进行信息的交互,就会将当前服务标记为不健康的状态
如果一个服务连续6次心跳(默认30秒)没有和Nacos进行信息的交互,Nacos会将这个服务从注册列表中剔除
这些时间都是可以通过配置修改的

2. Seata

【微服务】——分布式事务Seata
【微服务】—— Seata 的部署和集成

什么是分布式事务

2.1 Seata介绍

Seata是一款开源的分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务，为用户打造一站式的分布式解决方案。

2.2 分布式事务的相关概念

分布式事务处理过程的一ID+三组件模型，一ID即Transaction ID XID，全局唯一的事务ID。
三组件：
1.TC (Transaction Coordinator) - 事务协调者
维护全局和分支事务的状态，协调全局事务提交或回滚。
2.TM (Transaction Manager) - 事务管理器
定义全局事务的范围、开始全局事务、提交或回滚全局事务。
3.RM (Resource Manager) - 资源管理器
管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

Seata提供了四种不同的分布式事务解决方案：

• XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
• TCC模式：最终一致的分阶段事务模式，有业务侵入
• AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式
• SAGA模式：长事务模式，有业务侵入

3. Dubbo

3.1 Dubbo概述

Dubbo是阿里巴巴开源的基于 Java 的高性能RPC（一种远程调用） 分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

3.2 为什么要用Dubbo？

随着服务化的进一步发展，服务之间的调用和依赖关系也越来越复杂，诞生了面向服务的框架体系（SOA），也因此衍生出了一系列相应的技术，如对服务提供、服务调用、连接处理、通性协议、序列号方式、服务发现、服务路由、日志输出等行为进行封装的服务框架。就这样分布式系统的服务治理的框架就出现了，Dubbo就这样产生了，它实现了面向接口代理的 RPC 调用，服务注册和发现，负载均衡，容错，扩展性等等功能。

内部使用了Netty、Zookeeper，保证了高性能高可用性。
使用Dubbo可以将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，可用于提高业务复用灵活扩展，使前端应用能更快速的响应多变的市场需求。
分布式架构可以承受更大规模的并发流量。

3.3 Dubbo优缺点

优点（Dubbo能做什么）

• 透明化的远程方法调用，像调用本地方法一样调用远程方法；只需简单配置，没有任何API侵入。
• 软负载均衡及容错机制，可在内网替代nginx lvs等硬件负载均衡器。
• 服务注册中心自动注册和配置管理，不需要写死服务提供者地址，注册中心基于接口名自动查询提供者ip地址，并且能够平滑添加或删除服务提供者。
• 服务接口监控与治理，Dubbo-admin与Dubbo-monitor提供了完善的服务接口管理与监控功能，针对不同应用的不同接口，可以进行 多版本，多协议，多注册中心管理。

Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。

缺点

• 只支持JAVA语言

4. Sentinel

【微服务】—— 初识Sentinel
【微服务】—— Sentinel限流

4.1 什么是Sentinel

Sentinel 是一款面向分布式服务架构的轻量级流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统自适应保护等多个维度来保障服务的稳定性，核心思想是：根据对应资源配置的规则来为资源执行相应的流控/降级/系统保护策略，Sentinel 的主要特性如下图：

4.2 为什么需要Sentinel

为了保证服务器运行的稳定性,在请求数到达设计最高值时,将过剩的请求限流,保证在设计的请求数内的请求能够稳定完成处理

4.3 Sentinel 特征:

• 丰富的应用场景 ：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即
  突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
• 完备的实时监控 ：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机
  器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。
• 广泛的开源生态 ：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring
  Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入Sentinel。
• 完善的 SPI 扩展点：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快
  速地定制逻辑。例如定制规则管理、适配动态数据源等。

4.4 主流限流熔断组件对比：

5. Gateway

【微服务】—— 统一网关Gateway

5.1 什么是Gateway

Spring Cloud Gateway是Spring官方基于Spring 5.0，Spring Boot 2.0和Project Reactor等技术开发的网关，Spring Cloud Gateway旨在为微服务架构提供一种简单而有效的统一的API路由管理方式。Spring Cloud Gateway作为Spring Cloud生态系中的网关，目标是替代ZUUL，其不仅提供统一的路由方式，并且基于Filter链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。

5.2 什么是网关

网关:就是指网络中的关口\关卡
网关就是当前微服务项目的"统一入口"
程序中的网关就是当前微服务项目对外界开放的统一入口
所有外界的请求都需要先经过网关才能访问到我们的程序
提供了统一入口之后,方便对所有请求进行统一的检查和管理

网关的主要功能有

• 将所有请求统一经过网关

• 网关可以对这些请求进行检查
• 网关方便记录所有请求的日志
• 网关可以统一将所有请求路由到正确的模块\服务上

5.3 为什么需要Gateway

Gateway网关是我们服务的守门神，所有微服务的统一入口。
网关的核心功能特性：

• 请求路由
• 权限控制
• 限流
  

权限控制：网关作为微服务入口，需要校验用户是是否有请求资格，如果没有则进行拦截。

路由和负载均衡：一切请求都必须先经过gateway，但网关不处理业务，而是根据某种规则，把请求转发到某个微服务，这个过程叫做路由。当然路由的目标服务有多个时，还需要做负载均衡。

限流：当请求流量过高时，在网关中按照下流的微服务能够接受的速度来放行请求，避免服务压力过大。

5.4 主流网关的对比与选型

5.5 Gateway三大核心概念

• Route(路由)
  路由是构建网关的基本模块，它由ID，目标URI，一系列的断言和过滤器组成，如果断言为true则匹配该路由

• Predicate(断言)
  参考的是Java8的java.util.function.Predicate开发人员可以匹配HTTP请求中的所有内容(例如请求头或请求参数)，如果请求与断言相匹配则进行路由

• Filter(过滤)
  指的是Spring框架中GatewayFilter的实例，使用过滤器，可以在请求被路由前或者之后对请求进行修改。

6. Elasticsearch

【ElasticSearch】—— 初识ES

6.1 ElasticSearch的简介

ElasticSearch：智能搜索，分布式的搜索引擎
是ELK的一个组成,是一个产品，而且是非常完善的产品，ELK代表的是：E就是ElasticSearch，L就是Logstach，K就是kibana
E：EalsticSearch 搜索和分析的功能
L：Logstach 搜集数据的功能，类似于flume（使用方法几乎跟flume一模一样），是日志收集系统
K：Kibana 数据可视化（分析），可以用图表的方式来去展示，文不如表，表不如图，是数据可视化平台

6.2 为什么要使用Elasticsearch?

因为在我们商城中的数据，将来会非常多，所以采用以往的模糊查询，模糊查询前置配置，会放弃索引，导致商品查询是全表扫面，在百万级别的数据库中，效率非常低下，而我们使用ES做一个全文索引，我们将经常查询的商品的某些字段，比如说商品名，描述、价格还有id这些字段我们放入我们索引库里，可以提高查询速度。

6.3 中文词库

可以使用免费的中文分词器词库插件IK来实现中文分词效果

7. Leaf

7.1 什么是Leaf

Leaf是美团公司开源的一个分布式序列号(id)生成系统
可以在Github网站上下载项目直接使用，
github地址：Leaf

7.2 Leaf特性

• 全局唯一性：不能出现重复的ID号，既然是唯一标识，这是最基本的要求。
• 趋势递增：在MySQL InnoDB引擎中使用的是聚集索引，由于多数RDBMS使用B-tree的数据结构来存储索引数据，在主键的选择上面我们应该尽量使用有序的主键保证写入性能。
• 单调递增：保证下一个ID一定大于上一个ID，例如事务版本号、IM增量消息、排序等特殊需求。
• 信息安全：如果ID是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定URL即可；如果是订单号就更危险了，竞对可以直接知道我们一天的单量。所以在一些应用场景下，会需要ID无规则、不规则。

7.3 为什么需要Leaf

上面的图片中
是一个实际开发中常见的读写分离的数据库部署格式
专门进行数据更新(写)的有两个数据库节点
它们同时新增数据可能产生相同的自增列id
一旦生成相同的id,数据同步就会有问题
会产生id冲突,甚至引发异常
我们为了在这种多数据库节点的环境下能够产生唯一id
可以使用Leaf来生成

7.4 Leaf的工作原理

Leaf底层支持通过"雪花算法"生成不同id
我们使用的是单纯的序列
要想使用,需要事先设置好leaf的起始值和缓存id数
举例,从1000开始缓存500
也就是从id1000~1499这些值,都会保存在Leaf的内存中,当有服务需要时,直接取出下一个值
取出过的值不会再次生成,当缓存的数据取完时,会往后再缓存500个,从1500-1999

leaf要想设置起始值和缓存数
需要给leaf创建一个指定格式的数据库表
运行过程中会从数据库表获取信息
我们当前的信息保存在leafdb.leaf_alloc表中

8. Quartz

8.1 什么是Quartz

Quartz 是 OpenSymphony 开源组织在任务调度领域的一个开源项目，完全基于 Java 实现。

8.2 为什么需要Quartz

所谓"调度"就是制定好的什么时间做什么事情的计划
我们使用过的最简单的调度方法就是Timer
但是Timer的调度功能过于单一,只能是指定时间的延时调用和周期运行
而Quartz可以更详细的指定时间,进行计划调用

8.3 Quartz核心组件

• Job：顾名思义，指待定时执行的具体工作内容；

Job是一个接口，只有一个方法execute()，我们创建具体的任务类时要继承Job并重写execute()方法，使用JobBuilder将具体任务类包装成一个JobDetail（使用了建造者模式）交给Scheduler管理。每个JobDetail由name和group作为其唯一身份标识。
JobDataMap中可以包含不限量的（序列化的）数据对象，在job实例执行的时候，可以使用其中的数据。
JobDataMap继承Map，可通过键值对为JobDetail存储一些额外信息。

• Trigger：触发器，指定运行参数，包括运行次数、运行开始时间和结束时间、运行时长等；

Trigger有四类实现，分别如下：

• SimpleTrigger：简单触发器，支持定义任务执行的间隔时间，执行次数的规则有两种，一是定义重复次数，二是定义开始时间和结束时间。如果同时设置了结束时间与重复次数，先结束的会覆盖后结束的，以先结束的为准。
• CronTrigger：基于Cron表达式的触发器。
• CalendarIntervalTrigger：基于日历的触发器，比简单触发器更多时间单位，且能智能区分大小月和平闰年。
• DailyTimeIntervalTrigger：基于日期的触发器，如每天的某个时间段。
• Trigger是有状态的：NONE, NORMAL, PAUSED, COMPLETE, ERROR, BLOCKED，状态之间转换关系：
  
  COMPLETE状态比较特殊，我在实际操作中发现，当Trigger长时间暂停后（具体时长不太确定）再恢复，状态就会变为COMPLETE，这种状态下无法再次启动该触发器。

• Scheduler：调度器，将Job和Trigger组装起来，使定时任务被真正执行；

调度器，是 Quartz 的指挥官，由 StdSchedulerFactory 产生，它是单例的。Scheduler中提供了 Quartz 中最重要的 API，默认是实现类是 StdScheduler。
Scheduler中主要的API大概分为三种：

1. 操作Scheduler本身：例如start、shutdown等；
2. 操作Job，例如：addJob、pauseJob、pauseJobs、resumeJob、resumeJobs、getJobKeys、getJobDetail等
3. 操作Trigger，例如pauseTrigger、resumeTrigger等

8.4 Cron表达式

Cron表达式是能够制定触发时间的一个格式

• * 表示任何值,如果在分的字段上编写*,表示每分钟都会触发

• , 是个分割符如果秒字段我想20秒和40秒时触发两次就写 20,40

• - 表示一个区间 秒字段5-10 表示 5,6,7,8,9,10

• / 表示递增触发 秒字段 5/10表示5秒开始每隔10秒触发一次
  日字段编写1/3表示从每月1日起每隔3天触发一次

• ? 表示不确定值, 因为我们在定日期时,一般确定日期就不确定是周几,相反确定周几时就不确定日期

• L 表示last最后的意思,我们可以设置当月的最后一天,就会在日字段用L表示,
  周字段使用L表示本月的最后一个周几,一般会和1-7的数字组合
  例如6L表示本月的最后一个周五

• W (work)表示最近的工作日(单纯的周一到周五) 如果日字段编写15W表示
  每月15日最近的工作日触发,如果15日是周六就14日触发,如果15日是周日就16日触发
  LW通常一起使用,表示本月的最后一个工作日

• # 表示第几个,只能使用在周字段上 6#3表示每月的第三个周五
  如果#后面数字写大了,是一个不存在的日期,那就不运行了
  适合设计在母亲节或父亲节这样的日期运行

推荐一个Cron表达式生成器

9. Kafka

9.1 什么是Kafka

Kafka是由Apache软件基金会开发的一个分布式、分区的、多副本的、多订阅者的开源流处理平台，由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。

9.2 Kafka架构

Kafka Cluster(Kafka集群)
Producer:消息的发送方,也就是消息的来源,Kafka中的生产者
Consumer:消息的接收方,也是消息的目标,Kafka中的消费者
Topic:话题或主题的意思,消息的收发双方要依据同一个话题名称,才不会将信息错发给别人
Record:消息记录,就是生产者和消费者传递的信息内容,保存在指定的Topic中

9.3 Kafka特点

• 高吞吐量：Kafka 每秒可以生产约 25 万消息（50 MB），每秒处理 55 万消息（110 MB）
• 持久化数据存储：可进行持久化操作。将消息持久化到磁盘，因此可用于批量消费，例如 ETL，以及实时应用程序。通过将数据持久化到硬盘以及replication 防止数据丢失。
• 分布式系统易于扩展：所有的 producer、broker 和 consumer 都会有多个，均为分布式的。无需停机即可扩展机器。
• 客户端状态维护：消息被处理的状态是在 consumer 端维护，而不是由 server 端维护。当失败时能自动平衡。

10. Zookeeper

10.1 什么是Zookeeper

• ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是大数据生态中的重要组件。它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
• 它是一个为分布式应用提供一致性协调服务的中间件

10.2 ZooKeeper提供了什么

• 文件系统
  • Zookeeper提供一个多层级的节点命名空间（节点称为znode）。与文件系统不同的是，这些节点都可以设置关联的数据，而文件系统中只有文件节点可以存放数据而目录节点不行。Zookeeper为了保证高吞吐和低延迟，在内存中维护了这个树状的目录结构，这种特性使得Zookeeper不能用于存放大量的数据，每个节点的存放数据上限为1M。
• 通知机制
  • client端会对某个znode建立一个watcher事件，当该znode发生变化时，这些client会收到zk的通知，然后client可以根据znode变化来做出业务上的改变等。

10.3 Zookeeper作用

• master节点选举, 主节点down掉后, 从节点就会接手工作, 并且保证这个节点是唯一的,这也就是所谓首脑模式,从而保证我们集群是高可用的
• 统一配置文件管理, 即只需要部署一台服务器, 则可以把相同的配置文件同步更新到其他所有服务器, 此操作在云计算中用的特别多(例如修改了redis统一配置)
• 数据发布与订阅, 类似消息队列MQ
• 分布式锁,分布式环境中不同进程之间争夺资源,类似于多进程中的锁
• 集群管理, 保证集群中数据的强一致性

10.4 Zookeeper的特性

• 一致性: 数据一致性, 数据按照顺序分批入库
• 原子性: 事务要么成功要么失败
• 单一视图: 客户端连接集群中的任意zk节点, 数据都是一致的
• 可靠性:每次对zk的操作状态都会保存在服务端
• 实时性: 客户端可以读取到zk服务端的最新数据

11. RabbitMQ

11.1 什么是RabbitMQ

RabbitMQ简称MQ是一套实现了高级消息队列协议的开源消息代理软件，简单来说就是一个消息中间件。是一种程序对程序的通信方法，其服务器也是以高性能、健壮以及可伸缩性出名的Erlang语言编写而成。

11.2 RabbitMQ特征

1.可靠性（Reliability） RabbitMQ 使用一些机制来保证可靠性，如持久化、传输确认、发布确认。

2.灵活的路由（Flexible Routing） 在消息进入队列之前，通过 Exchange 来路由消息的。对于典型的路由功能，RabbitMQ已经提供了一些内置的 Exchange 来实现。针对更复杂的路由功能，可以将多个Exchange 绑定在一起，也通过插件机制实现自己的 Exchange 。

3.消息集群（Clustering） 多个 RabbitMQ 服务器可以组成一个集群，形成一个逻辑 Broker

4.高可用（Highly Available Queues） 队列可以在集群中的机器上进行镜像，使得在部分节点出问题的情况下队列仍然可用。

5.多种协议（Multi-protocol） RabbitMQ 支持多种消息队列协议，比如 STOMP、MQTT 等等。

6.多语言客户端（Many Clients） RabbitMQ 几乎支持所有常用语言，比如 Java、.NET、Ruby 等等。

7.管理界面（Management UI） RabbitMQ 提供了一个易用的用户界面，使得用户可以监控和管理消息 Broker 的许多方面。

8.跟踪机制（Tracing） 如果消息异常，RabbitMQ 提供了消息跟踪机制，使用者可以找出发生了什么。

9.插件机制（Plugin System） RabbitMQ 提供了许多插件，来从多方面进行扩展，也可以编写自己的插件。

11.3 RabbitMQ是干什么的？

答：RabbitMQ简单来说就是一个消息队列中间件，用来保存消息和传递消息的一个容器。在此过程中充当一个中间人的作用。

而队列的主要目的就是提供正确的路由来保证消息的传递；如果发送消息时消费者不可用的话，默认情况下该消息将会一直被存储在队列中，直到消费者消费为止。

那么同时呢，如果设置了消息存活的时间，即消息的有效期。在此有效期间消息如果还没有被消费的话，那么该消息就会变成死信，由死信交换机接收。而绑定死信交换机的队列则称为死信队列。

11.4 RabbitMQ的常见作用有哪些

RabbitMQ的常见作用有三种，分别是服务间解耦、实现异步通信、流量削峰。

主要实现了消费者和生产者之间的解耦，发送异步消息，高并发访问解决流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。

常见的应用常见有：用户订单，库存处理；用户注册，发送手机短信邮件；商品秒杀和抢购等…

12. Docker

12.1 什么是Docker

Docker是一个用来开发、运输和运行应用程序的开放平台。使用Docker可以将应用程序与基础结构分离，以便快速交付软件。使用Docker，您可以以管理应用程序的方式管理基础架构。通过利用Docker的方法快速传送、测试和部署代码，可以显著减少编写代码和在生产中运行代码之间的延迟。

12.2 为什么使用Docker

• 更快速的应用交付和部署：
  传统的应用开发完成后，需要提供一堆安装程序和配置说明文档，安装部署后需根据配置文档进行繁杂的配置才能正常运行。Docker化之后只需要交付少量容器镜像文件，在正式生产环境加载镜像并运行即可，应用安装配置在镜像里已经内置好，大大节省部署配置和测试验证时间。
• 更便捷的升级和扩缩容：
  随着微服务架构和Docker的发展，大量的应用会通过微服务方式架构，应用的开发构建将变成搭乐高积木一样，每个Docker容器将变成一块“积木”，应用的升级将变得非常容易。当现有的容器不足以支撑业务处理时，可通过镜像运行新的容器进行快速扩容，使应用系统的扩容从原先的天级变成分钟级甚至秒级。
• 更简单的系统运维：
  应用容器化运行后，生产环境运行的应用可与开发、测试环境的应用高度一致，容器会将应用程序相关的环境和状态完全封装起来，不会因为底层基础架构和操作系统的不一致性给应用带来影响，产生新的BUG。当出现程序异常时，也可以通过测试环境的相同容器进行快速定位和修复。
• 更高效的计算资源利用：
  Docker是内核级虚拟化，其不像传统的虚拟化技术一样需要额外的Hypervisor [管理程序] 支持，所以在一台物理机上可以运行很多个容器实例，可大大提升物理服务器的CPU和内存的利用率。

Docker运行架构图

12.3 Docker相关资料

Docker官网
Docker Hub官网（镜像仓库）
参考官方文档

13. 布隆过滤器

13.1 什么是布隆过滤器

布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。

13.2 布隆过滤器的优缺点

布隆过滤器的优点：

• 时间复杂度低，增加和查询元素的时间复杂为O(N)，（N为哈希函数的个数，通常情况比较小）
• 保密性强，布隆过滤器不存储元素本身
• 存储空间小，如果允许存在一定的误判，布隆过滤器是非常节省空间的（相比其他数据结构如Set集合）

布隆过滤器的缺点：

• 有点一定的误判率，但是可以通过调整参数来降低
• 无法获取元素本身
• 很难删除元素

13.3 布隆过滤器的使用场景

• 解决Redis缓存穿透问题
• 邮件过滤，使用布隆过滤器来做邮件黑名单过滤
• 对爬虫网址进行过滤，爬过的不再爬
• 解决新闻推荐过的不再推荐(类似抖音刷过的往下滑动不再刷到)
• HBase\RocksDB\LevelDB等数据库内置布隆过滤器，用于判断数据是否存在，可以减少数据库的IO请求

14. 负载均衡

14.1 什么是负载均衡

负载均衡（Load Balance，简称 LB）是高并发、高可用系统必不可少的关键组件，目标是 尽力将网络流量平均分发到多个服务器上，以提高系统整体的响应速度和可用性。

14.2 负载均衡的主要作用如下：

高并发：负载均衡通过算法调整负载，尽力均匀的分配应用集群中各节点的工作量，以此提高应用集群的并发处理能力（吞吐量）。

伸缩性：添加或减少服务器数量，然后由负载均衡进行分发控制。这使得应用集群具备伸缩性。

高可用：负载均衡器可以监控候选服务器，当服务器不可用时，自动跳过，将请求分发给可用的服务器。这使得应用集群具备高可用的特性。

安全防护：有些负载均衡软件或硬件提供了安全性功能，如：黑白名单处理、防火墙，防 DDos 攻击等。