1, 技术架构
2, 组件介绍
1, 服务注册与发现 --Eureka
服务注册与发现中心采用 Eureka, 以 AP 为核心的高可用注册中心, 保证高可用性和最终一致性, server 之间互相注册的 replicate 机制可以单点注册, 全局感知, 通过集群式部署来避免单点故障导致服务不可用.
提供云端服务发现, 一个基于 REST 的服务, 用于定位服务, 以实现云端中间层的服务发现和故障转移.
主要用来实现服务治理, 统一管理众多微服务应用的地址信息, 以及复杂的调用关系, 减少应用之间的耦合, 通过提供服务方在 Eureka Server 注册服务, 服务消费方在 Server 上订阅所需服务得到提供者的地址信息, 完成一次服务之间的请求调用.
由 Eureka Server 和 Eureka Client 组成, Eureka Server 用作注册中心, 支持集群部署; Eureka Client 是一个 Java 客户端, 用来处理服务注册与发现.
2, 服务网关 --Spring Cloud GateWay
Spring Cloud GateWay 作为 Spring Cloud 生态系统中的网关, 旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式, 并且基于 Filter 链的方式提供了网关基本的功能, 如: 安全, 授权, 监控 / 指标, 限流等.
GateWay 特征有: 动态路由, 基于 HTTP 请求的路由匹配, Predicates 和 Filters 作用于特定路由, 集成 Hystrix 熔断器, 易于编写的 Predicates 和 Filters, 限流, 路径重写, 与服务注册发现组件结合根据 serviceId 转发.
重要的概念
过滤器: 用于拦截和链式处理 web 请求, 实现横切的, 与应用无关的需求. 可在代理请求处理之前 (pre) 执行, 也可以在请求之后 (post) 执行. pre 类型过滤器可以做参数校验, 权限校验, 流量监控, 日志输出, 协议转换等; post 类型过滤器可以做响应内容, 响应头的修改, 日志输出, 流量监控等. 过了 pre 和 post 的区分, 根据作用范围还可以分为针对单个路由的 gateway filter 和针对所有路由的 global gateway filter.
Predicate: 在将 Web 请求和路由进行匹配时, 用到的就是 predicate, 决定请求走哪一个路由. GateWay 内置了多种类型的 Predicate.
请求时, 客户端向 GateWay 发起请求, 如果在 GateWay Handler Mapping 中找到与请求相匹配的路由 (此处用到 Predicate), 将其发送到 GateWay Web Handler,Handler 再通过指定的过滤链来将请求发送到实际的服务执行业务逻辑, 然后返回. 期间, 过滤器可能在发送代理请求之前(pre 过滤器) 或之后 (post 过滤器) 执行.
GateWay 基于 Webflux, 支持异步非阻塞编程.
3, 服务调用 --Ribbon + Hystrix + Feign
一次服务调用请求过程, 提供某个服务的应用可能有多个(集群部署), 消费方需要从中选择一个进行调用, 即客户端负载均衡技术, Ribbon 主要提供客户端的软件负载均衡算法.
Ribbon 支持许多常见的负载均衡策略, 同时也支持自定义负载均衡策略.
Hystrix 的主要作用是熔断器, 控制故障范围, 是一个容错管理工具, 通过熔断机制控制服务和第三方库的节点, 对延迟和故障提供更强大的容错能力.
由于网络分区环境的复杂性, 通常服务不能保证 100% 的可用性, 如果某个服务出现故障, 调用该服务就会出现线程阻塞, 此时若有大量请求涌入, 线程资源耗尽后造成服务瘫痪. 而由于服务之间的调用依赖性, 故障会快速在服务群中扩散, 严重时导致大量微服务不可用, 这就是服务故障的 "雪崩" 效应.
Hystrix 可以在服务故障时拦截请求, 快速返回错误信息, 同时自动探测服务状态以便后续恢复服务请求, 另外也支持实现服务降级机制, 可以显著增加整个分布式系统的健壮性和稳定性.
Feign 是一个声明式的 Web 服务客户端, 支持可插入注释, 可插拔编码解码器, 以及 Ribbon 的负载均衡, Hystrix 和它的 fallback 和 HTTP 请求和响应的压缩.
将对 REST 服务请求封装成接口形式, 以调用本地接口的形式调用远程 REST 服务, 对开发更加直观友好.
Feign 通过编写简单的接口和插入注解, Feign 就会根据自定义的 HTTP 请求的参数, 格式, 地址等信息, 来完全代理 HTTP 请求, 通过调用接口就可以完成服务请求.
4, 业务集群 --SpringBoot + SpringMVC
Spring Cloud 基于 SpringBoot 工程构建, 利用 SpringBoot 可以快速开发单个微服务应用.
通过 SpringMVC 的相关注解可以对外暴露 REST 服务.
5, 服务配置中心 --Spring Cloud Config
随着微服务规模的增大, 以及生产, 测试等环境隔离的要求, 由每个微服务应用单独维护各自的配置信息会非常混乱, 而且每次配置信息的变更都需要应用的重启才能生效, 因此需要一个分布式配置中心, 提供统一的配置信息管理.
Spring Cloud 中的分布式配置中心组件 Spring Cloud Config, 支持配置信息放在配置服务器本地, 也支持存放在远程 Git 仓库中, 集中化管理集群配置, 可以分为两个角色, Config Server 和 Config Client.
Config Server 保存配置信息在本地或远程仓库中, 然后对外发布配置服务, 将配置信息服务化; Config Client 通过访问 Config Server 提供的服务接口, 获取相关的配置信息来完成自身的应用初始化.
为了避免单点故障, 同样可以部署成集群模式.
同样另一个问题, 由配置中心统一管理, 配置信息变更时, 无需重启应用, 就可以做到配置信息实时更新生效.
6, 消息总线 --Bus
Spring Cloud Bus 通过轻量的消息代理连接各个分布的节点, 称为事件, 消息总线, 用于在集群中传播状态变化, 可以与 Spring Cloud Config 联合使用实现配置信息热部署. 主要功能有两点:
对指定主题的消息进行订阅和发布
事件监听, 包括刷新事件, 环境变更事件, 远端应用的 ack 事件以及本地服务端发送事件等.
其本质是利用了 MQ 的广播机制在分布式系统中传播消息.
提交代码或变更配置触发 post 请求给 bus/refresh
server 端接受请求并发送给 Bus
Bus 接到消息后通知给客户端
客户端收到通知后, 请求 server 获取最新配置
全部客户端更新配置
7, 认证, 授权, 安全 --spring cloud security + OAuth2 + JWT
Spring Security 是一个强大的, 高度可定制化的身份验证和访问控制框架, 两个主要目标就是 认证 和 授权, 一般为先认证身份, 然后进行授权.
认证协议 --JWT. 基本思路就是用户提供用户名和密码给认证服务器, 服务器验证用户提交信息的合法性, 验证成功返回一个 Token, 用户用这个 Token 访问服务器上受保护的资源. JWT 的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息, 以便于从资源服务器获取资源, 也可以增加一些额外的其它业务逻辑所必须的声明信息, 该 token 也可直接被用于认证, 也可被加密.
授权框架 --OAuth2.OAuth 允许用户提供一个令牌, 而不是用户名和密码, 每一个令牌授权一个特定的第三方应用在特定的时段内访问特定的资源.
8, 链路跟踪 --zipkin(spring cloud sleuth)
随着系统和微服务应用的增多, 一个业务可能需要多个微服务协同完成, 链路上任何一个应用的服务出现问题都会导致业务失败, 需要快速跟踪故障位置.
Spring Cloud Sleuth, 主要功能是在分布式系统中提供追踪解决方案, 并且兼容支持 zipkin,HTrace 和 log-base 追踪.
服务追踪从客户都拿发起请求到达被追踪系统边界开始, 到被追踪系统向客户返回响应结束, 称为一次 trace; 在 trace 过程每次调用服务时, 埋入一个调用记录("span"), 再附带上响应时间和请求成功与否等信息, 这样, 若干有序的 span 就组成了一个 trace.
Sleuth 为服务之间调用提供链路跟踪, 可以做到理清服务间调用关系; 耗时分析; 可视化错误(借助 zipkin); 链路优化.
结合 zipkin, 将数据发到 zipkin, 进行数据可视化, 展示微服务调用请求链, 错误信息可视化. 可以直观地看到一次请求经过了那些微服务, 以及每个服务的耗时, 在请求失败时可以快速定位到请求链中哪一环出了问题.
9, 监控中心 --Turbine,Dashboard + Spring Boot Admin
首先介绍两个 Hystrix 监控工具:
Hystrix Dashboard 是一个针对 Hystrix 进行实时监控的工具, 可以直观地看到各个 Hystrix Command 的请求响应时间, 请求成功率等.
Dashboard 只能看到单个应用内的服务信息, Hystrix Turbine 可以聚合监控系统内多个服务的数据. 由于分布式系统中服务通常集群部署, Turbine 可以把多个相同服务的节点状态聚合为一个数据源, 以一个整体集群的形式供 Dashboard 展示.
Actuator 时 Spring Boot 提供的对应用系统的自省和监控的集成功能, 可以查看应用配置的详细信息等, 为了保证 Actuator 暴露的监控接口的安全性, 需要添加安全管理的 Security 依赖.
Actuator 监控分为原生端点和用户自定义端点两类, 可以观察应用运行期间的各种性能指标和内部状况.
Spring Boot Admin:
由于使用 Actuator 监控, 需要对每个应用单独调用固定的接口来进行监控, 而且返回数据均为 JSON 数据.
Spring Boot Admin 是一个开源社区项目, 用于管理和监控 SpringBoot 应用程序. 应用程序作为 Spring Boot Admin Client 向为 Spring Boot Admin Server 注册 (通过 HTTP) 或使用 SpringCloud 注册中心 (例如 Eureka,Consul,Zookeeper) 发现. 在前端界面展示 Admin Client 的 Actuator 端点上的一些监控信息.
提供了安全登录界面的组件, 并且和 Spring Boot Security 相结合, 提供安全登录功能.
Spring Boot Admin Server 中还可以集成 Turbine 组件, 让 Turbine 中展示的内容整合到 Admin Server 中, 和应用实例一起监控, 方便查看和管理.
10, 消息队列 --Kfaka
11, 分布式日志系统 --ELK
ElK, 即 Elasticsearch+Logstash+Kibana.
Elasticsearch 是一个基于 Lucene 的开源分布式搜索服务器. 它的特点有: 分布式, 零配置, 自动发现, 索引自动分片, 索引副本机制, restful 风格接口, 多数据源, 自动搜索负载等. 它提供了一个分布式多用户能力的全文搜索引擎, 基于 RESTful Web 接口. 设计用于云计算中, 能够达到实时搜索, 稳定, 可靠, 快速, 安装使用方便.
Logstash 是一个完全开源的工具, 它可以对日志进行收集, 过滤, 分析, 支持大量的数据获取方法, 并将其存储供以后使用(如搜索). 一般工作方式为 c/s 架构, client 端安装在需要收集日志的主机上, server 端负责将收到的各节点日志进行过滤, 修改等操作再一并发往 Elasticsearch 上去.
Kibana 是一个基于浏览器页面的 Elasticsearch 前端展示工具, 可以为 Logstash 和 Elasticsearch 提供日志分析友好的 Web 界面.
每台服务器集群节点安装 Logstash 日志收集系统插件, 将日志输入到 Logstash 中
Logstash 将该日志格式化为 JSON 格式, 根据每天创建不同的索引, 输出到 Elasticsearch 中
另外, zipkin 的流也可以直接传给 Elasticsearch, 便于运维管理和分析
浏览器使用安装 Kibana 查询日志信息
12, 分布式事务
由于在微服务架构中, 不同的业务集群维护各自独立的数据库, 互相之间数据不互通, 调用也只是接口的调用, 再加上网络环境的不稳定性, 分布式事务的一致性就显得非常重要.
常见的分布式事务解决方案有:
两阶段提交
补偿事务机制
本地消息表
MQ 事务消息
13, 分布式缓存 --Redis
Redis 可以用来做分布式系统 Session 共享, 同时, Redis 做二级缓存对降低整个服务响应时间, 减少数据库访问次数也有帮助, 可选 Redis Cluster(集群模式)和 Redis Sentinel(哨兵模式).
来源: https://www.cnblogs.com/iUtopia/p/11758812.html