首页
学习
活动
专区
圈层
工具
发布
    • 综合排序
    • 最热优先
    • 最新优先
    时间不限
  • 来自专栏阿甘的码路2

    稳定性治理二,稳定性分析

    【解决】: 提前做好容量规划,进行扩容 临时增加,借调服务器 限流,超过容量的请求快速返回失败,保证系统“不挂” 依赖治理 依赖的资源不稳定 特点:依赖资源,主要是指远程服务或存储,由于远程服务的响应时间变慢 依赖治理 强弱依赖识别:对关键链路的应用进行调用链路的服务进行强弱依赖分析,识别出哪些是强依赖,哪些是弱依赖。 强依赖一般指此服务不可用,流程不能往下走,直接影响功能,否则为弱依赖。 强弱依赖关系梳理方式: 手工梳理 工具扫描 日志分析 「强弱依赖的治理:」 首先不合理的依赖先去除 强依赖是否是真正的核心业务依赖,如果不是,就变成弱依赖 「对于弱依赖,一般的处理方式:」 增加业务开关

    89451编辑于 2023-08-17
  • 来自专栏Linyb极客之路

    系统稳定性治理最佳实践

    那么系统稳定性该如何治理?有没有什么标准或者可以放之四海皆准的方法论和实践? 系统稳定性问题 ? 一个系统稳定性取决于很多因素,同样也受制于很多因素。 这类问题一般来说很难预期,也很难针对问题进行专项治理。覆盖全世界网络,根本没有人可以保证网络绝对的稳定性,也根本无法保障一台服务器永远不宕机。 稳定性治理 稳定性治理的核心三板斧,监控、压测和演练。 监控 监控如果做到了360无死角,则可以第一时间主动发现系统异常,定位到了解决则是相对明确的。 总结 稳定性治理三板斧:监控、压测和演练。应用容器三要素:load、线程、GC。业务数据监控四要素:大盘、成功率、RT值、主日志。DB监控三要素:QPS、TPS、慢SQL。 系统稳定性压倒一切,只有保障了好了稳定性,才能帮助业务蓬勃增长,因此稳定性治理始终是工程师基本能力之一。

    2.3K30发布于 2020-08-27
  • 来自专栏阿甘的码路2

    稳定性治理三,故障预防、发现、处理

    稳定性相关的前置知识在前两篇文章已经说的比较多了,个人也在网上对比看了下稳定性相关的内容,都是偏概念,因此此处更加偏向于系统实战设计实现。 需要注意的是,本篇的内容说到的,需要依赖前面两篇文章提到的系统分析,需要对系统掌控全面才能针对性的制作稳定性设计策略。 稳定性治理主要是需设计故障预防、故障发现、故障处理三个环节。 自动预案 系统自动预案是指在系统出现异常或故障时,系统自动执行预先设定好的应急措施,以确保系统的稳定性和可用性。 自动调整资源分配:当系统负载过高或资源紧张时,系统自动调整资源分配,以保证系统的稳定性和性能。 本期相关 稳定性治理一,重新认识系统 稳定性治理二,稳定性分析

    1.4K31编辑于 2023-08-17
  • 来自专栏老张的求知思考世界

    被忽视的问题:测试环境稳定性治理

    目前能搜到或者说我个人看到的关于测试环境稳定性治理的文章,仅有阿里和滴滴在这方面的一些实践方法论(链接见下方)。 所以呢,这篇文章我不会去讲一些看起来很厉害的技术,而是和大家聊聊,我之前负责测试环境稳定性治理时候,面临的种种问题和痛点,我是如何梳理和分析,并尝试去解决这些问题的过程。 附链接: 阿里巴巴线下环境稳定性治理 滴滴在测试环境上的探索和实践 项目背景和痛点 先交代下背景吧,这样能更好的理解做测试环境稳定性治理的出发点和治理方案为什么要如此设计。 分析过程及治理规划 针对上述的种种问题和痛点,我用了一周的时间做调研分析和评估,最终落地了环境稳定性治理规划和方案。下面是我的分析评估和治理规划,仅供参考。 调研分析出上述几点共性问题后,我输出了如下的稳定性治理规划: 项目名称 测试环境稳定性治理 项目目的 降低测试环境不稳定因素,提升环境可用SLA;让测试同学有更充裕的时间做自己专业的事情;快速交付稳定可用的测试环支撑业务的快速发展

    1.9K10编辑于 2022-01-25
  • 来自专栏瓜农老梁

    No.174# 中间件演进和稳定性治理实践

    把 “看方向” 和 “稳定性治理” 体系化,保障驾驭的马车平稳行进。 通过容灾能力设计、遵守变更规范、落实代码评审、完善监控告警、蓝绿攻防演练、事故案例复盘等方面构建 “稳定性治理” 体系。 一、文章目录与个人介绍 二、中间件演进规范实践 三、中间件变更规范实践 四、中间件异地双活实践 五、稳定性治理内容提点 ----

    72330编辑于 2022-12-03
  • 来自专栏瓜农老梁

    FA18# 中间件稳定性治理内容提点

    引言 中间件稳定性尤为重要,本文希望梳理从各个方面形成一个体系回答这个问题。推而广之,其他技术治理也类似。

    65030编辑于 2022-12-03
  • 来自专栏java架构计划训练营

    SpringCloud Feign服务治理(2)

    2、在调用方和被调用方服务启动类入口添加注解,并配置扫描路径 @EnableDiscoveryClient //让注册中心能够发现这个服务 @EnableFeignClients(basePackages

    22710编辑于 2022-06-14
  • 来自专栏杨建荣的学习笔记

    B站服务稳定性建设:高可用架构与多活治理

    当前继续专注于核心业务多活建设推进、多活管控治理等工作。 分享概要 一、高可用多活架构 二、业务多活改造 三、多活管控与治理 一、高可用多活架构 相较于传统的灾备单活的架构,多活指的是在同城或异地的一个数据中心建立一套与本地生产系统部分或完全对应的一套服务,再进行流量调度 三、多活管控与治理 1.多活元信息规则治理 我们初期在CDN上的一些规则偏向非标,有大量的正则写法,所以我们在做第一步时就对多活元信息的规则进行了治理,APIGW接入时也应用了前缀路由的模式,以方便做后续的统一切流管理 2)切量 在切量的过程中,我们会观测业务多活流量的变化与新引入的SLO体系的相关指标。 Q2:多活如何保证数据一致性? A2:这还需要根据数据中心的分布和业务形态来进行方案的选择。若是同城,只要考虑写主库读从库的模式,强一致性的需要强制读写主库。

    1.4K21编辑于 2023-09-04
  • 前端平台大仓应用稳定性治理之路|得物技术

    为了更好的维护应用的代码,解决潜在的稳定性问题风险,2023年6月做了前端大仓的技术调研并在7月开始试行前端大仓的研发模式,在2024年年初开始对前端大仓应用的稳定性进行体系化治理,近2年时间的治理,前端大仓的应用无论在代码质量还是流程统一上都达到了一定的稳定程度 ,应用稳定性治理达到了不错的效果,从未出现因大仓稳定性治理导致的线上问题。 二、治理体系前端大仓在试行之后,经过在迭代的持续性治理,已经形成了一套完整的稳定性治理流程体系,如下:定义指标:在前端大仓monorepo研发流程模式下定义应用稳定性治理目标,治理目标是经过各业务域统一对焦且切实有效的 ;治理目标制定:在每个季度初,各业务域根据应用稳定性治理结果重新定义治理目标,写入到OKR中,作为当前季度的稳定性治理事项,各业务域因应用的质量不一样,稳定性治理指标也存在一定的区别;跟进过程:在每双周的平台周会同步各业务域在迭代的稳定性治理结果 ,不仅提升了大仓应用代码的质量和稳定性,还提升了平台轮岗、借调研发的编码效率;研发流程卡点在构建发布和MR阶段上线以后,截止到目前为止,强卡次数1200多次,弱卡次数2万多次,成功避免出现线上问题隐患130

    22810编辑于 2026-01-06
  • 来自专栏瞎说开发那些事

    服务治理 2 --- Eureka集群

    一、 高可用注册中心 在上一篇[微服务系列] 服务治理—Eureka文章中,介绍了服务注册中心的单节点搭建部署。 然而在常用的微服务结构设计中,一般都是采用分布式的环境,以避免单机故障导致服务调用不可用,所以需要对微服务中的各个组件进行高可用的部署,服务治理中的服务注册中心也是一样。 本章将结合以下的拓扑图构建高可用的服务治理。 ? 三、 快速实践 01 1. 02 2. 服务的发现与消费 1. 生产服务 服务发现与消费主要涉及到两个内容:一是发现服务,而是对发现的服务进行消费(即调用)。 2. 消费服务 服务消费者采用Ribbon负载均衡器来实现。

    720100发布于 2018-06-19
  • 来自专栏腾讯云中间件的专栏

    混沌工程在云原生中间件稳定性治理中的实践分享

    云计算提升了软件开发运维效率,云测试打破了效能瓶颈进而提升软件质量,以混沌工程为代表的技术理念保障了云上系统稳定性。新一代软件工程将从开发效能升级、软件质量提升、系统稳定性保障三个维度全面革新。 大会以“云赋新生,精益求精”为主题,以保障系统稳定性、提升软件开发效能、促进软件高质量发展为目标,探索全面上云之后企业的软件研发效能与系统稳定性的关键技术演进和落地实践。 议题分享 腾讯云Kafka产品研发负责人许文强将在混沌工程实践分论坛为大家带来以《混沌工程在云原生中间件稳定性治理中的设计与实践》为主题的精彩演讲。 当中间件出现抖动、异常、故障等稳定性问题时,业务可能就会遭受影响。而消息队列底层一般是分布式架构,其架构复杂, 严重依赖IAAS层的稳定性。 本次分享主要介绍腾讯云消息队列如何通过使用常态化的混沌工程演习去提高系统的稳定性,验证各个关键场景的自动容灾能力。

    1K10编辑于 2022-06-17
  • 瞬时高并发系统设计:从流量治理稳定性保障的实战指南

    瞬时高并发系统设计:从流量治理稳定性保障的实战指南“直播间上链接 1 秒售罄,服务器直接报 503”“春运抢票刚点提交,页面就卡住不动”“赛事门票开放抢购,3 分钟内流量暴涨 100 倍,数据库直接宕机 2. 资源竞争激烈:“大家抢的是同一份东西”瞬时高并发场景几乎都伴随 “有限资源争夺”:春运抢票抢的是 “座位”,秒杀抢的是 “库存”,门票抢的是 “名额”。 二、架构设计核心:全域流量治理,分层扛压瞬时高并发系统的设计核心不是 “硬扛流量”,而是 “让流量在每个环节都可控”—— 通过 “接入层削峰、应用层解耦、数据层保稳、基础设施弹性”,形成一套 “流量漏斗 2. 应用层:“快进快出”,不做 “重活”应用层的核心原则是 “轻量化、异步化、无状态”,避免因业务逻辑复杂导致线程阻塞,影响并发能力。 2.

    61610编辑于 2025-09-25
  • 来自专栏写代码和思考

    Spring Cloud 学习笔记(2) 服务治理 Eureka

    2. 知识 Eureka 是 Spring Cloud Netflix 微服务套件中的一部分。Netflix Eureka来实现服务注册与发现, 它包含了服务端和客户端组件。 服务注册:在服务治理框架中, 通常都会构建一个注册中心, 每个服务单元向注册中心登记自己提供的服务, 将主机与端口号、 版本号、 通信协议等一些附加信息告知注册中心, 注册中心按服务名分类组织服务清单。 image.png 在完成了服务注册中心的搭建之后,接下将一个Spring Boot 应用加 入 Emeka 的服务治理体系中去。 示例 我们将搭建 peer1 和 peer2 两个 Eureka,互相注册。一旦注册完毕后,它们之间将会互相同步。 1112/eureka/ 步骤2,第二个 Eureka 服务:peer2 的配置 修改配置文件 application.properties server.port=1112 spring.application.name

    45730发布于 2021-05-13
  • 来自专栏TakinTalks稳定性社区

    SRE实战:如何低成本推进风险治理稳定性与架构优化的3个策略

    3.3.2 评估--判断风险,确定2个高优先级 对这些风险进行评估,需要从多方面综合判断风险影响,从而来确定优先级。 任务2:调整消息存储时间,3天缩短到12小时 消息容量不足直接原因很明确,就是磁盘的容量不足导致的。 40%以上,整体硬件缩容了30% 四、总结与展望 通过上述案例,我们可以回顾之前提到的核心策略,即丰富数据、积累经验库和治理劣化场景。 由于篇幅限制,还有一些业务架构和技术架构优化、日常发布中的劣化治理的案例无法一一分享。 2、系统确实有性能问题,怎么能确保这样实施真的能出效果?比如问题是否真的能定位、经验库是否能覆盖等等。

    92610编辑于 2023-12-04
  • 来自专栏并发笔记

    手写dubbo框架2-服务治理(zookeeper探讨)

    开始进入主题,本文主要介绍的是服务的注册和发现,也就是图片中的第1,2,3步,既然要实现服务治理,那么我们需要一个统一管理服务东西,也就是注册中心。 这里多说一句,图中的2,3很明显是分两步来处理。如果只是从注册中心拿到provider而已,那为什么要分两步呢?而且我所认识的单词也有限,要是我取名的话我可能会给它取名叫做get、return。 听起来好像上述完全可以解决我们的服务治理的功能。但是这只是对于单个provider来说。 znode,如下 [zk: localhost:2181(CONNECTED) 1] ls /[zookeeper, faregistrys][zk: localhost:2181(CONNECTED) 2]

    79261发布于 2019-07-15
  • 来自专栏希里安

    微服务治理?容器治理

    微服务治理的主要目标是确保整个系统的一致性、稳定性和安全性。 服务发现与注册: 微服务架构中的服务需要能够找到彼此,这通常涉及到服务发现和注册中心,以确保新服务的自动注册和发现。 自动化: 自动化是微服务治理的核心,包括自动部署、自动伸缩和自动化测试等。 容器治理(Container Orchestration): 容器治理是管理容器化应用程序的一系列策略和工具。 容器治理实例 容器治理是确保容器化应用程序在分布式环境中可靠运行的一组实践和工具。 容器治理: 安全性容器治理可以管理访问控制、证书管理和数据加密,以确保数据的保密性和完整性。 容器治理在这个示例中涵盖了容器的自动伸缩、容器的健康监控、容器的故障恢复、持久性存储连接以及安全性和访问控制等方面。这些措施确保了容器化应用程序的稳定性、性能和安全性。

    1.1K40编辑于 2023-10-30
  • 来自专栏实时流式计算

    【译文】数据治理与BI治理

    几十年来,数据治理一直是企业关注的焦点,并随着企业数据量的急剧增长,数据治理的重要性日益凸显。然而,大规模的有效BI治理一直是一个难以实现的目标,因为它需要比传统数据治理更广泛的关注点。 毕竟,如果给用户的交付物不一致,或者缺乏适当的上下文以确保业务用户正确地理解数据,那么所谓高质量、精心治理的数据又有什么价值呢? 有效的BI治理要求组织为数据和分析的治理建立流程。 BI门户的关键治理角色体现在以下两个场景:独立的BI治理平台,或与数据目录协同工作。 什么是数据治理? 数据治理是一组确保有效管理和利用数据的过程和技术的集合。 组织中的分析师和数据管理员使用数据治理工具来执行公司治理政策,来促进数据的正确使用。 应用这些工具进行数据治理需要大量的持续投资,因此许多组织希望从这些投资中获得可观的投资回报。 什么是BI治理

    1.5K40编辑于 2023-03-24
  • 来自专栏橙子架构杂谈

    【服务治理】服务治理漫谈

    …… 2. 超长的调用链路路和多个单点系统,将会在服务规模上升时引发稳定性和性能问题。在丁丁租房和美团就多次发生类似的单点故障。 这一步到位地解决了单点长链路的问题,且能够在直连的基础上,进行更大的性能优化和稳定性的抬升。 牺牲一定的性能和资源,换取服务治理理整体的⾼高度⾃自治和可运营 2. 执⾏行行和控制分离,数据平⾯面和控制平⾯面切割 3. 虚拟化、标准化、产品化,定义规范。 2. 咨询第二定律:不管一开始看起来什么样,它永远是人的问题。 人是复杂的动物,你必然会发现,脱离组织结构来谈最佳的系统设计是不切实际的。

    4K31编辑于 2021-12-06
  • 来自专栏韩曙亮的移动开发专栏

    【数字信号处理】离散时间系统稳定性 ( 稳定性概念 | 稳定性用法 )

    文章目录 一、离散时间系统稳定性 二、离散时间系统稳定性实际用法 一、离散时间系统稳定性 ---- 线性时不变 LTI 系统 , 如果 " 输入序列 " 有界 , 则 " 输出序列 " 也有界 ; 充要条件 : \sum^{+\infty}_{m = -\infty} |h(n)| < \infty 二、离散时间系统稳定性实际用法 ---- 实际用途 : 设计一个 滤波器 , 设计完 滤波器参数 后 ,

    3.9K30编辑于 2023-03-30
  • 来自专栏Listenlii的生物信息笔记

    网络属性专题2-脆弱性及组成稳定性

    组成稳定性(compositional stability): 评估群落结构随时间的变化。 网络中微生物群落的组成稳定性计算为: 公式中,v为同一地点在多个连续时间点采集的样本数,S为网络中总OTU数。yi,k为样本i中OTU k的丰度。 (ps:这个指数一般用来计算带时间节点的数据) 在文章中的应用为: 图中显示的是时间间隔为一年条件下(order=2,其中x轴的1表示的第二年与第一年之间的网络物种组成稳定性值,2表示的是第三年与第二年之间的网络物种组成稳定性值 这里的图中显示的就是order=3,4,5,6条件下,网络物种组成的稳定性值。 Long-term exposure to elevated CO2 enhances plant community stability by suppressing dominant plant species

    2K20发布于 2021-08-27
领券