TSDB 起步知识
TSDB (Time Series Database) 是一种专为时间戳或时间序列的数据优化的数据库。如果非要想象的话，它存储的是 [[timestamp, value], [timestamp, value], ...] 这样的数据，额外加上一些标签啊，名字啊，索引啊之类的特性。它使用的场景是监控，各种类型的监控：Host / APM /Network / User Behaviors / Sales, etc。如果不优化，数据库的 IO 很有可能出现瓶颈，CPU 做聚合运算的时候出现运力不足；你当然可以通过攒机器扩展来解决，但有了 TSDB，单机可以解决很大一部分问题。
TSDB 并不是什么新东西，它的概念也很简单，只是后端服务进入服务化阶段，各种指标都会冒出来，有来自应用的，有来自业务的，也有来自机器或网络本身。我们需要一个现代的 TSDB 来优化存储，已经查询这些监控得到的数据点。
TSDB 的使用体验相比关系型数据库简单多了，灌数据进去 …
read moreCRUD != Services, Behaviors = Services
这篇文章中作者不建议写 Entity Service (指的是那种提供数据增删改查的服务），想对比数据，更应该从用户行为开始着手设计系统。
作者介绍了一种构建系统的简易方法："Tell, Don't Ask."。它其实源于我们在大学里面学到的经典软件开发流程：整理 Use Case，抽象领域模型，然后构建系统。具体操作方法是这样：假设你扮演一个你要实现的系统，要处理一个用户请求。系统中的每个服务不向外问信息，只给请求增加信息，然后传递给下一个系统。
它生成的系统设计，会使将一套行为封装进服务中，服务对外发布仅能自己这个服务给出的消息，其它服务或订阅消息或被主动触发。事实上，这些消息最合适被推到的地方，就是 a message bus。
一致性问题仍然会出现，解决方法作者下期给出来。
衍生思考：
- 我觉得接触过 Redux 的前端同学都会笑而不语，后端们怎么在纠结这么简单的问题。你们的 Message Bus 就是 Redux 里面的 Store，这个消息就是 Redux 里面的 …
InfluxDB 系统设计 Pros v/s Cons
本文是 InfluxDB 自家写的 Pros v/s Cons，看看这款工具的权衡利弊。
- 同一时间点上的指标数据会被合并。好处是简化了冲突增加了性能，坏处是无法存储冗余数据，可能有数据丢失。
- 删除数据不友好。好处是读写性能都增强，坏处是不太好删数据。
- 修改数据不友好。好坏与上面类似。
- 数据按时间序线性入库。好处是性能高，坏处是数据点时间随机入库的话性能就差了。
- 数据库第一优先是处理大量数据读写。好处是系统 Brandwidth 好，坏处是性能会降一些。
- 写数据和查数据优于数据一致性。好处是多客户端高负载的情况下依然工作地很好，坏处是性能差的时候查询最近的点可能不会被包含进来。
- 时间序列生命周期很短。好处是可以处理不连续的数据，坏处是不支持schema,join这些关系操作。
- 一个数据点不太重要。好处是可以引入聚合等功能，坏处是数据点没有 ID 这种东西，纯粹靠时间戳来认。
衍生思考：我们可以看到每个假定部分都是监控领域的场景：监控服务，产生出大量基于时间序列的数据，灌进数据库，产生出很高的 IO；我们一般只关心最近发生的事件，发生过的事情就丢了不要了。经常做采样聚合切换精度来查看系统行为。
read more如何从监控指标中评定系统行为符合预期？
后端的计算资源这几年在剧烈变更，DevOps 们应该意识到很多 Monitoring 的基本概念也应该要跟上了！
Monitoring 的核心是观察和监测系统行为，如何界定系统行为是正确的。我们的部署和开发流程以天，小时的速度在迭代，变更让系统变的很脆弱，也使其正确性更难界定。各种后端服务的引入让系统混入网络问题的复杂性。节点死死生生，架构动态扩容缩容，监控应该如何面对这些挑战呢？
- 自顶向下地梳理业务，核心组件必须监控到位。
- 系统不是非好即坏，数字或者延时是更好的指标。这里面的挑战是，即便是每分钟采点，大量的指标也会产生大量的数据。怎么分析呢？统计学可以是解决系统行为的好工具。
- 对过去发生的事故仔细分析，从数据点中找出关联，从而监控到位。
- 设定 SLI/SLO/SLA，从服务级别去思考服务的监控（跟第一点很像）。
衍生思考：从裸的监控指标中抽取出有意义的，面向服务或商业的解读正是我个人目前的主要工作内容。这篇文章讲到的这几点确实是我目前工作中遇到的难点。尽管讲的很虚，但又觉得梳理地很到痛点。
read morePGP 必须死，为什么？
PGP 是一个加密程序，提供数据通信需要的密码支持。互联网的早期，为了保障邮件内容不被泄漏，人们开发了加密软件 PGP，尽管它被用的很广泛，但它难用隐患又多。不好用的点在于：
- PGP keys 对机器友好，对人类不友好，其传输和验证过程需要引入组件 key servers 和 public key fingerprints。这个过程其实还是蛮容易被恶意攻击者抓到漏洞从而被攻破：从 key server 根据 fingerprint 取回 key 的过程一来从公网走泄漏了请求，二来可能被中间人篡改成了假 key。
- PGP key 管理不好用。在 WebMail 领域，解决方案可以是 "Web of trust": 每个人都互相签署对方的 Key，尽管这个方案并不多人用。另外的解决方案是信任 Google / Yahoo / Keybase …
从 inode 出发了解文件系统的大部分概念
本文从 inode 开始解释所有文件系统的概念，是对新手来说很好的文章，每个概念都只花了大约一句话，像 main 函数调用触发了所有子函数一样精美，如果用两个词来描述这篇文章，那就是 very cool。
- inode 是数据结构，由 Linux 和其它 Unix-like 操作系统里的文件系统提供，存储除了文件名和文件内容外的所有信息。
- 数据结构是 c struct，可以存储多种数据类型（例如整型，浮点，等等）。
- 文件系统是关于目录的层级结构， 也叫目录树，这些目录用于组织文件。
- 文件是一个有名字的，用户层面上看数据是连续块的，在存储器(storage)里被持久化存储的信息。
- 文件的元信息是关于文件非内容部分的信息，包括文件大小，物理位置（存储器块的地址），文件 owner，group，权限，几种时间戳，以及指向 inode 的硬链接的引用计数。
- 存储器是长时间存储数据的中介，例如硬盘和磁带 …
程序员们更偏爱 Exiting Early 的代码风格
有一种写代码风格叫 Exiting Early, 基本上写代码的时候，非法的 case 先处理，提前 return 或抛错，最后才写正常流。与之相对应的是先写正常流，然后逐个处理异常流。大部分程序员更偏向 Exiting Early (也叫 Early Return, Guard Clauses, the Bouncer Pattern)。
- 这里面可能涉及到一个认知问题：Base Cases 越想越少，越来越接近 Good Case。
- Early Return 能让你轻易写出没有嵌套的代码。一系列的 if 可能很丑，但决定比 if 里面套 N 个 if 来的好读。这里面也藏着一个设定：到达了一个 Dead End 分支 …
