猜你喜欢
高性能之道: SRE视角下的运维架构实践

高性能之道: SRE视角下的运维架构实践

书籍作者:王力 ISBN:9787121454585
书籍语言:简体中文 连载状态:全集
电子书格式:pdf,txt,epub,mobi,azw3 下载次数:4620
创建日期:2024-04-03 发布日期:2024-04-03
运行环境:PC/Windows/Linux/Mac/IOS/iPhone/iPad/Kindle/Android/安卓/平板
下载地址
内容简介

本书从实践出发,包括了作者参与并主导的3家电商互联网公司架构从0到1的构建经历,从多个角度讲解稳定、性能、效率、成本四大职责落地经验,并结合Mikey金字塔进行了部分创新,很多内容都可以直接复用于实际工作。本书分为7篇,分别是开端篇、监控篇、故障篇、容量篇、全局视角篇、性能篇和扩展篇。

本书适合互联网行业内的运维人员、SRE和DevOps工程师、架构师、技术团队负责人及关注用户体验的相关开发者阅读,也适合掌握了一定的SRE方法论但在实践中无从下手的读者阅读。


作者简介

本书主要作者王力,资深技术老兵,《Nginx实战:基于Lua语言的配置、开发与架构详解》和《高性能之道:SRE视角下的运维架构实践》作者。15年互联网从业经验,其中有9年电商互联网开发和运维经验,这期间担任过微拍堂运维专家、阿里技术专家、折800运维架构师等,并有5年主导电商大促活动保障的落地经验,推进过折800、微拍堂两家电商平台运维架构从0到1的建设,精通服务的稳定性建设,精通高并发场景下的性能优化和中间件开发,擅长通过架构设计来优化系统复杂度、降本增效。

编辑推荐
适读人群 :本书适合互联网行业内的运维人员、SRE和DevOps工程师、架构师、技术团队负责人及关注用户体验的相关开发者阅读,也适合掌握了一定的SRE方法论但在实践中无从下手的读者阅读。

本书亮点和创新技术实践思路
√ SRE性能优化漏斗优化法则:全书用十几个章节介绍相关技术实践,体现了整个法则的收益。
√ 标准和规范治理平台的设计思路:是解决技术体系各项规范落地难、长期治理效果差的闭环解决方案。
√ HTTP故障降级理论和实践:从电商平台业务中抽象出降级模型,提出了创新的故障降级解决方案,相关思路不局限于解决电商平台业务问题,还可以扩展到其他一些领域(前提是运维人员深刻理解业务)。
√ 云原生可观测性开源工具Kindling的介绍及实践价值:针对目前云原生下海量日志分析难、定位问题难等进行的优秀实践。
√ 全视角解读运维架构建设中的各种矛盾和破解思路。

《高性能之道: SRE视角下的运维架构实践》电子书免费下载

pdf下载 txt下载 epub下载 mobi下载 azw3下载

前言

请各位读者耐心地看完下面的内容,这些内容是阅读本书之前必须了解的,可以让你们更清楚地理解本书想要表达什么,而不应只把本书当作一个方法论的实践手册。另外,下面也会告诉大家为什么笔者使用“高性能之道”作为本书的书名。

众所周知,SRE工程师有几类重要职责:延迟优化、性能优化、效率优化、稳定性优化、容量规划、应急响应等。随着SRE在国内的流行,很多运维团队开始转型,包括一些架构师、后端工程师、系统工程师也纷纷加入其中。在这个SRE实践日渐丰富的情况下,笔者想讲两件事情:一件坏事,一件好事。

第一件事情:互联网行业现状对技术的影响。几年前,或者说给人留下深刻印象的2011-2019年,互联网平台百花齐放,团购、电商、游戏、聊天软件等,基本上日常的生活方式都走进了互联网。也正是因为互联网发展迅猛,我们选择使用IT成本、人力成本交换时间,代码质量不高、架构设计不佳等问题都通过投入更多的成本暂时得到了解决。虽然这样做可以解决大部分性能问题,甚至隐藏不稳定的架构风险,让业务继续往前推进,但留下了很多技术债。

