09｜综合服务治理方案：怎么保证微服务应用的高可用？
该思维导图由 AI 生成，仅供参考
前置知识
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文介绍了如何保证微服务应用的高可用性，包括高可用性的定义、核心要点和面试准备。高可用性指系统可用性达到三个九，需要通过容错、限制故障影响范围、快速发现和修复故障、规范变更流程等核心要点来实现。在面试准备方面，建议准备一个全方位的高可用方案，并重点关注前端接口限流、第三方组件的高可用方案、服务的负载均衡算法等。文章内容详实，适合技术人员快速了解微服务应用的高可用性方案。 文章还介绍了异步解耦和自动故障处理两种提高微服务应用高可用性的方案。异步解耦可以将核心业务的逻辑分成同步执行和异步执行的部分，从而减少同步执行的步骤，提高可用性。自动故障处理包括熔断、限流、降级以及自动扩容等机制，能够降低出现故障的概率和提高反应速度，进一步提升可用性。 在面试准备方面，建议根据实际经验调整高可用方案，重点掌握几种方案，并在面试中注重引导和把控面试节奏，将面试内容限制在所了解的方案上。此外，还提出了两个思考题，引发读者思考和讨论。 总的来说，本文内容丰富，涵盖了微服务应用高可用性的关键要点和面试准备建议，适合技术人员快速了解微服务应用的高可用性方案。
《后端工程师的高阶面经》，新⼈⾸单¥59
全部留言(11)
- 最新
- 精选
我好像一点都不像程序员1、每个公司对不可用时长的标准似乎不同，像我们搞sass的，标准是某个功能达到一定量的租户反馈有问题，则可算进SLA的不可用时长内。说句大实话，随着服务的增多（目前已经有上千个微服务了），几十个产品，业务的增多，人员的变动，人员能力的参差不齐，线上事故肯定还是会有的，但是我们有完善的复盘机制，也有奖罚机制，每次出问题QA都要拉人复盘，给出各种后续措施，还要全公司通报，因此管理层对服务的稳定性是十分看重，我们目前的目标也是3个9，其实只要有一个组拖后腿，这个目标就很难达成。我们目前用的很多东西都是阿里云的，没有自己搞机房，所以运维基本也都是靠阿里云的工程师来协助处理。2、其他高可用方案：多环境验证（开发、测试、予发布、生产），灰度环境验证（G0、G1、G2），代码灰度上线（根据租户力度），配置项或者数据库的执行需要管理层审核，测试来执行，服务支持跨云部署（阿里云、华为云），南北流量分发，开发流程规范，代码CR，发布回滚机制，数据库监控告警，网关流量告警，服务自动扩容，业务error日志监控告警，数据库按服务拆库隔离，按租户分库，SQL慢日志监控等等。作者回复: 大佬！还是说实话的大佬。哈哈哈，其实可用性这个东西就是出去吹牛逼的时候就会拼命吹，但是私底下自己搞的时候就知道，三个九都难，有任何一个环节掉链子就直接寄了。 所以，我也觉得，追求高可用的时候，管理难度大于技术难度；与其说是技术问题，不如说是组织问题。
2023-07-05归属地：广东39
sheep话说，由业务问题尝试的错误数据，有啥自定故障处理措施咩。好像大部分都是事后bug修复完后，写维护接口来发版更新作者回复: 这种就是业务手动修复了，你没办法解决。只有那种非业务错误，系统错误是比较容易自动修复的，比如说同步数据部分失败。
2023-09-25归属地：广东1
ZhiguoXue_IT高可用一直是微服务比较热门的词，双十一业务高峰期的时候，首先就是根据预估的量进行全链路压测，机器扩容，其次对一些核心接口进行梳理，降级作者回复: 赞！
2023-08-04归属地：北京1
nadream文章中一直没有说怎么搭建监控服务，这块可以详细说下吗作者回复: 其实就是现实中大厂用的那些技术，什么 otel, prometheus, ELK 之类的往上怼就可以了，全是苦力活。
2024-01-17归属地：浙江
LargeOrange这些三个九四个九是设计完就能得到结论还是系统运行一段时间后得到的结论？作者回复: 正常来说，嗯，理论上来说，这个是设计的时候要给出的系统运行指标。而后在系统设计与实现的过程就要达成这个指标。 现实中是，随便评估的。 不是我乱说，是很多公司的评定就是乱说，PPT 上随便写。现在还没有准确的方法来评估这个可用性。
2023-11-14归属地：北京
浩仔是程序员1. 想要达到4个9还是非常难的 2. 老师提到的高可用措施已经涵盖大部分了，在做高可用改造时，第一步就是要梳理完整的调用链路，如LVS-RS-KONG-后端服务-数据库，缓存，消息中间件，第三方服务等，每个组件都必须是高可用的。另外，可能还要考虑多机房部署，一个机房挂了，其他机房还可以正常提供服务，甚至是多大区部署。 在实际落地中，比如缓存组件，依赖于基础组件团队提供集群，在客户端需要熔断的机制，对服务进行健康的探测，自动摘除不可用的实例，通常就是一个定时任务不断的探测，及时摘除。作者回复: 赞！
2023-07-27归属地：广东
。老师，请教一下，服务正常提供服务的时间，是指完全正常，比如很多个接口，其中每个接口部分请求出现异常，这种算是正常提供服务吗作者回复: 哈哈，难倒我了，我个人是倾向于认为只要用户没有感知，就算正常提供服务，个人。 所以比如说即便触发降级了，但是用户感觉不到，那么你也可以站在整个系统的角度认为服务是正常的。
2023-07-06归属地：北京
penbox我觉得四个九还是很难的，必须所有模块都达到高可用状态才行。任何一个模块拖了后腿，没有及时恢复都做不到四个九了。故障率要低，恢复时间也必须要快。 即便是单个模块内，高可用方案涉及到申请资源（花钱），调整制度，在团队里面没有一定的话语权也很难进行推动。作者回复: 确实，我个人甚至觉得三个九就不是一个人能解决的问题，就需要上下游的团队都通力合作。
2023-07-06归属地：四川
peter请教老师几个问题： Q1：“混沌工程”指什么？ Q2：“故障演练”具体是怎么做的？ Q3：自动扩容，是由系统的一个控制中心完成的吗？ Q4：一个微服务一个数据库吗？即微服务的数据库是自己私有的吗？作者回复: 1. 混沌工程你可以读这个系列的文章 https://www.infoq.cn/article/jjp0c2bR4*Ulld0wb88r。简单说就是主动、故意注入一些故障，并且是随机的故障，然后看系统的反应。 2. 故障演练这个说起来就很复杂了，一般来说其实就是要针对被测试的系统，你认为搞出来一些故障。比如业界多活的演练，就是直接把一个机房干趴下，看多活有没有生效。 3. 一般都是有一个控制中心，它需要采集各种数据，然后判断要不要扩容，并且写法扩容质量， 4. 是的，别的服务不允许直接访问数据库，只能通过这个服务来访问。
2023-07-05归属地：北京
木几丶回答问题： 1、3个9代表8.76小时，4个9代表52.6分钟，5个9代表5.26分钟。我自己做过高可用的系统，在我的系统里可用性是3个9到4个9之间接近4个9，从我的实际落地看，要达到4个9还是很有挑战的，不可用的来源主要是几个方面：程序bug、线上变更失误或方案考虑不周、机器宕机、网络故障、机房故障，前两个属于人为，后几个属于非人为，理论上说，非人为不可用自动恢复的速度是比较快的，只要机器网络不是特别烂，4个9比较容易达成，但前提是没有人为引起不可用，可实际这是很难的。 2、其他高可用方案：机房自动切换，异地多活，规范流程（虽然文中提到了，但是还是想说，太重要了）作者回复: 规范流程：我想到一个梗，变更不规范，同事两行泪。 我很赞同你说的，都是卡在人这一个环节里面，机器能解决的问题都好解决。
2023-07-05归属地：福建
