Xargin

If you don't keep moving, you'll quickly fall behind

Google 用了十年的 subset 算法被换掉了

之前在这篇 subset 限制连接数量 里,简单总结了 SRE book 书里讲到的 subset 算法的基本原理和问题。 之前还在做 mesh 的时候,也曾经想把 subset 算法在公司内落地,无奈和同事一起分析了两个星期以后,认为 subset 的: 1. 需要 paas 给每个 container 分配连续 id,且在下线时需要自动补漏,目前 k8s 其实并没有这种策略,给每个服务都做成 stateful-set

sarama producer hang 又一例

之前公司因为 aws 的 kafka 服务上的副本数配置不正确,所以在 aws 例行重启时会导致 producer hang,连锁导致消费断连,当时总结了一篇简单的文章: aws 上 kafka 服务更新导致断连一例公司内部写 kafka 的 consumer 和 producer 使用的是社区流行的 sarama 这个库,这个库应该 bug 挺多的,之前有云厂商建议用户不要使用该 lib 的文档:为什么不推荐使用Sarama Go客户端收发消息? 不过用都用了,

微服务税

现在稍微有一点规模的公司基本都上微服务了,后端工程师在大小公司打杂的话都会碰到因为是微服务,所以在做开发的时候: * 依赖太多,没有稳定的环境,服务跑不起来 * 服务要走网络,稳定性问题难以解决 * 上下游要解耦,每次上游做修改下游都会有故障 各种各样奇形怪状的问题,每一个痛点都会涉及到不少相关的解决方案,比如环境问题,之前我分享过 https://tilt.dev/;稳定性问题,我们直接去看 Google 三步曲 https://sre.google/books/;上下游用队列解耦之后,上游的不稳定业务事件导致下游故障,有 data validation 平台和 schema registry

平台到底有什么价值

不知不觉已经过了靠纯代码输出来做事情的阶段,很多时候做事情变成了说服别人做事情本身的价值,自己体力输出对于公司的贡献度已经越来越小了。作为一个架构师,需要能够帮助部门和公司走上正确的路线,避免无意义的内卷和消耗,以免让一线的开发心灰意冷无所成长最终提桶跑路。 2017 年,美团在南京上线了打车业务,滴滴上下为之震惊。彼时滴滴在本土兼并收购,打跑了洋人对手 Uber,正是意气风发之时。 又因为资本和老板之间良好关系的原因(CEO 们没少勾肩搭背吧),滴滴的高管们曾经认为美团绝对不会涉足打车领域,所以美团的决策让整个公司从上到下都很震惊。 O2O 业务在前期是笼络用户阶段,靠用户数量的增长为未来盈收的增长埋下种子,当业务达到一定规模,再以成本优势将用户对平台的依赖转化为平台的收益。 用户增长的核心引擎就是公司内部的运营系统,早期运营是大多数互联网公司的边缘业务,在大多数公司内大家一听到运营,想到的都是 CRM 系统,体感就非常之 low,

aws 上 kafka 服务更新导致断连一例

公司内部写 kafka 的 consumer 和 producer 使用的是社区流行的 sarama 这个库,这个库应该 bug 挺多的,之前有云厂商建议用户不要使用该 lib 的文档:为什么不推荐使用Sarama Go客户端收发消息? 不过用都用了,随便换也不好,碰到问题了还是要先定位一下,然后再去看到底是不是 lib 本身的质量问题导致。贸然就说这是 lib 的 bug 会让人鄙视。 现在就碰到这么个场景: 部门内有一个 kafka 的 message