那段时间其实已经出现了SRE角色,虽然国内的SRE起步较晚,但也不断地发挥出了价值。那几年,SRE工程师的核心职责中保障稳定性、效率是高于优化成本和性能的,或者说成本和性能也需要优化,但相比其他目标,被降低了优先级。但在2020年后,互联网行业出现了明显的疲态,这对我们互联网技术人来说,是一件坏事。这时大多数公司面对“寒冬”开始开源节流,成本优化被反复拉上日程,甚至有云厂商专门为云产品客户提供了专业的成本优化方案。大幅度地优化成本,如果只是单纯地缩减使用效率低的机器,将无法满足公司迫切节约成本的需求,而且一旦服务器资源减少,曾经性能不好的代码和架构问题都会浮出水面,甚至会导致辛辛苦苦节约的成本被一次偶发故障就抵扣了,得不偿失。因此,成本优化往往要伴随着架构优化、代码重构,甚至业务逻辑优化,简而言之就是性能优化。面对这种突然发生的改变,SRE工程师如何从容面对?

第二件事情:国内的SRE工程师大多从运维工程师转型而来,对性能优化、延迟优化缺乏经验,很难发挥出SRE工程师应具备的各项能力(当然很多公司也没有对团队的SRE工程师提出这样的要求)。部分有独特见解的团队,在成立SRE团队时,除了运维工程师,也引入了业务开发人员、基础架构师、系统工程师等有较强高并发开发经验和系统底层认知能力的成员,他们对性能的要求是极致的,为服务的SLA达标,设计更精妙的架构,而这些不是传统运维人员可以达到的,国内的SRE已经开始向更高阶的路线发展。虽然这又增加了SRE的技术难度,但是是一件好事,让我们可以拥有更全面、更有深度的技术。

下面举几个常见的例子。

(1)业务开发人员开发了一些动态接口,其实可以适当配置1~2分钟的CDN缓存,但并未配置,导致回源请求量高、带宽成本高,响应速度和性能也未达到最佳。

(2)NoSQL使用场景少,过度依赖MySQL,成本高,响应速度和性能也未达到最佳。

(3)客户端请求数据太多,实际应用中,只使用了部分数据,浪费了带宽,数据太多甚至意味着可能存在太多的数据处理操作,响应速度和性能也未达到最佳。

(4)在页面渲染过程中,部分数据是不需要提前加载的,但前端工程师设计了大量预加载任务,导致了大量无效计算和网络开销,响应速度和性能也未达到最佳。

(5)业务开发人员对某个接口设置了1分钟的Redis缓存,但根据业务场景,这个接口的缓存其实可以设置为10分钟,这导致请求量减少得不多,响应速度和性能也未达到最佳。

诸如此类,各种问题累加在一起,极大地增加了系统的资源开销,这会影响成本优化,也会影响服务性能,而高性能可以提升成本优化的效果,也可以优化业务架构、延迟等现象,帮助我们更好地提升用户体验。

基于这两件事情,笔者使用“高性能之道”作为书名,本书会从SRE工程师的职责进行讲解,通过实践让读者更好地理解,这些职责在工作中是相辅相成的、共同发挥作用的。这几年互联网行业“内卷”严重,但也正是全面发挥SRE工程师职责的好机会。寒冬闭关苦修,静待春风到来!


前 言

写书的目的:破圈之道

从运维的范畴讲,我认为,在一个开发团队内,除了业务需求实现层面的事情,其他都属于运维的范畴,这个范畴内的事情本质上就是为软件生命周期内的运行维护阶段服务。

——来自赵成的运维体系管理课


以上是蘑菇街运维总监赵成的运维体系管理课中的一段经典语句,如果正在看本书的你是运维人员,可以认真地理解一下这段话,然后与自己的工作职责进行一下对比。

运维人员长期以来的工作职责都是围绕成本、安全、效率、稳定来开展的,这和SRE工程师的工作职责有很多相同点。但现在仍然有不少运维人员将掌握各项基础设施的维护、配置和监控当作工作职责,这样合适吗?如果你所在的公司对运维人员的要求就是支撑和辅助,而你本人也完全接受,那么无可厚非;但如果你在一家产品不断迭代、不断创新的公司做运维工作,笔者相信这些能力是远远不够的,除非你就打算“躺平”。

