LinkedIn Real-Time Presence Platform 的实现
Presence 系统说白了就是那套标记在线隐身正在忙这些状态的系统，LinkedIn 使用的技术栈是 Play Framework & Akka Actor Model，处理的流量量级为 1.8K QPS。
从业务上来说，要存储的数据自然是 online status + timestamp，挑战倒不在数据存储，而是怎么把这样的数据变更推到 C 端该用户的关注者，特别是那些正停留在该用户页面上浏览的那些用户。关于推送这个流程，Linkedin 的做法是浏览器保持实时连接，然后引入 Pub/Sub 系统，让这个实时连接去 Sub 另外一个用户的 user presence topic。当某个用户上线了，Presence Platform 就 Pub 消息到频道，这样另外一边的用户就收到推送了。
这个系统要解决的另外一个大问题是用户反复上线下线给系统造成不必要的压力，这可能会是用户网络情况不给力等原因。LinkedIn 的做法倒也简单，实时连接加上一个心跳，一轮心跳 …
read morePython `JSON` 库的一些不为人知的用法
JSON 作为 REST API 事实上的标准序列化表示 (serialized representation)，在 Python 很早的版本就加入了支持。很多人也许平时只用 json.dumps() / json.loads() 这几个方法，但事实上，这个库还有不少小众但好用的功能。
json.dumps(data, indent=4): 配置缩进json.dumps(data, sort_keys=True): 序列化以后 key 是排序好的- ^ 以上两个方法还是给人看的，数据量会加大。
json.dumps(data, separators=(',', ':'): 序列化的时候, object :, 中间的空格都不要了。默认用的separators=(', ', ': ')。这个方法可以压缩最后的数据量。json.dumps(data, skipkeys=True …
Metaparticle 技术 - 分布式太难，我们用这个偷懒的工具
在将应用程序切换到分布式系统的时候，将会经历一番工具噩梦，你要考虑代码，编译，打包，写镜像，配容器，推 registry，配集群，配k8s，配置yaml，此外还有各种工具，语言，文件要管理，中间环节错一个系统就可能会出错。回到软件开发的最本源，我们希望一切难题可以通过写代码来解决，这个视频中演讲者讲述了通过 metaparticle 技术来解决这个问题。我们仅仅只需要在 Web 应用中添加几个装饰器，配置上例如 @containerize('docker.io/my-image', options) 这样的代码，你的应用启动时就会转为从 docker 启动。你可以将 Metaparticle 理解为一种 cloud native application 的标准库，普通应用程序加上几行 metaparticle 的代码后就能变为分布式系统。而这些代码你不用再去理会什么 dockerfile，什么 yaml，你的应用是 …
Google SRE 们如何做 Escalation 和事故应急响应
本文是 Google Cloud Platform 团队的工程博客新文章，通过不少例子介绍了在 Google 内部是如何在开发和保障服务可靠性之间做权衡。简单介绍 Google SRE 团队的现状：两个 Shard 在欧洲和美国两个时区的团队各值守 12 小时，两班倒，监控核心的 10 个最高流量的服务外加十几个小一些的服务。这个团队的监控指标既有关于用户使用体验的顶级 SLO 指标，也有核心组件可用性的细粒度的 SLO 指标。一旦出了问题，SRE 团队可以将任何单一相对应的 SLO 指标转给相关的开发团队去核查。服务会配置 error budget，举个例子，对于某个服务，如果一小时内烧掉九个小时的错误预算就报警；如果一周的错误预算超过上周的，那就提工单建档排查。
从 Escalation policy 的目的来看，它既要能保证快速响应，又要减少不必要的误报，并保持测量项的准确度。对此，Google …
read moreGLB - 看看 GibHub 如何做负载均衡
本文是 GitHub 工程团队博客对他们的负载均衡器 GLB (GitHub Load Balancer) 做的简介。
- 挑战
- 要同时支持 HTTP, SSH, Git 三种协议的流量。
- 每天流量数十亿。
- 历史架构
- 跑在专用的，调优过，巨大的 Bare Metal （裸机）。
- Haproxy 做故障转移。
- 硬件上支持 10G link 故障转移。
- ^ 遇到的问题
- 网络硬件，负载均衡的主机，硬件配置，三者都混写在一起，太痛苦。
- 没法水平扩展。
- 描述期望
- 能跑在普通的商用硬件上。
- 能水平扩展。
- 支持高可用，故障转移时 abort TCP 连接。
- 支持 connection draining （感觉是 graceful shutdown …
系统组件失效时的常见应对策略
如果遇到了网络，硬件，程序级别的组件失效，我们应该如何保证最小化影响呢？本文介绍了常见的技巧和策略。
- 大多数宕机源于系统变更：代码更新，配置变更等等。解决方案是变更先在一小部分实例中应用，通过监控，可以在有不良影响发生是快速回滚。
- 另一种方案是 blue-green / red-black 部署，部署两份，但负载均衡只指向其中一个，上线就是上到其中一个，然后让负载均衡切换到另一个。
- 应用提供
GET /health之类的接口，或者其它自己报告的方法，告诉负载均衡自己的健康情况。负载均衡将其移除出 Pool Members，如果一个实例遇到了问题。 - Self Healing：可以开发一个系统，监控实例的健康，如果坏掉了，就自动将其启动。当然，我们要考虑程序过载，应用到数据库链接超时等等因素进来。需要引入额外的逻辑，知道当遇到什么情况的时候不要重启坏掉的实例。
- Failover Caching：相比服务挂掉什么都没了，如果可以接受返回过期数据，那就可以引入缓存组件。
- Retry: 当应用好了以后可以重试执行一些操作，不过要小心，它可能会引发层叠效应 …
