坏代码味道（一）

GC 优化

1.防止大对象Buffer到内存中

现象：当大包请求时，YGC 耗时严重
原因：默认情况下 Zuul2 并不会缓存请求体（DirectByteBuffer），也就意味着它会先发送接收到的请求 Headers 到后端服务，之后接收到请求体再继续发送到后端服务，发送请求体的时候，也不是组装为一个完整数据之后才发，而是接收到一部分，就转发一部分。
如果需要缓存请求体：
需要 Override needsBodyBuffered 方法， com.netflix.zuul.netty.filter.BaseZuulFilterRunner#filter
针对大包请求时，网关性能降低，体现在：网关操作会将请求体 Buffer 到用户空间来实现提取请求体做 WAF 拦截
优化：

• 判断大包，大包不缓存（Content-Length）
  

2.防止多次创建重复对象

现象：YGC 次数多
原因：
如何快速获取 Body？Zuul 贴心的为我们提供了如下两种方式，封装在过 Request 中供开发者使用
com.netflix.zuul.message.ZuulMessageImpl#getBodyAsText
com.netflix.zuul.message.ZuulMessageImpl#getBody
但不幸的是，内部每次获取对象繁琐，并且 new String() 创建返回
优化：
取一次，缓存在 Context 中，需要时从 Context 获取
3.防止多次创建中间对象

现象：YGC 次数多
原因 ：多次创建中间无用对象，例如：ProtobufSerializer#serialize

1.     @Override
2.     public byte[] serialize(String topic, Object data) {
3.         if (data == null) {
4.             return null;
5.         }
6.         return JSON.toJSONString(data).getBytes();
7.     }

复制代码

优化：直接序列化成 byte，不需要先创建中间对象 String，再 getBytes()
CPU 优化

1.减少线程个数，降低上下文切换次数

现象：无关线程太多，影响内存(JVM+操作系统)+CPU 争抢
原因：网关内有生产者，消费者，每个消费者都会有消费轨迹的线程池(10)，网关有针对不同场景下的消费者，故会创建诸多消息轨迹线程
优化：

• 禁用消息轨迹
  
• 调整消费者线程数
  

2.减少字符串比较次数

现象：每次请求到自定义的 Route Filter，都要通过 Loop 缓存获取到和当前 RequestMethod 一致的 Rest API。通过火焰图可以看出，单位时间内，该部分逻辑 CPU 计算占比高
[img=30%,30%]https://img2023.cnblogs.com/blog/299214/202305/299214-20230524024602222-1639017475.png[/img]
原因 ：

1. Set<String> apis=restApiManager.getApis().stream().filter(a -> method.equalsIgnoreCase(a.getHttpMethod())).collect(Collectors.toSet());

复制代码

本意是过滤掉和当前 Request Method 不一致的，但是每请求一次，都需要重复计算过滤：O(n)
优化：O(1)，改为 HashMap，Key 为 Method，Value 为 Set  apis，封装统一方法获取，RestApiManager#getApis(String method)
3.减少正则表达式计算次数

现象：API 路由需要正则匹配，最终确定需要路由的 Service。通过火焰图可以看出，单位时间内，该部分逻辑 CPU 计算占比高
[img=30%,30%]https://img2023.cnblogs.com/blog/299214/202305/299214-20230524024536613-1068201263.png[/img]原因：API 路由需要正则匹配，最终确定需要路由的 Service
优化：通过前缀匹配，过滤掉非法的API。比如访问：/v1/accounts/{accountId}/getAllInfo，先过滤掉非 /v1/accounts 开头的 API，因为正则肯定不匹配
4.减少序列化

现象：序列化需要CPU运算，减少不必要的序列化场景可以提高吞吐量
原因：针对相同请求的话，WAF 里需要计算出一个签名，减少攻击验证次数。
因为计算相同内容的 MD5，将对象序列化成 JSON。在高并发下序列化会大量占用 CPU。

1. signature = buildSignature(objectMapper.writeValueAsString(requestMessage));

复制代码

优化：
使用 ToString 来替换序列化：

1. signature = buildSignature(requestMessage.toString())

复制代码

其他优化

• 不打无用日志，日志需要编码，需要 CPU 消耗
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！