通过本书,笔者希望可以让更多的运维人员改变以往的工作模式,摒弃常年仅做后方保障工作的习惯,运维人员需要站在团队的最前面,统筹所有与运维架构有关的问题,在保障承诺的稳定性指标的前提下,尽最大的努力完成业务迭代、成本优化、性能优化、容量规划等工作。

本书以SRE的视角解读运维架构,运维架构并非指传统意义上的配置、安装、维护等,而是除了业务开发,其他都属于运维架构范畴,这些最终都是为了在合理的效率和成本前提下,让用户可以享用稳定的服务。

本书会通过一系列实践和案例突出以下3个基础思想。

(1)绝大部分用户体验不顺畅,从运维视角都能看出端倪,通过对性能、容量、响应速度等维度的分析,可以推进代码规范、质量等方面的改进,最终提升用户体验。

(2)在保障稳定性建设正常开展的前提下,最大化地降低用于应对技术风险的运营成本。

(3)除了业务开发,其他都属于运维架构范畴,但只有了解了业务和业务开发,才能更准确地完善运维架构。

这些基础思想可以支撑运维工作的整个生命周期,同样为其他技术岗位人员更好地实现跨部门共建提供解决思路。

读者对象

本书内容是通过大量工作经验总结得到的知识和技术方案,读者需要一定的积累才能更深刻地理解其中的价值。对于刚入行的运维人员,建议先熟悉运维架构工作或SRE方法论,再进行学习。

本书适合互联网行业内的运维人员、SRE和DevOps工程师、架构师、技术团队负责人及关注用户体验的相关开发者阅读,也适合掌握了一定的SRE方法论但在实践中无从下手的读者阅读。

本书内容

本书的大部分内容是以笔者9年电商行业运维和开发经验为基础进行的讲解,其中将电商行业与SRE中的Mikey金字塔相结合进行了创新,很多内容都可以直接用于日常工作(本书不会过多地介绍SRE基础知识,若读者想要学习相关知识,可以自行上网搜索谷歌SRE的相关文章)。

本书分为7篇。

开端篇,主要讲解SRE和运维架构之间的关联性和SRE的工作范畴,解读了岗位职责和一些日常非核心场景中容易被忽略的点,以及应该重视测试环境和预发布环境。

监控篇,主要讲解监控落地时容易被忽略的地方,并且提供了可持续维护监控对象的一些方法,提出了监控新思路——监测和控制,而不是以往运维视角下的以触发报警为核心的监控逻辑,监控应该发挥控制的效果,比如在监测到技术风险时,执行一系列动作来控制风险。

故障篇,主要讲解在故障的整个生命周期内,运维人员和SRE工程师应该担当的职责,并将故障分为事前治理、事中应急、事后改进三大板块,基于每个板块给出什么时间节点做什么事情的指导建议。

容量篇,主要介绍业务和容量的关系,并且讲解在容量规划中通过什么样的方式能够更好地实现成本、性能的平衡,而且在该篇章中,增加了对编程能力的介绍。编程能力能让我们更理解资源消耗是如何产生的,为我们更好地与业务开发人员探讨资源配置的合理性做好准备。

全局视角篇,主要介绍如何从各个技术岗位的视角看待运维架构中的各项事务,同时以用户视角讲解SRE的价值,为运维破圈做准备。

性能篇,主要通过介绍各性能优化技术方案,提供可实战的落地任务,给出工作中常见的技术难题和解题思路。

扩展篇,主要介绍在共建稳定性的过程中如何更好地应用整个技术体系,给出如何将技术思想和技术方案进行跨部门分享和推广的实践。

勘误

本书以实践为主,绝大部分内容是电商行业的技术实践,可能存在考虑不周全的地方,再加上运维架构相关内容烦琐复杂,在体系化的打造过程中难免存在疏漏和错误,请读者朋友多多见谅。如果你发现本书中存在的任何问题或者希望提出建议,请联系笔者,笔者的QQ邮箱是[email protected]。

