微服务架构(一)分布式系统高可用设计方案

本文探讨了微服务架构中实现高可用性的关键策略,包括服务冗余、无状态化、幂等设计、录入验证、超时机制、负载均衡、异步处理、服务限流降级熔断、数据复制与服务治理。通过这些手段,确保系统在面对故障时仍能保持稳定运行,并介绍了服务分级和如何平滑停止线上服务的方法。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

高可用性(稳定性) 


判断指标


传统的判断是否高可用的指标是看一段时间内停机时间在总运行时间的占比,1个9是90%的时间可用,2个9是99%的时间可用
3个9是千分之一的时间不可用。
科学的衡量指标是影响的请求量在总请求量中的占比。晚上没人使用的时候停机和白天使用高峰期停机影响程度是不一样的。


主要手段


一服务冗余
服务的硬件和软件总是会出问题的,所以在整个业务链路中,要保证每个节点的服务都是多份冗余,一旦一台服务挂掉,
可以迅速把流量切换到其他冗余服务器。
二无状态化
要想做到一个节点多份冗余,就要是服务无状态化,这样既可以做到快速的流量分流,也可以快速的伸缩服务器数量。现在流行的dock容器就是
为快速方便扩容而生的。
三幂等设计
对同一个请求多次重复提交,得到的结果应该是一样的。
四录入验证机制
用户是万恶的,如果你不能对录入的内容进行合理的检查和限制,你根本不知道你的用户会在你的系统中做出什么的举动。
五超时机制
六负载均衡
根据相关负载均衡算法对流量进行合理的分配。(狭义上的负载均衡nginx F5都可以做)
如果一台服务器挂掉(假死,内存溢出等),要能够快速把改服务从服务队列中移除。(这个不能使用zookeeper等注册服务,因为注册服务是通过ping的方式
检查一个应用的状态,这样并不能判断一个服务是否宕机,nginx可以通过配置来承担这类工作,但nginx是一个中间件,最好是用jar包的方式解决这类问题)
对于挂了的服务,怎么进行快速的恢复。
七异步化设计
异步处理的目的是保主流程,增加吞吐量。对于那些不需要返回结果的边缘业务,可以通过异步来处理。
八服务限流降级和熔断
在网关层可以通过一个流量漏洞来限制一定时间内

<think>嗯,用户这次的问题是关于微服务架构分布式架构高可用架构之间的区别,需要结合站内引用内容来回答。用户之前已经讨论过单体架构微服务架构的比较,现在想深入理解更复杂的架构概念。 从用户的问题来看,ta应该是个有定技术背景的开发人员或架构师,正在做技术选型或学习系统设计。用户特别要求参考站内引用,说明ta需要权威的参考资料,而不是泛泛而谈。不过有趣的是,用户提供的引用内容其实有些宽泛,需要我从中提取关键点来精准回答问题。 先梳理三个架构的核心定义: 微服务架构本质是应用拆分方式,把单体应用拆成独立的小服务(引用[2][3]) 分布式架构是系统部署方式,强调多节点协作(引用[1][4]) 高可用架构是目标属性,任何架构都可以通过冗余等手段实现高可用(引用[1]的稳定性讨论) 用户可能存在的认知误区是以为微服务必然分布式,或者分布式必然高可用。需要澄清这些概念不在同维度:微服务是开发层面的架构风格,分布式部署层面的系统形态,高可用是运维层面的质量属性。就像建筑中"loft户型"(微服务)、"钢结构"(分布式)、"抗震设计"(高可用)的关系。 特别要注意引用[3]的细节:微服务可以部署在同服务器上,这点很多开发者会误解。而引用[4]的代码示例虽然简单,但能说明服务间解耦的思想。高可用方面,引用[1]提到的"提高系统稳定性"原则可以延伸讨论。 回答策略应该是:先用表格对比三个概念的本质维度(设计目标/核心特征等),再分章节详细解释相互关系。关键要说明: - 微服务常采用分布式部署但不是必须 - 分布式系统定是微服务(比如集群部署的单体应用) - 高可用是所有架构的共性需求,实现手段不同 最后的相关问题设计要引导用户深入技术细节,比如CAP理论在分布式系统的应用,或者服务网格这种具体方案。用户显然需要可落地的知识,不只是理论区分。</think>以下是微服务架构分布式架构高可用架构的核心区别分析,结合引用内容进行结构化说明: --- ### 、本质维度对比 | **架构类型** | **核心目标** | **关键特征** | **典型实现** | |--------------------|-----------------------------|------------------------------------------|---------------------------------------| | **分布式架构** | 解决单机性能瓶颈 | 多节点协作、任务拆分、网络通信 | 集群部署、负载均衡[^1][^4] | | **微服务架构** | 解耦复杂系统 | 服务独立开发/部署、技术异构、轻量通信 | Spring Cloud、Dubbo[^2][^3] | | **高可用架构** | 保障系统持续可用 | 冗余设计、故障转移、快速恢复 | 多活数据中心、健康检查[^1][^4] | --- ### 二、核心区别详解 #### 1. **微服务 vs 分布式架构** - **耦合关系** - 微服务:**业务维度解耦**,按功能边界拆分服务(如订单服务、支付服务)[^2][^3] - 分布式:**资源维度解耦**,将任务分散到不同节点(如计算节点、存储节点)[^1] > ✅ *示例:电商系统中,微服务按模块拆分(商品服务、用户服务);分布式将数据库分片存储在不同服务器。* - **部署独立性** - 微服务:服务可部署在**同服务器不同容器**,不强制分布式部署[^3] - 分布式:**必须跨节点部署**,依赖网络通信[^1][^4] ```mermaid graph LR A[微服务] --> B[可单机多容器部署] A --> C[可跨节点分布式部署] D[分布式架构] --> E[强制跨节点部署] ``` #### 2. **高可用架构的定位差异** - **正交性设计**:高可用是**跨架构的通用目标**,可应用于单体、分布式微服务架构[^1][^4] - **实现手段**: - 微服务/分布式:通过**服务冗余**、**自动扩缩容**实现高可用 - 独立方案:**熔断机制**(如Hystrix)、**心跳检测**、**多地域容灾** --- ### 三、典型组合场景 1. **分布式微服务架构** - 微服务部署分布式节点上 - 优势:$$ \text{扩展性} = \sum_{i=1}^{n} \text{(服务独立扩展能力)} $$[^2][^4] 2. **高可用分布式系统** - 分布式节点间设置冗余和故障切换(如ZooKeeper选举) - 满足:$$ \text{系统可用性} \geq 99.99\% $$[^1] 3. **单机高可用微服务** - 微服务部署在同服务器,通过容器隔离 + 进程监控保障可用性[^3] --- ### 四、选择建议 | **场景** | **推荐架构** | **原因** | |---------------------------|----------------------|------------------------------------------| | 大型复杂业务系统 | 分布式微服务 | 兼顾解耦与扩展性[^2][^4] | | 高性能计算任务 | 纯分布式架构 | 最大化利用硬件资源[^1] | | 关键业务系统(如支付) | 微服务+高可用设计 | 业务隔离与故障容错双保障[^1][^4] | > 💡 **核心洞察**:微服务是**架构拆分方法论**,分布式是**资源组织形式**,高可用是**质量属性**,三者可独立或组合使用[^1][^3][^4]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值