坏代码味道
Posted tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了坏代码味道相关的知识，希望对你有一定的参考价值。
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 消耗
代码坏味道 - 耦合
耦合
Feature Envy
症状：
方法访问其他类的对象的属性，而不是自己的。
成因：
最常见的问题就是由数据类引起的。
治疗：
多数时候，同时需要做出改变的code 应该在一起。
收益：
不合适的亲密
症状：
一个类有大量的访问另一个类的属性和方法，类之间的联系千丝万缕。
成因：
治疗：
变双向依赖为单向
单点接触
收益：
消息链
症状：
a.b().c().d()
有什么不好吗？ 客户对这关系知道的太多了，修改关系就意味着修改所有客户。
成因：
治疗：
隐藏委托，变单点接触。a 通过b 找到c ,调用c 的方法，改成 a调用b 的方法。
考虑是否可以把方法移动到客户端，客户自足。
收益：
减少依赖
中间人
症状：
一个类仅仅就是为了把行为委托给其他类，那它没有存在的必要。
成因：
过渡使用去除消息链的方法的结果；
治疗：
如果一个类的大多数方法都委托给其他类，那就移调中间人，采用消息链。
收益：
不完整的库类 --
这也是 坏味道？
症状：
库不能满足需要，但它又是只读的。
成因：
治疗：
在本地添加一个方法，在库的基础上实现更多功能；
继承库的类
收益：
不用再实现一遍库里已经提供的代码
以上是关于坏代码味道的主要内容，如果未能解决你的问题，请参考以下文章