致谢

本书中有部分内容来自其他作者的共同努力。在他们的帮助下,笔者才得以将整套实践体系打造完善。笔者要特别感谢以下成员。微拍堂运维团队:田红阳、柴振华、刘占彬、张博、刘帅、李秋阳、陆游、姜伯洋、章远强、涂永春、陈建华、李启龙等。Kindling开源团队。技术专家周云龙、索碧桐。网易SRE工程师陆游。

特别感谢微拍堂创始人徐烽、金明亮,在他们的大力支持下,笔者才有充足的时间将本书打磨完善。

感谢电子工业出版社博文视点的编辑付睿,她在本书的出版过程中提供了很多宝贵的建议。


目录

开端篇 弱化边界感

第1章 引言3

1.1运维架构和SRE3

1.2理解业务,技术为业务服务5

1.3不设边界6

1.4SRE金字塔6

1.5总结7

第2章 重视测试环境和预发布环境8

2.1提效和维稳的第一道门槛——测试环境9

2.1.1低级错误9

2.1.2提效分析10

2.2“守门员”——预发布环境11

2.2.1低级错误11

2.2.2提效分析12

2.3两大环境问题根本原因溯源12

2.4微拍堂测试环境治理思路介绍13

2.5总结17

监控篇 底层逻辑的艺术

第3章 浅谈监控系统设计21

3.1梳理监控体系21

3.2梳理监控指标22

3.3变更监控25

3.4准实时系统监控25

3.5短时进程追踪工具27

3.6全链路监控27

3.7商业监控平台的选用建议28

3.8监控方式:白盒监控与黑盒监控29

3.9从监控数据中总结规律30

3.10黄金指标30

3.11总结31

第4章 云原生可观测性开源工具——Kindling32

4.1行业现状32

4.2Kindling解决方案——关联内核可观测性数据的Trace34

4.3Kindling探针的架构设计理念37

4.4Kindling探针架构38

4.4.1内核态程序:drivers38

4.4.2用户态C/C++程序:kindling-probe38

4.4.3用户态Go程序:kindling-collector39

4.4.4程序间通信方式40

4.5在线Demo介绍41

4.6案例分享42

4.6.1安装43

4.6.2功能介绍44

4.6.3稳定性价值47

4.7总结48

第5章 高阶实战——打造可持续维护的闭环流程49

5.1案例:动态观测SQL质量流程设计50

5.1.1分析规范难以落地的原因50

5.1.2监督与管控流程设计51

5.1.3通知和统计57

5.2案例:WebP格式图片的规范和落地实践57

5.2.1规范无法持续推广57

5.2.2成本和用户体验上的双赢58

5.2.3计划实施60

5.2.4管控机制60

5.2.5采集数据信息和数据加工处理60

5.2.6巡检平台之规范化监督61

5.3案例:管道通信规范化实践62

5.3.1我们每天都在使用管道62

5.3.2管道示例场景及性能说明64

5.3.3如何规范管道使用场景66

5.4标准和规范治理平台67

5.4.1现状68

5.4.2设计思路68

5.5总结72

第6章 挖掘Nginx的监控价值73

6.1URI指纹服务设计73

6.2Nginx日志分析指南76

6.2.1参数白名单76

6.2.2URI的响应时间和HTTP状态监控77

6.2.3URI响应字节数波动分析77

6.2.4查询URL请求的项目79

6.2.5注意HTTPS的透传80

6.2.6利用Nginx完成动态全链路比例调整81

6.3总结82

故障篇 故障的生命周期

第7章 事前治理的方法论85

7.1从故障中总结经验85

7.2从系统资源层面和日志中巡检异常86

7.3从标准和规范中寻找闭环之路86

7.4从业务中挖掘基础服务的使用问题87

7.5技术风险防控运营成本87

7.6总结88

第8章 变更管控设计思路89

8.1变更管控89

8.1.1变更对象89

8.1.2变更发布90

8.1.3变更可灰度91

