主要参考拉勾教育潘新宇老师的《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 | 如何进行高保真压测和服务扩容？