何谓系统稳定性?
控制系统理论认为:系统受到某种干扰而偏离正常状态,当干扰消除,如果系统的扰动能逐渐收敛并最终恢复正常状态,则系统是稳定的;反之,系统偏离越来越大,则是不稳定的,所以,稳定性是系统抗干扰和返回平衡状态的能力。
对于经典的传递函数的软件系统,一般我们讲的稳定指的是BIBO稳定,即有界输入有界输出稳定。一个系统如果对任意有界输入得到有界输出,它就是BIBO稳定的。一句话,稳定的系统对于各种输入需要有符合预期的输出。
随着软件复杂性越来越高,稳定性的保障越来越难,随着服务规模越来越大,稳定性的重要性越来越高。阿里云CEO行癫把稳定性比喻成木桶的底板,如果稳定性出问题,则滴水不留,所以,工程师在设计和开发软件的时候,要坚持底板思维。
我们的软件需求和计划很少考虑非功能部分,然而软件的结构和实现却有非常大的比重服务于此,这也许是软件项目计划经常延期的重要原因。
如何保障稳定性?
虽然理论上没有绝对稳定的系统,但我们依然可以有所作为,使我们设计和开发的系统在生产环境接近稳定运行。
从大的方面讲,稳定性保障,可以分成3个部分:
制度纪律
- 编码规范、代码提交门禁
- Code Review
- 静态代码扫描,动态代码分析
- Unit Test、压测
- 灰度发布、Rollback、应急预案
- 监控
- 复盘、故障树分析
思想之道
- 保持简单、降低复杂度
- 不(零)信任、面向失败设计
实践之术
- 冗余设计(数据、计算、带宽冗余)
- 快速恢复设计(无状态设计)
- 容错、灾备
- 隔离
- 过载保护(限流、熔断、有损服务)
- 错误重试策略,避免流量风暴
- 去关键路径、去中心化、避免单点故障
- 负载均衡(load balance)
- 看门狗设计
- 安全编码
制度纪律
通过制度去规范操作和行为,通过纪律去约束大家在框架内活动,被证明是保障稳定减少出错行之有效的方式。
纪律是关键,只有持之以恒的遵守制度,才能避免方法和规定沦为空谈。
但制度和纪律只是划出质量底线,只能解决大多数稳定性问题,难以发现一些隐匿的问题,需要配合思想之道和实践之术,持续改进软件质量,才能全面保障稳定性。
思想之道
道是大的层面,它具有全局性的指导意义,我从众多的指导思想里,挑选最重要的两点:保持简单和不信任/面向失败设计,展开来讲。
-
保持简单
复杂是稳定性的天敌,保持简单即保持稳定。单一职责,功能清晰即是践行保持简单。把简单的东西搞复杂很容易,而化繁为简则堪称化腐朽为神奇。所以保持简单并不是低要求,它需要你透过表象洞悉事物本质,用最直接最土味的方式解决问题,做技术的同学有一个奇怪的癖好,喜欢把自己最近琢磨的东西用到项目中,不然总有锦衣夜行的感觉。
我的建议是“学深用浅”。引入复杂性,一方面要权衡收益,另一方面要警惕损伤,要理解项目开发很多时候是团队合作,任何复杂性的引入都会对合作者提出更高要求,严以律人是危险的,低门槛才是符合人性的。
-
不信任设计、面向失败设计
不信任设计又叫零信任设计,和面向失败的设计有相似之处,其本质都是防御性编程思想。不信任设计思想假设系统依赖的上下游都不靠谱,假设周围都是坏人,假设攻击无处不在。
网络服务需要对客户端请求参数做严格验证,不仅检查合法性,也要验证NaN。游戏开发有一句名言:假设客户端的数据都是假的。
进程内的函数调用大多时候很安全,会有可预期的结果,但如果跨进程调用(RPC)的可靠性则会低很多,有可能超时,有可能丢包,有可能失败,调用者必须意识并处理好各种异常情况,是重试?如果重试的话重试多少次?重试之间的间隔应该怎么确定?请求的上下文怎么保存和恢复?
我们要正确理解不信任设计的内涵,避免用力过猛,警惕借面向失败设计之名行无效编程之实,比如已经对客户端请求数据做了严格校验,在服务器处理过程中,重复检验,比如已经对接口入参判空,在内部调用过程中重复判断。这会降低代码浓度,混入大量无效代码,损伤可读性和执行效率,本质上是违背“保持简单”原则的。
实践之术
术是局部层面,它是实践经验,牵扯方方面面,难以尽数枚举。
如果以文章写作类比软件开发,谋篇布局相当于设计层面,设计层面要致广远,遣词造句相当于实现层面,实现层面要尽精微。
所谓千里之堤溃于蚁穴,防微杜渐功德无量。
-
冗余设计
冗余设计指留出安全余量,冗余包括数据冗余、计算冗余、带宽冗余。数据冗余指一份数据多个副本,一主多备。
计算冗余,比如服务实例的QPS极限是10K,但实际上我们会按5K跑,这样,即使出现流量超速增长,我们依然有反应时间。
-
快速恢复设计(无状态设计)
互联网服务很多都是无状态设计,服务实例只是逻辑的盒子,后面跟着分布式一致性数据库,这样能极大简化设计,即使实例挂了,客户可以很容易迁移到其他服务实例执行,而有状态设计则要复杂难搞得多。 -
容错、灾备
容错指我们的系统要有一定的错误容忍能力,这意味错误发生,我们要能查错、检错、避错、甚至改错,只要可能,我们就要吞咽错误。灾备这个大家耳熟能详,主从设计,异地备灾,目标都是为了应对各种极限情况。
-
隔离
隔离本质上就是说如果故障发生了,如果故障发生,而又不能吞咽,那也应该隔离避免错误传播扩散,千方百计缩小影响范围,相当于感染新冠要被隔离起来。容器化等技术为隔离提供良好能力支撑。 -
过载保护
-
熔断
熔断机制不止软件设计独有,股市也有,我甚至怀疑软件的熔断机制是从股市学来的。 -
限流
系统设计要做好资源耗尽、资源不够用的情况,如果服务请求超过服务能力,那就应该限流,这应该作为一种配置,或者自动执行的策略。这个跟地铁限流差不多,处理不了,那就排队。
-
有损服务
有损服务我印象中最先是腾讯跟海量服务的概念一起提出来的,指如果出现服务能力不够,不能为所有客户所有业务提供服务的异常情况,那系统有所取舍,尽可能保持业务运行,减少损失,比如在微信服务器在处理能力有限的情况下,可以优先保消息发送,而关闭朋友圈服务能力,比如直播业务在带宽有限的情况下,应该降低码率减少清晰度,而不应该拒绝服务。有损的意义就是有损失,有损伤的意思,它是一种思想,是退而求其次,是不得已而为之。
-
-
错误重试策略,避免流量风暴
如果设计一个ToC服务,在客户大规模断连的情况下,客户会重连,重连失败再连,如果重连尝试的频率不控制好,正常客户端重连有可能演变成对服务器的大规模攻击,打爆一台服务器,又去灭另一台,这太吓人了。可以参考kernel TCP的重连策略,有最大尝试次数,而且重试间隔是逐渐拉大的。
-
去关键路径、去中心化、避免单点故障
企业不要关键先生,关键先生会成为瓶颈,软件也不能把宝压到一个地方,去中心化去集中式,没什么难理解的。
-
负载均衡
load balance其实就是分担压力,LB要避免倾斜,有多种LB算法,比如RR,比如一致性hash,各有利弊,有兴趣可以研究下。LB不仅限于服务,进程内的多线程可能也会需要考虑这个问题。
-
看门狗和心跳机制
可以参考kernel的watch dog,其实就是看护机制,检测错误并努力掰过来。 -
安全编码
安全编码是一个职业程序员的基本要求,安全编码规则很多,很细节的一些规矩。这个可能跟语言相关,如果是C++相关的可以参考:C++的门门道道C相关的规则要少一些,我顺手列举一些。
- 比如要注意初始化。
- 比如全局变量不要有构造顺序的依赖。
- 比如慎用强转,强转等于接管了编译帮你做的类型检查。
- 比如理解线程安全函数,理解可重入的概念,理解信号机制。
- 比如要避免死锁,理解ABBA锁理解自死锁。
- 比如要谨防资源泄漏。
- 比如处理好内存分配失败的情况,理解野/悬垂指针。
- 比如要处理好边界,防止越界,溢出。
- 比如内存拷贝要避免内存重叠,理解memmove的用途。
- 比如理解递归的低效和栈的大小限制,避免爆栈。
- 比如建议使用STD安全版本函数(_s+n)版本。
- 比如了解unsigned < 0导致死循环的情况。
- 比如了解浮点数跟0比较的问题。
- 比如理解整型数据溢出和反转。
- 比如不要返回临时变量的引用或者指针,理解栈帧动态伸缩的原理。
- 比如理解做好把关检查的必要性,包括系统把关和模块把关。
小结
最后来读段经典:《系统化思维导论》一书中引用冯诺依曼的话写道:如果你观察一些自动装置,不论它们是人类设计的还是自然界本来就存在的,你通常会发现,它们的结构很大程度上受控于它们可能失效的方式,以及针对失效所采取的防御性措施(多少有些效果),说它们能预防失效有点夸张,它们不是能预防失效的,只是被设计成试图达到这种状态,这样至少大部分失效都不会是毁灭性的。所以,根本谈不上消除失效,或完全消除失效带来的影响。我们能尝试的只是设计一种自动装置,在大部分失效发生时仍能继续工作,这种装置减轻了失效的后果,而不是治愈失效,大部分人造的和自然界存在的自动装置,其内部原理都是如此。