8.1.4变更可回滚92

8.1.5变更可监控92

8.1.6配置项变更92

8.1.7变更管控思路92

8.2JumpServer使用的艺术及工单交互96

8.3变更三板斧:运维团队的可监控、可灰度、可回滚实践98

8.3.1案例:云服务器资源伸缩稳定性98

8.3.2案例:CDNOpenResty的变更策略102

8.4总结106

第9章 轮值的设计思路107

9.1值班模式探究108

9.1.1让开发人员参与其中108

9.1.2制定KPI109

9.1.3值班人员的边界探讨110

9.2值班机器人111

9.3提升值班价值——SRE需求池设计112

9.3.1结合日常巡检与非值班时间112

9.3.2在烦琐的工作中收集需求112

9.4总结113

第10章 故障演练与应急预案114

10.1故障演练缘由114

10.1.1更好地面对系统规模增长带来的复杂性115

10.1.2提升故障的排查速度115

10.1.3验证应急预案的正确性115

10.1.4验证基础设施的稳定性116

10.1.5验证监控感知能力116

10.1.6验证应急流程的顺畅度116

10.2故障演练流程116

10.2.1故障演练场景关键要素116

10.2.2故障演练预期117

10.3应急预案119

10.3.1应急场景标准化120

10.3.2梳理应急预案清单120

10.4总结121

第11章 应急响应流程实践122

11.1收拢故障上报来源122

11.1.1从技术体系内部发现122

11.1.2从技术体系外部发现123

11.2建立应急小组123

11.2.1人多力量弱123

11.2.2稳定性接口人和岗位权限123

11.2.3完善客诉标准化术语124

11.3故障噪点治理124

11.3.1报警治理124

11.3.2设计外部反馈阈值125

11.3.3收集第三方抖动事件125

11.4控制应急节奏126

11.4.1舍小保大126

11.4.2“优先止血”,后续定位根本原因127

11.4.3及时同步信息,减少信息差127

11.5应急“止血”的常见操作127

11.5.1代码回滚127

11.5.2重启128

11.5.3时序监控下的限流、熔断、扩容129

11.5.4业务降级130

11.5.5阻断慢查询131

11.5.6网络与运营商131

11.5.7重识监控132

11.6总结132

第12章 静态容灾降级系统133

12.1荆棘之路134

12.2设计之路136

12.3架构流程图138

12.3.1反向代理系统138

12.3.2日志分析系统138

12.3.3后台系统——利用URI指纹服务138

12.3.4爬虫系统139

12.3.5容灾的缓存系统140

12.3.6基于时间的版本用途140

12.3.7异地容灾141

12.4核心代码解说142

12.4.1Ngx_Lua应用142

12.4.2爬虫和日志分析系统的关系143

12.4.3完全容灾和部分容灾功能144

12.5静态容灾的智能关闭方案145

12.5.1从日志分析系统复制请求145

12.5.2利用GoReplay复制流量145

12.5.3利用Nginx的mirror镜像功能146

12.5.4灰度验证容灾系统缓存——闭环设计147

12.6替换爬虫的新思路148

12.7总结148

第13章 基于OpenResty的动态限流设计思路150

13.1常见反向代理限流方案缺点分析150

13.2动态限流设计思路151

13.3多维度限流154

13.4智能感知响应能力动态控速设计方案157

13.5屏蔽慢请求带来的服务阻塞159

13.6总结160

第14章 故障复盘161

14.1复盘前161

14.2复盘中161

14.3复盘后164

14.4自省164

14.5跨部门分享165

14.6故障库165

14.7总结165

容量篇 性能与成本间的平衡

第15章 成本优化169

15.1成本优化事前准备169

15.1.1目标的制定和价值体现170

15.1.2IT成本与人力成本的权衡170

15.1.3提升对系统的理解171

15.1.4评估优化前后的数据统计及业务影响171

15.1.5从用户体验看待成本优化173

15.1.6梳理业务和资源的关系173

15.2公有云基础资源优化实践174

15.2.1成本管理白皮书174

15.2.2合理化资源使用率177

