gpt4 book ai didi

代码坏味道(一)

转载 作者:我是一只小鸟 更新时间:2023-05-24 22:31:39 32 4
gpt4 key购买 nike

回到顶部

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 。

                        
                              @Override
    public byte[] serialize(String topic, Object data) {
        if (data == null) {
            return null;
        }
        return JSON.toJSONString(data).getBytes();
    }

                        
                      

优化 :直接序列化成 byte,不需要先创建中间对象 String,再 getBytes() 。

回到顶部

CPU 优化

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

现象 :无关线程太多,影响内存(JVM+操作系统)+CPU 争抢 。

原因 :网关内有生产者,消费者,每个消费者都会有消费轨迹的线程池(10),网关有针对不同场景下的消费者,故会创建诸多消息轨迹线程 。

优化 :

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

2.减少字符串比较次数

现象 :每次请求到自定义的 Route Filter,都要通过 Loop 缓存获取到和当前 RequestMethod 一致的 Rest API。通过火焰图可以看出,单位时间内,该部分逻辑 CPU 计算占比高 。

原因 :

                        
                           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 <String> apis,封装统一方法获取,RestApiManager#getApis(String method) 。

3.减少正则表达式计算次数

现象 :API 路由需要正则匹配,最终确定需要路由的 Service。通过火焰图可以看出,单位时间内,该部分逻辑 CPU 计算占比高 。

原因 :API 路由需要正则匹配,最终确定需要路由的 Service 。

优化 :通过前缀匹配,过滤掉非法的API。比如访问:/v1/accounts/{accountId}/getAllInfo,先过滤掉非 /v1/accounts 开头的 API,因为正则肯定不匹配 。

4.减少序列化

现象 :序列化需要CPU运算,减少不必要的序列化场景可以提高吞吐量 。

原因 :针对相同请求的话,WAF 里需要计算出一个签名,减少攻击验证次数.

因为计算相同内容的 MD5,将对象序列化成 JSON。在高并发下序列化会大量占用 CPU.

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

                        
                      

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

                        
                          signature = buildSignature(requestMessage.toString())

                        
                      
回到顶部

其他优化

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

最后此篇关于代码坏味道(一)的文章就讲到这里了,如果你想了解更多关于代码坏味道(一)的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。

32 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com