Dean's Story

我们的产品是一个客户数据平台。产品的一个重要部分类似企业版的”捷径”，让运营人员可以像搭乐高积木一样创建企业的自动化流程，无需编程即可让数据流动起来。从这一点上，我们的业务特点就是聚少成多，把一个个服务连接起来就成了数据的海洋。理念上跟微服务一致，一个个独立的小服务最终实现大功能。当然我们一开始也没有使用微服务，当业务还未成型就开始考虑架构，那么就是”过度设计”。另一方面需要考虑的因素就是”人”，有没有经历过微服务项目的人，团队是否有devops文化等等，综合考量是否需要微服务化。

好久没更新了，正好上周遇到一个获取不到客户端IP的BUG，开发环境用nginx做反代都是work的。上到生产环境就获取不到。思来想去就是生产上多了一个SLB负载均衡。但这是一个老的功能，之前也都是好的，突然就拿的不对了，非常之诡异。

微服务是否适合小团队是个见仁见智的问题。回归现象看本质，随着业务复杂度的提高，单体应用越来越庞大，就好像一个类的代码行越来越多，分而治之，切成多个类应该是更好的解决方法，所以一个庞大的单体应用分出多个小应用也更符合这种分治的思想。当然微服务架构不应该是一个小团队一开始就该考虑的问题，而是慢慢演化的结果，谨慎过度设计尤为重要。

公司的背景是提供SaaS服务，对于大客户也会有定制开发以及私有化部署。经过2年不到的时间，技术架构经历了从单体到微服务再到容器化的过程。

节前没有新业务代码，正好Greenwich刚发布，于是开始为期四天的框架代码升级。

之前的版本是 spring boot 1.5.10 , spring cloud Edgware.SR3

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

果断搭建一个最小化工程单测Rabbitmq发送性能，发现在启用发送端事务后性能下降非常明显。

本机SSD硬盘测试结果10w条消息未开启事务，大约10s发送完毕；而开启了事务后，需要将近320s，差了30多倍。

接着翻阅Rabbitmq官网，发现开启事务性能最大损失超过250倍。

Using standard AMQP 0-9-1, the only way to guarantee that a message isn’t lost is by using transactions – make the channel transactional then for each message or set of messages publish, commit. In this case, transactions are unnecessarily heavyweight and decrease throughput by a factor of 250. To remedy this, a confirmation mechanism was introduced. It mimics the consumer acknowledgements mechanism already present in the protocol.

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

如果希望很方便针对API进行测试，并且方便的集成到CI中验证每次的提交，那么spring boot自带的IT绝对是不二选择。

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

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

The Hystrix timeout of 60000 ms for the command “foo” is set lower than the combination of the Ribbon read and connect timeout, 200000ms.

这两天抽空使用了一下两款压测工具

• wrk
• Artillery

并且通过两款工具对产品的两个环境进行了测试