15.2.3自建产品和云产品的使用场景优化178

15.2.4基于业务场景的成本控制179

15.3总结180

第16章 智能伸缩平台181

16.1弹性伸缩平台关键路径盘点181

16.2基础设施建设182

16.2.1基于Pod的HPA传统模式182

16.2.2基于Cluster-Autoscaler的Node伸缩184

16.3基于业务场景的实战189

16.3.1定时伸缩189

16.3.2基于预测的弹性伸缩191

16.4风险控制体系199

16.4.1动态限流触发规则199

16.4.2扩容节点失败和业务降级200

16.5总结200

第17章 容量规划201

17.1容量规划现状201

17.2容量规划建设思路202

17.2.1建设核心202

17.2.2建设思路203

17.3应用系统容量规划说明204

17.4基于巡检模式的容量评估流程205

17.4.1对流量来源的梳理205

17.4.2对容量对象的梳理206

17.4.3收集日常关键性数据207

17.5对容量规划关注点的梳理210

17.5.1压力测试210

17.5.2业务放量212

17.5.3大促活动213

17.5.4秒杀业务214

17.5.5关注运营活动计划214

17.5.6尖刺限流215

17.6总结215

第18章 编程能力216

18.1养成写伪代码的习惯216

18.2养成管理代码的习惯217

18.3编程能力分级218

18.4编程能力更深层的价值探讨219

18.4.1如何看待PHP短连接问题219

18.4.2理解Redis和Memcached在业务场景上的区别220

18.4.3进程、线程、协程在Linux系统中的表现221

18.4.4探究阻塞和非阻塞、异步和同步在系统中的表现223

18.4.5共享内存224

18.4.6尝试一些导致进程崩溃的操作224

18.4.7学习秒杀系统的业务架构225

18.4.8给自己的代码做闭环实践226

18.4.9参与业务开发日常226

18.5熟悉编程语言特性226

18.6通过系统分析倒推应用配置问题227

18.6.1通过access函数发现PHP性能问题227

18.6.2Java连接池失效228

18.7总结229

全局视角篇 运维破圈

第19章 开启测试视角233

19.1测试人员的职责边界233

19.2压力测试234

19.2.1压测黑名单思维235

19.2.2压测利器Wrk235

19.2.3流量镜像工具GoReplay235

19.3自动化测试监控平台设计237

19.3.1“牵一发而动全身”的迭代238

19.3.2OpenDiffy介绍238

19.3.3变更管控的支撑系统OpenDiffy+GoReplay239

19.4破坏性测试探究239

19.5从前端的体验“找碴儿”240

19.5.1基于浏览器特性的服务优化240

19.5.2从图片加载中寻找优化方法241

19.5.3数据埋点的发送频率242

19.5.4域名的使用限制243

19.5.5请求重复性243

19.5.6PageSpeedInsights分析页面的加载243

19.5.7定期的内耗分析245

19.6总结245

第20章 开启用户视角246

20.1内外兼顾246

20.1.1内部用户247

20.1.2外部用户248

20.2建立反馈机制249

20.2.1优化客服反馈机制249

20.2.2与客服合作的案例分享249

20.2.3奖励机制250

20.2.4关注舆情250

20.3产品体验——谷歌SRE的高阶思维251

20.3.1不仅仅是体验251

20.3.2交互烦琐252

20.3.3无人问津252

20.3.4ROI252

20.4防御体系的“误伤”指南253

20.4.1WAF“误伤”253

20.4.2内部风控“误伤”254

20.5关注客户端环境254

20.5.1客户端机型配置254

20.5.2网络255

20.6总结255

第21章 开启前端和App开发人员视角256

21.1概述256

21.2为什么要解决性能问题257

21.3缓存257

21.3.1强缓存257

21.3.2协商缓存259

21.4网络请求261

21.4.1HTTP/2.0261

21.4.2DNS预解析262

21.4.3预先建立连接262

21.4.4服务器应该避免过多重定向263

21.5客户端计算263

21.6预加载265

21.7梳理技术风险265

21.7.1请求阻塞式串行加载266

