月度归档：2018年03月

阳春三月在成都

发表于由
回复

这是一篇月末总结，如果你是不小心被标题吸引误入，那么我更加建议你把这篇月志读完。既来之，则安之?

三月工作上发生了挺大变化，很多老朋友离开了，很多新同学加入了。无论是离开还是加入的人，里面都有自己喜欢和欣赏的人。成都的圈子只有这么大，鄙人都祝福他们。

自己又回到3年前的类似位置，做着类似的事情，此乃物是。三年前犯过的错误、苦恼纠结的事情，无一缺席，但是已经没有了当初面对类似事情的不确定性，此乃人非。

这个月重新找到了写字的愉悦感。在某些平台居然还被特别推荐过，我跟妞儿说这是一件funny的事情，没有开心的成分。算是把延期了好几年的课程补上了一小步。

在这个过程中，鄙人也开始逐渐体会到了自己订阅的公众号作者写作的内心感受。写作的目的可能有很多种，但是对于某一类人来说，写作就是一种习惯性的分配特定时间进行思考。这种思考可能在写作开始之前已经在潜意识中发生。写作就是讲这些思考的尘埃落定和梳理的过程。另外，根据我的观察，一般擅长写作的人，大多都是逻辑清晰且沟通起来很愉快的人。

三月挺幸运，包括今天。接触到了很多交流起来很愉快的人。鄙人跟妞儿说，遇到聪明的人的时候，有一种发自内心的欣赏和热爱。这种热爱跟基情没有关系，对于没有那么熟络的人，珍惜交流的效率和时间；对于熟悉的人，会聊很多平时不会聊的话题和看法。要知道，其实这个世界上，能够一起沟通和讨论一些深度想法的人太少太少了，遇到一个，怎能不喜？有那么一群人，注定就是寂寞。

马上而立之年了，责任随不至于越来越重，但是却只越来越真实。这个月似乎也硬着头皮处理了很多家庭上的事情。也许有时候过于追求效率，以及当面揭穿一些人的套路伎俩吧，给人的感觉是脾气太冲，经常惹恼很多人，包括家人。在这个点上，我从来不抱怨什么路长且累呀，什么不理解呀。我挺同意韩路的观点：如果你对目标足够清晰和强壮，那么做一些事的时候必然会有取舍和付出。想通了这件事，很多事情就是理所当然的，哪里还有什么抱怨。我花了挺长时间想清楚这个问题，也会有心情郁闷的时候，也会有到家以后，熄火在车里闷两分钟的时候，但是只要踏入家门，我必然是女儿的好爸爸，妞儿的好丈夫，父母的好儿子，而这一切，内心是举重若轻，毫无纠结的。

三月：

  • 最喜欢的物品：飞行棋手机架
  • 最喜欢的书：《原则》
  • 最惺惺相惜的人：至今不知道他的名字，但是却有过一次非常深入、愉快的交流
  • 财务目标一个都没有达到，且存在浮亏的款项
  • 独立项目新开了一个项目，看能走多远吧

三月开始，南方逐渐进入一年中最好的日子。在期待四月中，2018已经过去25%.

一次非典型性 Redis 阻塞总结

发表于由
回复

南方逐渐进入一年中最好的时节，用户也开始骚动起来。看了眼数据，活跃用户已经double很远，马上triple了。

一日睡眼惺忪的清晨，正看着数据默默yy时候，线上开始告警…… MMP，用户早上骚动的增长比想象好快呢。同事第一时间打开立体监控瞥了一眼，结合服务的错误日志，很快把问题锁定到了一个Redis实例（事实上，自从立体监控上线以后，基本上处理流程从以前的 < 80%时间定位问题 + 20%解决问题 > 变成了 < 少量时间确认问题 + 解决问题 >）。团队处理效率还是挺快的，原因定位到AOF持久化：

这是当时的Redis配置：

127.0.0.1:6379> config get *append*
1) "no-appendfsync-on-rewrite"
2) "no"
3) "appendonly"
4) "yes"
5) "appendfsync"
6) "everysec"

从配置看，原因理论上就很清楚了：我们的这个Redis示例使用AOF进行持久化(appendonly)，appendfsync策略采用的是everysec刷盘。但是AOF随着时间推移，文件会越来越大，因此，Redis还有一个rewrite策略，实现AOF文件的减肥，但是结果的幂等的。我们no-appendfsync-on-rewrite的策略是 no. 这就会导致在进行rewrite操作时，appendfsync会被阻塞。如果当前AOF文件很大，那么相应的rewrite时间会变长，appendfsync被阻塞的时间也会更长。

这不是什么新问题，很多开启AOF的业务场景都会遇到这个问题。解决的办法有这么几个：

  1. 将no-appendfsync-on-rewrite设置为yes. 这样可以避免与appendfsync争用文件句柄，但是在rewrite期间的AOF有丢失的风险。
  2. 给当前Redis实例添加slave节点，当前节点设置为master, 然后master节点关闭AOF，slave节点开启AOF。这样的方式的风险是如果master挂掉，尚没有同步到salve的数据会丢失。

我们采取了折中的方式：在master节点设置将no-appendfsync-on-rewrite设置为yes，同时添加slave节点。

理论上，问题应该解决了吧？啊蛤，的确是理论上。

修改后第一天，问题又出现了。惊不惊喜，意不意外？

于是，小伙伴又重新复习了一下当时出问题时候的Redis日志：

有两个点比较可以：

  1. 前几条AOF日志告警日志发生在晚上3~5点之间，而那个时候，我们整个系统负载是非常低的。
  2. 清晨的告警日志不是某一个Redis实例告警，而是该机器上的所有Redis实例都在告警。

