主要参考拉勾教育潘新宇老师的《23讲搞定后台架构实战》,文末是所参考的具体文章链接。
防备上游、做好自己、怀疑下游。
定义新的接口时需要考虑未来兼容性,如果接口上线后再想要修改,则需要花费较高的成本。
增加鉴权后,调用方申请权限时可以沟通好预期,明确接口功能和调用方的意图,避免流量过高打挂服务,或者传参出错等。
接口里的入参需要是对象类型,而不是原子类型,很好的向后兼容,接口增加可选参数,不影响不需要该参数的调用方。
传参错误无法正常处理业务逻辑
避免极端传参消耗过多资源,影响服务稳定性,比如limit offset的参数,数值过大可能导致深分页。
如果外部客户调用你的接口超时,调用方并不知道此次写入是否成功,通过反查调用方可以确定此次调用是否成功;通过重试,调用方期望你告诉它,上次写入已经成功,无须重试。
反查,重试,唯一索引。
批量查询的接口最好都增加分页,而不是一次吐出所有数据。这样既可以提升稳定性、又可以提升性能。
对于消息消费需要保证幂等,不然当消息出现重试后,会出现业务上的脏数据。
消息的数据在消费处理时需要进行前置参数检验。如果未做前置参数校验,同样也有可能写入一些不合法的脏数据。
消息的数据要尽可能全,进而减少消息消费方的反查。
消息中需要包含标记某个字段是否变更的标识。
接口并调用次数,函数执行次数,接口失败次数
接口平均耗时、最大耗时、tp999 耗时(99.9%的请求最大耗时)
接口调用成功率,接口调用失败率
RPC 连接池、线程池、垃圾回收耗时、cpu/内存利用率、机器负载
有了监控,还需要加阈值报警,以及自动服务降级和限流
解了微服务的最大支撑能力,参考此值来设置微服务的限流阈值。寻找服务性能的最短板(服务自身、下游依赖、数据库存储层),针对性解决问题,提高系统整体性能。
读接口直接使用用线上录制的流量,线上录制的流量请求体真实,不失真。
写接口需要对录制的流量打上压测标记,并将数据写入到影子库,避免测试数据出现到线上。
压测过程中的各项指标数据和压测的结果即服务所能够支撑的QPS。
一般阈值设置在极限值的 40% ~ 50%,如果阈值是压测一个接口得到的,但是实际服务对外提供了两个接口,那么这个接口的阈值可能还需要再折半,因为压测时一个接口独占了所有资源,新增接口后,资源必定被强占一部分,这样的话,那接口 QPS 阈值就应该设置极限值的 20 ~ 25%。
流量过滤器:可以采用采用 RPC 框架提供的拦截器实现,也可以采用 service mesh 的 proxy 来实现,并将出入参转发到 MQ 。
请求日志保存模块:根据预设的压测配置,进行压测日志的收集。包括接口信息,请求体和响应体等信息。
请求日志下发模块:将压测的请求日志下发到发压机器里。发压进程直接读取本地磁盘的请求日志,可以短时间发起洪峰流量。
发压模块:读取本地请求日志,转换成请求体后调用被压测服务,实施真实发压,除此之外,还需要记录请求结果。
压测管理端:用来设置各项压测配置以及查看压测结果值。
因为所有机器所处的网络是共享的、进程间的切换存在性能消耗,以及存储是共享的等因素。实例增加后,公共资源抢占愈发明显,所以集群的 QPS 不是随着机器数量增加而线性增加的
17 | 如何设计一锤子买卖的 SDK ?
19 |如何做好微服务间依赖的治理和分布式事务?
20 | 如何通过监控快速发现问题?
21 | 如何进行高保真压测和服务扩容?