微服务名词概述
微服务架构四大问题
服务与服务之间如何通信
- 同步通信
HTTP (Apache Http Client)
RPC (Dubbo、gRPC、Apache Thrift) - 异步通信 - 消息队列
- 同步通信
这么多服务,如何管理(服务治理 - 服务注册于发现)
- 基于客户端 - Zookeeper
- 基于服务端 - Eureka
服务挂了怎么办
重试机制、服务熔断、服务降级、服务限流
客户端如何访问(Api 网关)
服务雪崩
因服务提供者不可用导致服务调用者不可用,并将不可用逐渐放大的过程。
缓存雪崩
缓存中数据大批量到过期时间,而查询数据量巨大,引起数据库压力过大甚至 down 机。
解决方案:热点数据永远不过期、过期时间设置随机、分布式存储缓存等。
缓存穿透
用户不断请求缓存和数据库中都没有的数据,如发起为 id 为“-1”的数据或 id 为特别大不存在的数据。这时的用户很可能是攻击者,攻击会导致数据库压力过大。
解决方案:用户鉴权校验、id 做基础校验;也可以将 key-value 对写为 key-null,缓存有效时间可以设置短点,如 10 秒(设置太长会导致正常情况也没法使用)。这样可以防止用户反复用同一个 id 暴力攻击。
缓存击穿
缓存中没有但数据库中有的数据(一般是缓存时间到期),这时由于并发用户特别多,同时读缓存没读到数据,又同时去数据库去取数据,引起数据库压力瞬间增大,造成过大压力 。
解决方案:热点数据永远不过期、加互斥锁(在缓存过期期间,最多只有一个线程能够查询数据库更新缓存)等。
集群脑裂
由于网络断开原因,一个集群被分裂成两个集群;如 Elasticsearch 和 Zookeeper 等,通过选举确定主节点,都面临此问题;他们采用节点数过半机制保证集群脑裂后还能正常工作;
过半机制就是可用节点数 > 总节点数 / 2,集群才对外提供服务,否则集群不可用;
分布式锁
在分布式系统中,多个节点(计算机或进程)并行运行,多个节点操作同一资源时,先竞争该资源的锁,待业务完成后释放锁,以保证同一时刻只有一个节点操作该资源。
分布式锁主要解决以下问题
数据一致性
互斥访问
避免死锁
协调分布式任务:分布式锁还可以用于协调多个节点执行分布式任务的顺序或并发控制。
防止重复操作
并发控制:分布式锁可以用于限制系统中的并发连接数或请求速率。
分布式锁改善性能瓶颈
使用分层锁:将分布式锁分成多个层次,每个层次的锁控制不同的资源或操作。这可以减少不同节点之间的竞争,提高性能。例如,可以使用不同的锁来控制不同的资源,而不是一个全局锁。
使用更高效的锁实现:选择适合应用场景的高性能锁实现。例如,基于缓存的分布式锁(如 Redis)通常比基于数据库的锁更高效。优化锁的实现可以显著提高性能。
减少锁的粒度:在需要互斥访问的地方使用锁,而不是在整个操作中使用锁。
使用本地缓存:在适当的情况下,可以使用本地缓存来减少对分布式锁的频繁访问。
引入异步处理
使用分布式算法:一些分布式锁实现使用高效的分布式算法,如 Paxos 或 Raft,来减少竞争和提高性能。
优化锁的生命周期:尽量减少锁的持有时间,以减少锁的竞争。
监测和调优:使用性能监测工具来分析锁的性能瓶颈,并进行必要的调优。
分布式锁的实现
基于数据库的分布式锁:
使用数据库表中的行记录来表示锁状态,通过事务操作来获取和释放锁。
优点:可靠,支持事务,容错性强。
缺点:性能较低,可能引起数据库负载,不适用于高并发场景。基于缓存的分布式锁(如 Redis 或 Memcached):
使用缓存中的键值对来表示锁状态,通过缓存操作来获取和释放锁。
优点:高性能,支持超时自动释放锁,可扩展性强。
缺点:不如数据库锁那么可靠,可能发生竞态条件,需要处理锁过期情况。基于 ZooKeeper 的分布式锁:
使用 ZooKeeper 的临时有序节点来表示锁状态,节点的顺序用于竞争锁。
优点:ZooKeeper 提供强一致性和可靠性,适用于复杂的分布式场景。
缺点:性能相对较低,ZooKeeper 的配置和维护复杂。基于分布式协议的锁(如 Paxos、Raft 等):
使用分布式一致性协议来实现锁,通常用于高可靠性要求的场景。
优点:强一致性和可靠性,适用于复杂的分布式系统。
缺点:性能较低,配置和使用复杂。基于原子性操作的锁(如 CAS):
使用原子性的比较和交换操作来实现锁,通常在编程语言和平台层面提供支持。
优点:性能较高,适用于低级别的锁需求。
缺点:可能需要自行处理锁的释放和超时逻辑。基于分布式消息队列的锁:
使用分布式消息队列来协调锁的获取和释放,通过消息传递实现锁的竞争。
优点:可扩展性强,适用于事件驱动的系统。
缺点:消息队列的延迟和复杂性
公平锁和可重入公平锁
公平锁
操作资源时排队取号,先到先获得锁,且独占一把锁;
可重入公平锁
操作资源时多个操作者允许使用同一个号,无需重复排号,先到先获得锁,一把锁可以被多次锁定;
[更多 Java 显式锁](/back/java/java 并发编程。html#显式锁的分类)
羊群效应
一个节点挂掉,所有节点都去监听,然后做出反应,会给服务器巨大压力;所以有了临时顺序节点,当一个节点挂掉时,只有他后面那个节点才会做出反应;
CI、CD
持续集成 (Continuous Integration,CI):
目的: 将团队代码集成到本地仓库中,然后在 测试环境 中自动运行构建和测试。目的是早期发现和解决集成问题,提高代码质量,减少集成错误。
持续交付 (Continuous Delivery,CD):
定义: 不仅自动构建和测试代码,自动化部署到一个 预生产环境 ,供进一步的手动测试或用户验收测试使用。
目的: 缩短交付周期,使得软件在任何时候都是可部署的状态,降低发布新版本的风险。
持续部署 (Continuous Deployment,CD):
定义: 强调通过自动化流程将软件部署到 生产环境 ,从而实现在每次通过了测试的代码提交后,都能自动发布到生产环境。
目的: 最大限度地减少发布新版本的手动干预,提高交付速度和可靠性。
总的来说,持续集成注重代码集成和测试,持续交付强调自动化部署到预生产环境,而持续部署则将这一自动化扩展到生产环境。
垂直扩容和水平扩容
垂直扩容(横向扩容)是通过增加单个节点、服务器或实例的处理能力。水平扩容(纵向扩容)是通过增加系统中节点、服务器或实例的数量。
CAP 理论
CAP 理论提出在一个分布式系统中,Consistency(一致性)、Availability(可用性)、Partition Tolerance(分区容错性),不能同时成立。
一致性 C
所有节点在同一时间得到的数据是一样的。
可用性 A
在合理的时间内响应请求,没有阻塞。
同时满足可用性和一致性矛盾,因为网络不可靠,导致节点不可用,
分区容错性 P
一个节点挂掉,系统仍然能正常工作,他是分布式系统必须具备的基本能力。
一致性和可用性本来就相互矛盾,因为如果所有节点要保证数据一致,在同步数据期间,节点会拒绝请求导致系统不可用;
只能在 CP 和 AP 之间取舍,AP(可用性+分区容错性)系统在实践中更为常见和主流,提供不间断的服务直接影响用户满意度、留存率和收入。
尽管 AP 更常见,CP(一致性+分区容错性) 系统在金融核心系统、分布式锁与协调服务、关键配置管理、分布式事务、分布式锁、消息队列等场景中应用较多,牺牲可用性(在分区时)是必要的代价。
服务熔断
服务熔断(Circuit Breaker),当某个微服务连续的失败次数或错误率达到某个预置点,所有请求都会被阻止,当检测到服务响应正常后,又逐步恢复调用链路的过程。
服务熔断防止系统因连续故障而崩溃,通过切断故障点来保护系统的整体稳定性,服务熔断主要包括以下几个过程:
打开熔断(拒绝所有请求)->半开(允许部分请求)->关闭(所有请求正常处理)。
服务降级
服务降级(Fallback),在服务出现问题时,尽可能提供部分功能或返回友好数据,减少对用户的影响。

