微服务之注册中心 Zookeeper 与 Eureka 比较
分布式环境的一个非常重要的理论是 CAP 原则,即一个分布式系统不可能同时满足 C(一致性)、A(可用性) 和 P(分区容错)。而分区容错是分布式架构中必须要保证的,因此只能在 A 与 C 之间进行权衡。
Zookeeper 保证的是 CP , 而 Eureka 保证的则是 AP。
分布式环境的一个非常重要的理论是 CAP 原则,即一个分布式系统不可能同时满足 C(一致性)、A(可用性) 和 P(分区容错)。而分区容错是分布式架构中必须要保证的,因此只能在 A 与 C 之间进行权衡。
Zookeeper 保证的是 CP , 而 Eureka 保证的则是 AP。
分布式架构中通常都会存在共享资源,在多个服务或一个服务多个实例同时对此共享资源进行读写操作情况下,会存在数据不一致性,就需要分布式锁来解决此问题。
实现分布式锁通常会借助外部组件,主要有四种实现方式,基于 Redis 实现,基于 Zookeeper 实现,直接使用 Redisson 已实现的分布式锁,Google 的 Chubby 服务。
本地事件表加消息队列实现分布式事件方案实现数据的最终一致性。本地事件表作用是为了事件溯源(Event-Sourcing),消息队列实现事件通知。
事件表要求记录了业务表操作的所有事件,所有事件的组合就是表中数据的生命周期。
本篇是 分布式微服务应用系列(九):分布式事务概念及解决方案 的延续。
微服务分布式架构中的分布式事务是一个技术难点,为了保证数据的一致的,必须要解决分布式事务问题。
分布式事务的两个基本理论是 CAP 和 BASE,为实现分布式解决方案提供了理论方向。实现分布式事务的解决方案主要有两种类型,一种是基于强一致性协议实现,另一种是柔性事务实现数据最终一致性。
缓存已是系统架构中非常重要的组件,特别是在高并发的系统中几乎是不可或缺的。
由于缓存的特性和功能,在某些场景上会存在一些问题,主要是 缓存穿透、缓存雪崩 和 缓存击穿。
缓存是高并发系统的三把利器之一(另两把是 限流、降级),可以说是必不可少的。缓存的主要目的是为了解决磁盘与内存速度差异问题,解决高并发下频繁访问数据库导致磁盘 I/O 压力和 CPU 负载过高问题。
这里所说的缓存是指业务系统的缓存,是将数据缓存在内存中,当下次有相同请求时就直接从内存中取数据返回。
缓存可以在服务端本地,也可以是远程独立的缓存系统,如 Redis,通常本地缓存和远程缓存配合使用。
本篇文章在 Spring 缓存体系上进行扩展和补充,更多可参考 Spring Boot 2实践系列(十):Spring 缓存体系、Spring Boot 2实践系列(十一):Ehcache集成详解和使用、Spring Boot 2实践系列(十二):Spring Data Redis 集成详解和使用 ,官方:Spring Data Redis 。
在 Spring Cloud 微服务架构中,使用 Spring Boot Admin 对微服务进行监控和管理。
关于 Spring Boot Admin 的基本应用,可参考 Spring Boot 2实践系列(十六):Spring Boot Admin - Actuator 监控管理 Web 框架 ,Spring Boot Actuator 可参考 Spring Boot 2实践系列(六):应用监控模块 Actuator 详解和集成 ,Spring Boot Admin 2.14 官方文档。
微服务之间的相互调用,需要一套认证机制来确认调用是安全的。这不同于在 API 网关的统一认证,主要是防止在微服务暴露在外网的情况下,内部接口被外部恶意调用。
如果微服务是在内网,对外暴露的只有 API 网关,则可以不用做认证。本篇以 JWT 技术来实现安全认证。更多关于 JWT ,可参考分布式应用系列(一):详细理解 JWT(Json Web Token)。
在分布式微服务架构中,特别是跨域访问的情况下,通常会使用 JWT 技术来实现安全认证。
JSON Web Tokens 是一种开放的、行业标准的 RFC7519 规范,用于安全地表示双方之间的声明。