距离上次博文已经有快半年了。原本打算在过年期间写一篇2019年的回顾和总结。但也被这突如其来的疫情打乱。放假期间一直关注相关新闻导致信息过载，一度非常沮丧。

发现有大量的CLOSE_WAIT端口占用，继续调用该服务的api，等待超时之后发现CLOSE_WAIT的数量也没有上升，也就是说服务几乎完全僵死。

配置其实分为结构和内容两个方面，结构对应的是代码，比如1.0.0新开发的代码上有一个功能开关${feature.switchA}，但master上还没有，这就是结构的变化。另一方面是内容，1.0.0的开发分支有两个测试环境，连着不同的数据库，那么对应的${mysql.url}的内容肯定不同。

spring-cloud-starter-eureka → spring-cloud-starter-netflix-eureka-client

在做系统的整体性能测试时发现经常会卡在一个较低的QPS（单机低于100）数值，而且应用服务器的负载不高，检查MQ消费速率只有40左右。接着把目标放在消息发送端上，发现消息发送速率很低，大约40条/s。

大家在初次使用spring-cloud的gateway的时候，肯定会被里面各种的Timeout搞得晕头转向。hytrix有设置，ribbon也有。我们一开始也是乱设一桶，Github上各种项目里也没几个设置正确的。对Timeout的研究源于一次log中的warning

ZuulException REJECTED_SEMAPHORE_EXECUTION 是一个最近在性能测试中经常遇到的异常。查询资料发现是因为zuul默认每个路由直接用信号量做隔离，并且默认值是100，也就是当一个路由请求的信号量高于100那么就拒绝服务了，返回500。

ActiveProfiles强制使用了IT的Profile，从最佳实践上来说IT Profile所配置的数据库或者其他资源组件的地址，应该是与开发或者Staging环境隔离的。因为当一个IT跑完之后很多情况下我们需要清除测试数据。

Websocket是HTML5之后的一个新事物，可以方便的实现客户端到服务端的长会话，特别适合用于客户端需要接收服务端推送的场景。例如在线客服聊天，提醒推送等等。改变了以往客户端只能通过轮询或者long poll来获取服务端状态的限制。

这两天抽空使用了一下两款压测工具 wrk Artillery 并且通过两款工具对产品的两个环境进行了测试 工具比较 wrk wrk自身性能就非常惊人，使用epoll这种多路复用技术，所以可以用少量的线程来跟被测服务创建大量连接，进行压测，同时不占用过多的CPU和内存。 命令非常简单 {代码...} 这样就可以进行最简单的压测。但是真实...

最近对devOps这个话题有点兴趣，所以研究了一下monitor相关的开源项目，翻到medium上的一篇文章,而且实际项目中也曾看到devOps组的同事搭过类似的监控，就想过把瘾，了解一下监控可视化。

微信火了这么久，这两周第一次从一个开发者的角度来研究微信的生态系统而不是应用本身。现在做国内的项目或者产品难免都需要集成微信，其实现在微信背后的支撑平台已经是非常繁杂的了：

AOP（Aspect Orient Programming），一般称为面向切面编程，作为面向对象的一种补充，用于处理系统中分布于各个模块的横切关注点，比如事务管理、日志、缓存等等。AOP实现的关键在于AOP框架自动创建的AOP代理，AOP代理主要分为静态代理和动态代理，静态代理的代表为AspectJ；而动态代理则以Spring AOP为代表。静态代理是...

年前意外的经历了一次阿里的电话面试，话说还没想换工作，但这位业余HR（应该是技术负责人）都没介绍工作岗位和要求，直接就约定某晚的电面时间，抱着好奇的态度被“虐”了一把。

目前我们处理消息的同步，一般是落地到DB后，再同过异步的方式做数据的聚合和处理。至于DB的操作为了简单直接用了Hibernate提供的一套JPA接口，（老实说真的是不喜欢JPA，一是sql log不好分析无法优化，二是必须非常了解JPA的所有关键字含义，不然就要出问题，所以我一直喜欢用mybatis这种更轻量的甚至spring-jdbc）。

任何消息都不能丢，因为这都是数据啊，即使处理不了也得找地方存着。最好每次的消息都存着，之后就变成了event sourcing（另一个大坑）。

最近一个使用Spring的项目中需要进行性能调优。方式基本上是编写新的代码实现原来一样的业务逻辑，只是实现方式有一些调整，例如增加cache，优化算法等等。