在这种百思不得骑姐的情况下，结合历史上被坑的经验，我们99%断定是我们使用的云主机存在问题。

这个问题有可能是宿主机超售太多导致单个租户实际能使用到的云盘IO比标称值低，也有可能是租户隔离做得不好，导致坏邻居过度占用IO影响其他租户。

这个很好理解：我们使用的是阿里云的云SSD，而阿里云目前的架构还没有做到计算和存储分离，即计算和存储的网络IO是共享的。

当然目前这个问题还没有实锤，我们也还在跟阿里云积极沟通解决。同时为了避免给自己惹麻烦，我还是留了1%的其他可能性?

祝大家周末愉快！

参考资料

Redis相关—Redis持久化

Dropbox Bandaid 微服务反向代理/Sevice Mesh 代理解析

发表于由
回复

随着微服务架构以及的广泛普及，很多公司都会使用或者自行开发自己的API Gateway, 甚至在内部服务也会应用Service Mesh.

不久前，看到了一篇Dropbox公司介绍其内部服务代理Bandaid的文章: Meet Bandaid, the Dropbox service proxy. 不得不说设计细节一贯独角兽风格，非常有收获，对于改进我们自己设计的proxy 也有一定参考意义。这里做一个简单的读后笔记。英语好的同学可以直接阅读原文。（插一句，Dropbox不久前在美股上市了，在中美贸易战中为数不多逆势上涨的股票之一，玩美股的同学可以关注一下。再插一句：股市有风险，投资须谨慎。）

Bandaid 诞生的背景

Bandaid 是有公司内部的反向代理服务演变而来，使用Golang实现。反向代理有很多成熟的解决方案，之所以选择自行开发主要有以下几个原因：

  • 更好的与与内部的基础设施集成
  • 可以复用公司内部基础库（更好的与内部代码集成）
  • 减少对外部的依赖，团队可以灵活的按需开发
  • 更适合公司内某些特殊使用场景

上面的大部分因素根我们进行微服务组件开发时候的考量基本一致。这也是我们当初没有使用Go kit 这种工具套装进行架构微服务改造的顾虑，当然，那个时候还没有这些工具链。

Bandaid 的特性

  • 支持多种负载均衡策略 (round-robin, least N random choices, absolute least connection, pinning peer)
  • 支持 https to http
  • 上下游支持 http2
  • 路由改写
  • 缓存请求与响应
  • host级别的逻辑隔离
  • 配置热加载
  • 服务发现
  • 路由信息统计
  • 支持gRPC代理
  • 支持HTTP/gRPC健康检查
  • 流量支持按权重分配和金丝雀测试

丰富的负载均衡策略，以及对HTTP/2和gRPC的支持实例亮点。要知道，nginx 从 1.13.10才开始支持gRPC.

另一方面，从支持的特性看，如果要求不是特别多，直接用来作为Service Mesh也是相当不错的。而且由于是使用Go开发，对于本来就在使用Go作为技术栈的团队来说，无论是使用还是二次开发，门槛和学习成本都是很低的。

Bandaid 设计解析

整体架构

请求队列设计

接收的请求按照LIFO 后入先出的方式进行处理。这个设计有点反直觉，但却是合理的：

  • 绝大部分情况下，队列应该是空或者接近空的状态。因此LIFO的策略并不会恶化队列最大等待时间。
  • 根据业务类型，可以配置队列的优先级和长度。可以非常方便的实现服务限流、服务降级和熔断器。
  • Bandaid 采用总是接收TCP连接，并将连接交由用户态管理的策略。结合LIFO有一个很大的好处：
    • 与内核态管理连接比较，如果客户端发送请求后意外关闭了TCP连接，Bandaid 是无法马上获取到该错误的，需要等到读取完该请求，然后处理请求后开始写response时才会触发错误，发现这个连接其实已经关闭。因此，处理这类请求是在无谓的消耗服务器资源。而采用LIFO和用户态管理连接的话，Bandaid 可以根据配置的超时策略，一定程度上drop掉这类请求，减少处理这种「dead request」的数量。

Worker 设计

Worker采取固定大小的工作池设计，一方面可以精确的控制并发数量，另一方面，也避免频繁创建worker的开销。不过文中也承认，池的大小在设置的时候需要结合业务考虑清楚，否则可能不能充分利用服务器资源，错误的触发服务降级。

worker在处理队列中的请求时，支持按照优先和权重处理。因此，可以非常容易的实现金丝雀发布和逻辑上的upstream隔离。

负载均衡策略

  • RR, 均匀撒胡椒面。优点是足够简单，缺点是没有考虑不同后端服务实例的数量和接口处理时长差异，会导致大量Bandaid 服务资源被极少数的慢服务和接口消耗掉。
  • least N random choices: 先随机选择N个候选upstream host, 然后选择连接数最少的host (认为是当前负载最低的)作为最终目标host.

这种方式在在大部分时候可以工作得很好，但对于那种快速失败的小服务会失效。因为这种服务有很大概率被选中，但是并不意味着其当前负载较低。缓解该策略的方式是absolute least connection.

  • absolute least connection: 从全局host中选择连接数最少的host作为目标host.

  • pinning peer: 将worker与host绑定。这种方式可以避免慢服务过量消耗Bandaid资源的问题，但是请求调度不够灵活。

总结

从 Bandaid 的设计看，无论是作为 reverse proxy 还是 service mesh 都有不错的潜力。不过 Dropbox 团队当前还没有公开Bandaid性能测试数据，代码也还没有开源。因此，猴急的同学可能还需要等一段时间。