文章 百度网站创建及发展历史,安国市住房和城乡建设局网站,清晰化网站,wordpress默认后台密码凌晨四点被公司的监控告警叫醒了#xff0c;告警的原因是生产环境跑批任务发生故障。即刻起床处理故障#xff0c;但还是花了不少时间才解决。这次故障是一次数据校验的跑批任务#xff0c;校验前面跑批任务的数据是否正确。幸运的是#xff0c;之前的核心任务已经完成告警的原因是生产环境跑批任务发生故障。即刻起床处理故障但还是花了不少时间才解决。这次故障是一次数据校验的跑批任务校验前面跑批任务的数据是否正确。幸运的是之前的核心任务已经完成并没有影响到生产上的交易系统工作。为什么我这里提到了交易工作呢因为交易系统是整个系统业务流量的入口如果交易系统发生故障那会给公司带来直接的收入损失。今天我们聊的话题是服务治理服务治理最终达到的结果就是系统 「7 * 24」 小时不间断服务。1 监控告警公司的这次生产告警很准确找到系统的直接维护人并且通知到是哪个跑批任务出了故障。这次告警是通过监控跑批任务中间件的任务执行结果来触发的。一般情况下告警有哪些类型呢我们看下图1.1 批处理效率❝多数情况下批处理任务是不阻碍业务入口的所以不需要监控。❞在阻碍业务入口的情况下批处理任务必须要监控。我举两个业务场景域名系统要通过dns信息和数据库记录来找出脏数据进行交易补偿这期间客户查询域名信息可能是脏数据银行日终跑批期间是不允许实时交易的这个「7 * 24」小时不间断服务相违背这些场景下批处理效率是非常重要的一个监控指标必须配置超时阈值并进行监控。1.2 流量监控常用的限流的指标如下图:流量监控我们需要注意几点不同的系统使用的监控指标是不同的比如redis可以用QPS指标对于交易系统可以用TPS通过测试和业务量的预估来配置合适的监控阈值监控阈值需要考虑突发情况比如秒杀、抢券等场景1.3 异常监控异常监控对于系统来说非常重要。在生产环境中很难保证程序不发生异常配置合理的异常报警对快速定位和解决问题至关重要。比如开篇提到的跑批告警告警信息中带着异常让我很快就定位到了问题。异常监控需要注意下面几个方面客户端read timeout,这时要尽快从服务端找出原因对客户端收到响应的时间设置一个阈值比如1秒超出后触发告警对业务异常一定要监控比如失败响应码1.4 资源使用率生产环境配置系统资源时一般要对系统资源的使用率有一个预测。比如redis在当前的内存增长速率下多久会耗尽内存数据库在当前的增长速率下多久会用光磁盘。系统资源需要设置一个阈值比如70%超过这个限制就要触发告警。因为资源使用快要饱和时处理效率也会严重下降。配置资源使用率的阈值时一定要考虑突增流量和突发业务的情况提前预留额外的资源来应对。对核心服务要做好限流措施防止突增流量把系统压垮。1.5 请求延迟请求延迟并不是一个很容易统计的指标下图是一个电商购物系统这个图中我们假设组合服务会并发地调用下面的订单、库存和账户服务。客户端发出请求后组合服务处理请求需要花费2秒的处理时间账户服务需要花费3秒的处理时间那客户端配置的read timeout最小是5秒。监控系统需要设置一个阈值来监控比如1秒内如果有100个请求延迟都大于了5秒就触发报警让系统维护人员去查找问题。❝客户端设置的read timeout不能太大如果因为服务端故障导致延迟要保证fail-fast防止因为资源不能释放造成系统性能大服务降低。❞1.6 监控注意事项监控是为了能让系统维护人员快速发现生产问题并定位到原因不过监控系统也有几个指标需要考虑根据监控目标来指定监控指标采样频率频率太高会增加监控成本。监控覆盖率最好能够覆盖到所有核心的系统指标。监控有效性监控指标不是越多越好太多会给分辨报警有效性带来额外工作量也会让开发人员习以为常。告警时效对于跑批任务这种非实时交易类系统可以不用实时告警记录事件后定一个时间比如早晨8点触发告警责任人到公司后处理。为避免长尾效应最好不要使用平均值。如下图10个请求有9个延迟都是1秒但有1个延迟是10秒所以平均值参考意义并不大。❝可以采用按照区间分组的方式比如延迟1秒以内的请求数量1-2秒的请求数量2-3秒的请求数量分组进行统计按照指数级增长的方式来配置监控阈值。❞2 故障管理2.1 常见故障原因故障发生的原因五花八门但常见的无非下面几种发布升级带来的故障硬件资源故障系统过载恶意攻击基础服务故障2.2 应对策略应对故障我们分两步走立即解决故障比如因为数据问题引起的故障修改问题数据即可。找出故障原因可以通过查找日志或者调用链追踪系统来定位问题并解决2.2.1 软件升级故障升级带来的故障有的是上线后能很快暴露的。有的是上线很长时间才会暴露比如有的业务代码可能之前一直执行不到。对于第一种情况可以采用灰度发布的方式进行验证解决。对于第二种情况完全避免是很难的我们只能最大限度的提高测试用例覆盖率。2.2.2 硬件资源故障这类故障主要分为两类硬件资源超载比如内存不够硬件资源老化对于第一种故障一般用监控告警的方式来通知责任人处理处理的方式主要是增加资源找出消耗资源严重的程序进行优化。对于第二种故障需要运维人员对硬件资源进行记录和监控对于老化的资源及时进行更换。2.3 系统过载系统过载可能是遇到秒杀之类的突增流量也可能是随着业务发展慢慢地超过系统承受能力可以使用增加资源或者限流的方式来应对。2.4 恶意攻击恶意攻击的类型非常多比如DDOS攻击、恶意软件、浏览器攻击等。针对恶意攻击防止手段也很多比如对请求报文进行加密、引入专业的网络安全防火墙、定期安全扫描、核心服务部署在非默认端口等。2.5 基础软件故障如下图所示除了业务服务外每个组件都是基础软件都需要考虑高可用。3 发布管理发布通常指软硬件的升级包括业务系统版本升级、基础软件升级、硬件环境升级等。作为程序员本文讲的升级是针对业务系统的升级。3.1 发布流程一般情况下业务系统升级流程如下发布到生产环境验证没有问题表示发布成功。3.2 发布质量在升级软件的时候发布质量非常重要为保证发布质量需要注意下面这些问题。3.2.1 CheckList为了保证发布质量发布前维护一份CheckList并且开发团队对所有的问题进行确认。等这份清单都确认完成后进行构建发布。下面是一些比较典型的问题上线sql是否正确生产配置文件配置项是否完备外部依赖的服务是否已经发布并验证完成新机器路由权限是否已经开通多个服务的发布顺序是否已经明确如果上线后发生故障怎么应对3.2.2 灰度发布灰度发布是指在黑与白之间能够平滑过渡的一种发布方式。如下图升级时采用金丝雀部署的方式先把其中一个server作为金丝雀进行发布升级这个server在生产环境运行后没有问题再升级其他的server。有问题则进行回滚。3.2.2 蓝绿部署蓝绿部署的方式如下图升级之前客户端的请求发送到绿色服务上升级发布之后通过负载均衡把请求转到蓝色系统绿色系统暂时不下线如果生产测试没有问题则下线绿色系统否则切回绿色系统。❝蓝绿部署跟金丝雀部署的区别是金丝雀部署不用增加新的机器而蓝绿部署相当于是增加了一套新机器需要额外的资源成本。❞3.2.4 ab测试ab测试是指在生产环境发布多个版本主要目的是测试不同版本的不同效果。比如页面样式不一样操作流程不一样这样可以让用户选择一个最喜欢的版本作为最终版本。如下图三个颜色的服务部署了客户端的请求分部发送到跟自己颜色一样的服务上。❝ab测试的版本都是已经是验证没有问题的这点不同于灰度发布。❞3.2.4 配置变更好多时候我们把配置写在代码里比如yaml文件。这样我们修改配置后就需要重新发布新版本。如果配置修改频繁可以考虑下面两种方法引入配置中心使用外部系统保存配置4 容量管理在2.3节中讲到系统过载导致的系统故障。容量管理是保证系统上线后稳定运行的一个重要环节主要是保证系统流量不超过系统能承受的阈值防止系统奔溃。一般情况下系统容量超载的原因如下业务持续增加给系统带来的流量不断增加系统资源收缩比如一台机器上新部署了一个应用占用了一些资源系统处理请求变慢比如因为数据量变大数据库响应变慢导致单个请求处理时间变长资源不能释放重试导致的请求增加突增流量比如微博系统遇到明星离婚案之类的新闻。4.1 重试对于一些失败的请求进行重试能够很好地增加系统的用户体验。重试一般分为两类一类是对连接超时的请求一类是对响应超时的请求。对于连接超时的请求可能是网络瞬时故障造成的这种情况下重试并不会对服务端造成压力因为失败的请求压根就没有到达服务端。但是对于响应超时的请求如果进行重试可能会给服务端带来额外的压力。如下图正常情况下客户端先调用服务A服务A再调用服务B服务B只被调用了一次。如果服务B响应慢导致超时客户端配置了失败重试2次服务A也配置了失败重试2次在服务B最终不能响应的情况下服务B最终被调了9次。在大型分布式系统中如果调用链很长每个服务都配置了重试那重试会给调用链下游服务造成巨大的压力甚至让系统奔溃。可见重试不是越多越好合理的设置重试对系统有保护作用。对于重试有如下3个建议非核心业务不重试如果重试必须限定次数重试时间间隔要指数增加根据返回失败的状态进行重试比如服务端定义一个拒绝码客户端就不重试了4.2 突增流量对于突增流量是很难提前规划到的。遇到突增的流量时我们可以先考虑增加资源。以K8S为例如果原来有2个pod使用deploy编排扩容到4个pod。命令如下kubectl scale deployment springboot-deployment --replicas4
如果资源已经用完了那就得考虑限流了。推荐几个限流框架google guavanetflix/concurrency-limitssentinel4.3 容量规划系统建设初期做好容量规划是非常重要的。可以根据业务量来估算系统的QPS基于QPS进行压力测试。针对压力测试的结果估算的容量并不一定能应对生产环境的真实场景和突发情况可以根据预估容量给出预留资源比如2倍容量。4.4 服务降级服务降级对于服务端来说可以有三种方式服务端容量超载后直接拒绝新的请求非核心服务暂停预留资源给核心服务用客户端可以根据服务端拒绝的请求比例来进行降级处理比如观察1分钟如果服务端对1000个请求拒绝了100个客户端可以作为参考以后每分钟超过90个就直接拒绝。5 总结微服务化的架构给系统带来了很多好处但同时也带来了一些技术上的挑战。这些挑战包括服务注册与发现、负载均衡、监控管理、发布升级、访问控制等。而服务治理就是对这些问题进行管理和预防保证系统持续平稳地运行。本文所讲的服务治理方案也算是传统意义上的方案有时会有一些代码的侵入而框架的选择也会对编程语言有限制。在云原生时代Service Mesh的出现又把服务治理的话题带入一个新的阶段。后续再做分享。「原创不易点个“再看”就是对我最大的支持转发一下那就是真爱了。」「欢迎加我微信:zhujinjun86拉你加入技术群。」
