2. 微服务组件
2.1 微服务组件包括哪些
一个完整的微服务包括的组件：注册中心，配置中心，熔断，限流，链路跟踪，路由
在微服务中，有些组件为必须组件（必须启动存在），客户端才能正常调用
- 必须组件：注册中心，后台服务（Provider）
- 非必须组件：配置中心，熔断，限流，链路跟踪，路由
2.2 课程学习的组件
- 注册中心 Nacos
- 配置中心 Nacos
- 网关 Spring Cloud Gateway
- 熔断，限流 Sentinel
- 分布式追踪系统 SkyWorking
2.3 注册中心组件
2.3.1 什么是注册中心
注册中心可以说是微服务架构中的地址簿，它记录了服务和服务地址的映射关系，在分布式架构中，服务会注册到这里，当服务需要调用其他服务时，就在这里找到服务的地址，进行调用。
2.3.2 为什么需要注册中心
服务注册中心给客户端提供可供调用的服务列表，客户端在进行远程服务调用时，根据服务列表然后选择服务提供方的服务地址进行服务调用。服务注册中心在分布式系统中大量应用，是分布式系统中不可获取的组件。
注册中心是整个服务调用的核心部分，如果服务不存在注册中心，那么通过网关会调用不到，导致失败。
2.3.3 注册中心分类
注册中心分两大类
- 临时实例：在nacos中Java客户端自动注册的服务实例一般为临时实例，并且客户端会间隔几秒发送心跳到注册中心，告诉注册中心是否存活，如果不存在，那么注册中心会自动从列表中去掉此节点。
- 永久实例：可以通过api的方式人工填写客户端信息，注册中心不会去掉节点（不管是否在线）。注册中心会主动检查客户端是否在线。
2.3.4 常见的注册中心
Netflix Eureka
Nacos
Consul
Zookeeper
CoreDNS
2.3.4.1 consul，eureka，nacos对比
| 功能对比 | eureka | consul | nacos |
|---|---|---|---|
| 配置中心功能 | 不支持 | 支持，但是用起来偏麻烦，不太符合spring Boot框架的命名风格，支持动态刷新 | 支持，用起来简单，符合springBoot的命名风格，支持动态刷新 |
| 依赖 | 依赖zookeeper | 不依赖其他组件 | 不依赖其他组件 |
| 应用内/外 | 直接集成到应用中，依赖于应用自身完成服务的注册与发现 | 属于外部应用，侵入性小 | 属于外部应用，侵入性小 |
| ACP原则 | 遵循AP（可用性+分离容忍）原则，有较强的可用性，服务注册块，单牺牲了一定的一致性 | 遵循CP原则（一致性+分离容忍）服务注册稍慢，由于其一致性导致了在leader挂掉重新选举期间整个consul不可用 | 通知遵循CP原则（一致性+分离容忍）和AP原则（可用性+分离容忍） |
| 版本迭代 | 目前已经不进行升级 | 目前仍然进行版本迭代 | 目前仍然进行版本迭代 |
| 集成支持 | 只支持SpringCloud集成 | 支持SpringCloud K8S集成 | 支持Dubbo，SpringCloud，K8S集成 |
| 访问协议 | HTPP | HTTP/DNS | HTTP/动态DNS/UDP |
| 雪崩保护 | 支持 | 不支持 | 支持 |
| 界面 | 英文界面 | 英文界面，不符合国人习惯 | 中文界面 |
| 上手 | 容易 | 复杂一点 | 极易，中文文档，案例，社区活跃 |
2.4 配置中心组件
2.4.1 什么是配置中心
管理各个环境的配置文件参数，比如说数据库，缓存，存储，业务应用并且支持管理每个不同的环境的配置。
2.4.2 为什么需要配置中心
- 本地配置在服务启动加载，修改配置不需要重启服务
- 多个环境（dev，prod，sit，uat）容易混淆，会产生错误，导致服务运行异常
- 出现配置错误时，不容易回滚到指定的版本
2.4.3 配置中心演进
从单一的单机部署到多机的负载均衡，以及后来应用的微服务容器化，不可避免的使用多个环境的配置。
2.3.4 常见配置中心功能对比
| 功能 | Spring Cloud Config | Apollo | Nacos |
|---|---|---|---|
| 实效性 | SpringCloudBus | HTTP长轮询 | HTTP长轮询 |
| 权限控制 | 支持 | 支持 | 支持 |
| 灰度发布 | 支持 | 支持 | 不支持 |
| 版本管理 | 支持 | 支持 | 支持 |
| 版本回滚 | 支持 | 支持 | 支持 |
| 多环境支持 | 支持 | 支持 | 支持 |
2.5 API路由网关组件
2.5.1 什么是API网关
API网关是微服务架构中提供路由转发与鉴权等功能，首先，它会提供最基本的路由服务，将客户端请求转发后台业务服务；其次，作为一个入口，它还可以进行认证，鉴权，限流等操作。
2.5.2 为什么需要API网关
- 客户端访问的统一对接接口
- 防止内部接口直接暴露给外部客户端（隐藏内部服务）
- API网关通过提供一个额外的保护层来防止恶意攻击，例如SQL注入，XML解析器漏洞和拒绝服务
- 服务网关的前置过滤器中，所有请求过来进行权限校验
- 日志访问与审计
2.5.3 网关架构说明
调用之前所有的客户端通过7层负载均衡反向代理后台的服务
调用之后所有的客户端通过微服务框架网关负载到后台的服务
2.5.4 常用的网关组件
- KONG是一个通过lua-nginx-module实现的在nginx中运行的lua应用程序
- Spring Cloud Gateway是由Spring官方基于Spring5.0等技术开发的网关，目的是代替原先版本中的Zuul
- Zuul
2.6 服务限流组件
2.6.1 什么是服务限流
- 服务限流：指当系统资源不够的情况下，不足以应对大量的用户与数据接口请求时，为了保证优先的资源能够正常服务，因此对系统按照预设的规则进行流量限制或功能限制的一种方法。
2.6.2 为什么需要服务限流
- 发生错误或者超时，不让调用接口，调用本地fallback（容错）
- 解决高并发请求，一旦达到规定请求，熔断，报错
2.6.3 常用限流组件
Sentinel（阿里 哨兵）
Hystrix (Spring Cloud 豪猪)
2.6.4 图解说明熔断作用
- 如果未接入熔断处理，在客户端直接返回500错误，程序会抛异常，有可能会导致其他服务也不可用（消耗系统资源）
- 启用熔断处理，在客户端返回200正常？？
2.7 链路跟踪（调度链）组件
2.7.1 什么是调用链
调用链是整个分布式系统中跟踪一个用户请求的过程，包括数据采集，数据传输，数据存储，数据分析和数据可视化展示工具，也是微服务中代码的调试和服务监控的性能分析工具。
2.7.2 为什么需要调用链
分布式web系统中，客户端的一次请求操作，可能需要经过系统中多个模块，多个中间件，多台机器的相互协作才能完成，并且这一系列调用请求中，有些是串行处理的，有些是并发执行的，那么如何确定客户端的一次操作背后调用了哪些应用，哪些模块，经过了哪些节点，每个模块的调用先后顺序是怎样的，每个模块的性能问题如何？随着业务系统模型的日趋复杂化，分布式系统中继续一套链路追踪（trace）系统来解决这些问题（快速定位）。
2.7.3 常见组件
- SkyWalking 用于追踪，监控和诊断分布式系统，特别是使用微服务架构，云原生或容积技术
- Zipkin的一个叫Brave的组件来实现对应用内部的性能分析数据采集，通过实现一系列的java拦截器，来做到对http请求，数据库访问的调用过程跟踪。
- Pinpoint是开源在github上的一款APM监控工具，用java编写，用于大规模分布式系统的监控，它对性能的影响最小（只增加约3%资源利用率），安装agent是无侵入式的。
2.7.4 调用链调用过程
- 通过调用接口可以查看到每个接口所调用的层次，并且可以查看调用的方法名。
在本例中，客户端访问网关服务在调用系统中会显示，服务端先启动tomcat，如果程序调用auth方法，最后对外服务，也可以看到接口调用时间。
2.8 小结
- 本节讲述了在微服务中涉及的5大组件，分类为必须组件和非必须组件
- 大致阐述每个组件的原由北京以及典型的组件代表
- 每个组件功能总结：
注册中心 所有服务注册与调用查询
配置中心 微服务配置项集中管理
网关 自动路由与负载均衡至微服务
熔断，限流 防止服务崩溃的保护机制
分布式追踪系统 判断程序性能与调用关系