21.7.2埋点发送过于频繁266

21.7.3弱网下的资源加载降级266

21.7.4拨测266

21.8总结267

第22章 DNS应用场景实践268

22.1利用DNS完成故障转移268

22.2使用HTTPDNS提升访问稳定性271

22.3提升测试、A/B测试等环境的切换效率273

22.4域名反向解析用途实践273

22.5内部DNS系统高可用实践274

22.5.1两次DNS故障275

22.5.2问题和思考276

22.5.3改进措施278

22.5.4配置及验证279

22.5.5监控283

22.6总结284

性能篇 SRE进阶之路

第23章 高并发网关价值探究287

23.1通用功能介绍287

23.2网关中的聚合模式288

23.2.1Lura启示录289

23.2.2APISIX中的batch-requests插件289

23.2.3从GraphQL发现的技术实践思路291

23.3兼顾缓存的网关设计思路293

23.3.1APISIX的proxy-cache插件293

23.3.2利用聚合拼接缓存资源293

23.3.3鉴权和缓存剥离294

23.4总结295

第24章 高性能Varnish缓存系统296

24.1HTTP缓存对后端服务的价值分析296

24.2CDN缓存和Varnish缓存的共存模式298

24.3安装Varnish和所需模块299

24.4配置文件概览300

24.5稳定性建设所依赖的功能300

24.5.1神圣模式300

24.5.2宽限模式——异步缓存更新302

24.5.3更安稳的软清除303

24.6最佳实践304

24.6.1动态缓存时间配置304

24.6.2热Key及秒杀系统的缓存实践305

24.6.3后端服务故障转移306

24.6.4高并发下Varnish启动参数优化307

24.6.5Varnish配置模板优化实践307

24.6.6测试环境缓存系统的干扰事件309

24.7总结309

第25章 SRE漏斗优化法则310

25.1SRE性能优化之漏斗优化法则311

25.2漏斗优化法则的技术栈梳理312

25.2.1减少访问量312

25.2.2减少返回的数据313

25.2.3减少交互次数313

25.2.4降低CPU、内存使用率314

25.2.5提升资源利用率314

25.3总结315

第26章 awesome性能分析工具316

26.1站在巨人的肩膀上工作316

26.1.1系统性能分析常见清单317

26.1.2bcc-tools工具清单319

26.1.3火焰图320

26.2Netdata320

26.3总结321

第27章 性能优化实践锦集322

27.1TIME_WAIT优化方案扩展322

27.2利用Ngx_Lua缩短请求链路323

27.3eBPF在Kubernetes上的应用325

27.3.1kubectl-trace325

27.3.2使用前提325

27.3.3使用优点325

27.3.4使用场景326

27.3.5安装326

27.4善用CDN327

27.4.1静态加速327

27.4.2动态加速328

27.4.3缓存过期保护策略328

27.5记一次中台服务优化实战329

27.5.1寻找优化目标330

27.5.2抽丝剥茧——尝试优化方案331

27.5.3使用gopprof火焰图发现端倪333

27.5.4回顾复盘337

27.6总结337

扩展篇 在团队间搭建桥梁

第28章 业务开发人员视角下的技术风险341

28.1了解业务开发人员342

28.1.1工作内容342

28.1.2废弃十年如一日343

28.1.3重构并非易事343

28.1.4发布前的检查清单344

28.1.5站在巨人的肩膀上编程344

28.1.6拒绝伪需求345

28.2大淘客之旅346

28.2.1对话高层,达成共识346

28.2.2对话业务线负责人347

28.2.3重识目标,各个击破347

28.2.4技术氛围和激励政策348

28.2.5“曲线救国”的技术路线348

28.3总结351

第29章 SRE视角全篇总结352

29.1齐心协力353

29.1.1关键要素353

29.1.2华山论剑353

29.2竞品分析——最后1公里355

29.3故障降级系统——来自监控的沟通艺术355

29.3.1抽象业务形态355

29.3.2抽象监控触发条件357

29.3.3收拢零散性的自愈任务357

29.4重识CMDB价值357

29.5总结358

产品特色