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