21 | 流量回放：保障业务技术升级的神器
什么是流量回放？
流量就是指在某个时间段内的所有请求，我们通过某种手段把发送到A应用的所有请求录制下来，然后把这些请求统一转发到B应用，让B应用接收到的请求参数和A应用保持一致，从而实现A接收到的请求在B应用里面重新请求了一遍，这个过程，我们称为“流量回放”。
当我们对应用逻辑有改动，但在做了单元测试和回归测试之后，因为线上环境更加复杂，为了降低出错的概率，可以尝试使用流量回放。
传统QA测试不能满足要求的根本原因就是在于改造后的应用在上线后出现跟应用上线前不一致的行为。我们测试的目的就是为了保证改造后的应用跟改造前应用的行为一致，我们测试Case也应该尽力去模拟应用在线上的行为，这时最好的方式就是用线上流量来验证，但是又不能把新的应用直接上线，所以我们可以考虑流量回放。也就是说我们可以把线上一段时间内的请求参数和响应结果保存下来，然后把这些请求参数在新改造的应用里面重新请求一遍，对比一下改造前后的响应结果是否一致，这样就间接达到了使用线上流量进行测试的效果。
我们常用的流量回放方案包括TcpCopy、Nginx等。
在RPC框架中，因为所有的请求都经过RPC，我们可以在RPC中拿到这些请求参数，将这些参数旁录下来，并将旁录结果用异步的方式发送到一个固定的地方保存起来，这样就完成了流量录制功能。
在完成录制功能后，我们需要模拟一个应用调用方，将录制好的请求参数重新发送一遍到要回归测试的应用里面，然后对比录制拿到的请求结果和新请求的结果，这样就完成了请求回放的过程。
流量回放不是RPC框架的核心功能，但是有了这个功能以后，用户可以更放心的升级自己的应用了。
使用流量回放，对请求有一些限制：
- 请求是否依赖底层数据，如果依赖，那么需要保证底层数据是一致的。
- 请求是否与当前系统状态或者系统时间有关系，如果相关，那么相关依赖也需要保持一致。
- 请求所执行的方法是否幂等，如果不幂等，很可能会影响验证结果。
实现流量回放的设计思路：
- 使用动态代理，切面拦截对应的方法，获取出入参。
- 把拦截信息异步转存到线上验证系统。
- 通过线上验证系统调用待验证的防范。
- 收集结果对比信息，设置报警功能。
22 | 动态分组：超高效实现秒级扩缩容
我们之前学习过服务分组，在调用方复杂的情况下，如果让所有调用方都调用同一个集群，那么很可能会因为非核心业务调用量的突增，造成整个集群都不可用了，为了避免这种情况，我们需要把整个打击群根据不同的调用方划分出不同的小集群，从而实现调用方流量隔离的效果，保证不同业务之间不会相互影响。
在给集群分组的时候，我们一般会选择性的合并一些调用方到同一个分组里，至于如何合并，并没有统一标准，一般来说，我们可以按照应用的重要级别来划分，让非核心业务应用和核心业务应用不要共用一个分组，并且非核心应用之间也最好别用一个分组。
那么我们如何为每个分组配置合适的机器数量呢？一般会通过压测来评估服务提供方单台机器所能承受的QPS，然后再计算出每个分组里面的所有调用方的调用总量，考虑到可能的不确定性因素，我们可以在现有调用总量的基础上，添加一个百分比作为buffer，这个百分比一般来自经验总结。
我们计算每个分组所需要的机器数量时，会额外增加一些机器，这样让每个小集群可以有一定的抗压能力，而抗压能力取决于预留机器的数量，这就需要在成本和可用性之间做权衡。
当某个分组的调用方流量突增，而分组所预留的空间不能满足当前流量要求时，我们可以看一下其他分组的服务提供方是否有富余能力来帮忙处理请求，这也就是动态分组的含义。
因为服务提供方的分组信息以及机器节点都保存在注册中心里面，我们可以在注册中心里面将部分实例的别名改成我们想要的别名，然后通过服务发现进而影响到不同调用方能够调用的服务提供方实例集合，换句话说，我们可以通过控制注册中心，来管理服务调用方可以触达的服务提供方以及分组节点的信息。
通过直接修改注册中心数据，我们可以让任何一个分组瞬间拥有不同规模的集群能力。我们不仅可以实现把某个实例的分组名改成另一个分组名，还可以让某个实例分组名变成多个分组名，这就是我们在动态分组里面最常见的两种动作：追加和替换。
我们还可以利用动态分组解决分组后的每个分组预留机器冗余的问题，我们没有必要把所有冗余的机器都分配到分组里面，我们可以把这些机器做成一个共享的池子，从而减少整理预留的实例数量。
标签：调用,请求,回放,笔记,Day15,RPC,分组,流量,应用 From： https://www.cnblogs.com/wing011203/p/17084432.html