聊城做手机网站,wordpress 插件 函数,凡科网站制作平台,馆陶网站一个产品随着不断研发#xff0c;其服务架构的复杂度会越来越高。随着产品的用户体量变大#xff0c;为了保证产品能够长线运营#xff0c;就需要保证整个服务架构的稳定性。因此#xff0c;今天这篇文章#xff0c;就从实操的角度#xff0c;粗浅讨论一下#xff0c;服…一个产品随着不断研发其服务架构的复杂度会越来越高。随着产品的用户体量变大为了保证产品能够长线运营就需要保证整个服务架构的稳定性。因此今天这篇文章就从实操的角度粗浅讨论一下服务架构的稳定性需要如何做到基础保障。
既然是基于实操的角度那么理论上的东西不会涉及的太深刻。好比说谈到稳定性我们就会考虑SLI、SLO、SLA这些基础概念但这些比较宏观。拿OKR举例子的话O是SLAKR是SLO而SLI则是KR具体的指标定义。所以这篇文章主要讲如何保证SLI以及其他指标间接满足SLO、SLA的需要。
对于外部客户来讲核心服务的SLI指标是需要优先保证的而周边服务的SLI指标则可以做为核心服务的下钻指标来看待。SLI指标一般是上游视角的服务可用性如果一个请求返回一些4字头、5字头的错误码那么就可以认为上游视角服务不可用。由于5字头主要是服务器错误因此5字头的问题需要case-by-case排查服务端实现问题进行处理而4字头则不一定。比如一个只能POST的路由强行GET就有可能构造出一个404一个设计上预计延时较长的接口客户端如果提前断开nginx也可能给一个499的错误。究其性质4字头的错误可以适当做过滤但也不排服务端自己可以把接口实现给优化掉主动解决问题。
为了保证SLI的高指标刚刚提到除了周边服务的SLI指标外其他当前服务的黄金指标也必不可少。上下游的请求错误可以反映当前服务具体出现哪些错误或者不合理的请求以及服务处理业务过程中哪些环节出了异常容器的CPU/MEM等资源占用可以反映服务在哪些具体的时刻出现性能问题错误和崩溃日志则直接反映具体出现的业务逻辑或者性能问题是什么。
对于SLI的毛刺可以将同一时间段三类下钻指标结合起来看找到一些毛刺上的共性对于请求错误可以找到一些trace的例子做分析对于性能占用问题可以通过抓取火焰图来看当前某个时间段哪些函数占用的时间比较多然后再做定点优化对于错误崩溃日志问题可以做日志聚合分析看哪些类型的日志出现的比较多哪些日志在某个时刻有上涨波动找到一些关键字共性特征。这样就可以系统性查证可能导致可用性降低的原因从而逐个排除击破。
除了核心服务和周边服务之外中间件的问题也是需要关注的比如DB的表可用性、消息队列的吞吐量延时以及缓存的访问错误率等等。对于DB而言可以重点关注慢查询、连接数上限和主从延时等性能指标如果有慢查或者连接数打满那要考虑代码hit索引以及连接池未及时释放问题是需要服务器关心的如果有主从延时则需要看是不是同时刻有DDL之类的操作锁表导致大量数据不能及时同步或者纯粹是DB运维原因。对于缓存而言如果缓存访问错误可以优先看下是否因为高延时引起如果是的话看下是否有大key占用了缓存较多的内存或者频繁对于大key做操作导致缓存处理不过来。之后DB和缓存都需要注意集群分片的场景下单个实例的性能问题需要考虑是否存在某些热点数据。
对于消息队列除了运维原因外尤其是作为消费者的服务需要监控上消费逻辑的处理延时。尤其如果消费逻辑涉及到和第三方平台的交互需要考虑第三方平台是否稳定如若不稳定则需要走另外的消息处理异步逻辑兜底做一个相对优雅的fix。如果代码层面没法优化的话通过扩容服务则是最粗暴直接的解决方式。
最后除了服务本身的指标之外从业务角度而言也需要梳理业务的核心重要链路补充打点metrics上报从而在监控服务性质指标的同时也可以及时发现一些业务性质的问题。业务错误最终会导致服务可用性下降这样通过结合同时间段的指标聚合分析服务SLI的下降问题就可能会更加容易被定位到。
