RPC 接口的设计原则

主要参考拉勾教育潘新宇老师的《23讲搞定后台架构实战》,文末是所参考的具体文章链接。

1、RPC 接口

防备上游、做好自己、怀疑下游。

定义新的接口时需要考虑未来兼容性,如果接口上线后再想要修改,则需要花费较高的成本。

1.1 第一个原则:增加接口调用鉴权

增加鉴权后,调用方申请权限时可以沟通好预期,明确接口功能和调用方的意图,避免流量过高打挂服务,或者传参出错等。

1.2 第二个原则:接口里的入参需要是对象类型,而不是原子类型

接口里的入参需要是对象类型,而不是原子类型,很好的向后兼容,接口增加可选参数,不影响不需要该参数的调用方。

1.3 第三个原则:入参需要增加条件限制和参数校验

传参错误无法正常处理业务逻辑

避免极端传参消耗过多资源,影响服务稳定性,比如limit offset的参数,数值过大可能导致深分页。

1.4 第四个原则:写接口需要保证幂等性

如果外部客户调用你的接口超时,调用方并不知道此次写入是否成功,通过反查调用方可以确定此次调用是否成功;通过重试,调用方期望你告诉它,上次写入已经成功,无须重试。

反查,重试,唯一索引。

1.5 第五个原则:返回的数据量必须要分页

  • 批量查询的接口如果数据量极大可能会把数据库或缓存打挂;
  • 数据量越多,网络传输的时间也越长,直接的体现就是接口的性能非常差。

批量查询的接口最好都增加分页,而不是一次吐出所有数据。这样既可以提升稳定性、又可以提升性能。

1.6 第六个原则:所有的接口需要根据接口能力前置设置兜底限流

2、MQ 消息设计原则

对于消息消费需要保证幂等,不然当消息出现重试后,会出现业务上的脏数据。

消息的数据在消费处理时需要进行前置参数检验。如果未做前置参数校验,同样也有可能写入一些不合法的脏数据。

消息的数据要尽可能全,进而减少消息消费方的反查。

消息中需要包含标记某个字段是否变更的标识。

3、微服务需要哪些监控看板

3.1 次数监控

接口并调用次数,函数执行次数,接口失败次数

3.2 性能监控

接口平均耗时、最大耗时、tp999 耗时(99.9%的请求最大耗时)

3.3 成功率、错误率监控

接口调用成功率,接口调用失败率

3.4 调用方监控

3.5 资源利用率监控

RPC 连接池、线程池、垃圾回收耗时、cpu/内存利用率、机器负载

有了监控,还需要加阈值报警,以及自动服务降级和限流

4、压测

4.1 压测目的

解了微服务的最大支撑能力,参考此值来设置微服务的限流阈值。寻找服务性能的最短板(服务自身、下游依赖、数据库存储层),针对性解决问题,提高系统整体性能。

4.2 压测方式

读接口直接使用用线上录制的流量,线上录制的流量请求体真实,不失真。

写接口需要对录制的流量打上压测标记,并将数据写入到影子库,避免测试数据出现到线上。

4.3 压测需要观测的数据

压测过程中的各项指标数据和压测的结果即服务所能够支撑的QPS。

4.4 根据压测结果设置限流阈值

一般阈值设置在极限值的 40% ~ 50%,如果阈值是压测一个接口得到的,但是实际服务对外提供了两个接口,那么这个接口的阈值可能还需要再折半,因为压测时一个接口独占了所有资源,新增接口后,资源必定被强占一部分,这样的话,那接口 QPS 阈值就应该设置极限值的 20 ~ 25%。

4.5 压测系统模块组成

流量过滤器:可以采用采用 RPC 框架提供的拦截器实现,也可以采用 service mesh 的 proxy 来实现,并将出入参转发到 MQ 。

请求日志保存模块:根据预设的压测配置,进行压测日志的收集。包括接口信息,请求体和响应体等信息。

请求日志下发模块:将压测的请求日志下发到发压机器里。发压进程直接读取本地磁盘的请求日志,可以短时间发起洪峰流量。

发压模块:读取本地请求日志,转换成请求体后调用被压测服务,实施真实发压,除此之外,还需要记录请求结果。

压测管理端:用来设置各项压测配置以及查看压测结果值。

5、问题

问:为什么集群的QPS 不是随着机器数量增加而线性增加的

因为所有机器所处的网络是共享的、进程间的切换存在性能消耗,以及存储是共享的等因素。实例增加后,公共资源抢占愈发明显,所以集群的 QPS 不是随着机器数量增加而线性增加的

6、完整参考

17 | 如何设计一锤子买卖的 SDK ?

19 |如何做好微服务间依赖的治理和分布式事务?

20 | 如何通过监控快速发现问题?

21 | 如何进行高保真压测和服务扩容?

你可能感兴趣的:(rpc,java,分布式,微服务,数据库)