精子生于 1995 年，英文 ID jysperm.
2019 年度小结（技术方面）
Redis 的工程价值
今年一开始先是完善了去年的 任务队列，为了让它真正地被用起来，我将之前由另外一个服务实现的定时任务系统也合并进了这个任务队列，让它有了一些固定的流量，以便我来发现性能上的问题，进一步完善它。
这项工作最后取得了还不错的效果，开始有了用户使用任务队列的功能。我也写了一篇文章来介绍 用 Redis 来实现定时任务，当然这篇文章中介绍的是一种经过极度简化的范式，实际上实际的代码要复杂的多，例如序列化、错误处理、结果查询、限流、统计等额外的特性。
这个项目让我再度增加了对 Redis 的好感，这次我用到了比较大量的 Lua Script 来保证分布式架构下的一致性（Redis 的Lua Script 会被独占地执行）。在将一致性需求限制到单个 Redis 实例可以容纳的范围（Redis 只使用一个线程）并且 Redis 运行相对稳定的情况（故障切换会丢失数据），Redis 为业务层提供了一个非常「够用」的高性能的、有一致性保证的数据同步方案。这并不是说 Redis 提供的方案有多么完美，而是在性能、功能、一致性、可靠性上提供了一个非常好的这种，更具有工程价值。
Golang 的表达能力
我还尝试了为 LeanCloud 写一个 Golang 的 SDK（后来因时间安排的关系暂停掉了，目前还未发布），就像之前我为 DeployBeta 写 ORM 一样，同样遇到了 Golang表达能力不足的问题。问题主要在于 Golang 中并没有能让 Struct 继承方法的机制（数据字段则可以通过内嵌匿名 Struct 的方式来继承）。
所以当用户定义一个「继承」自 ORM 基类的 Struct 时，我们无法向用户定义的 Struct 上添加例如 Save、Set 之类的方法，无法有效地追踪用户对于数据对象的改动。
经过几个版本的改动，我最后选择了一种将所有基本类型（string、int）包装为 Struct 的方案：
type Todo struct {
orm.ObjectMeta
Name orm.String `orm:"name"`
Priority orm.Number `orm:"priority"`
}
todo := Todo{
Name: orm.NewString("test"),
Priority: orm.NewNumber(1),
}
err = orm.Save(&todo)
todo.Name.Set("test")
todo.Priority.Incr(1)
err = orm.Save(&todo)
fmt.Println(todo.Name.Get(), todo.Priority.Get())
这个方案可以做到不以字符串的形式传递字段名（可以得到编译期的类型检查），可以追踪对每个字段进行的修改（包括 Incr 等运算）。我将 Set 添加到了基本类型的封装类型上，将 Save 作为了一个全局方法，避开了 Golang 对于继承的限制。带来的问题则是用户需要通过我们的封装方法（Get）来访问字段的值；同时今后设计嵌套对象时也需要更大的工作量。
所以并不是如 Golang 的支持者说的那样，更少的特性意味着更简单的设计。当业务逻辑确实复杂，语言表达能力又非常匮乏的情况下，会逼着开发者做出一些不优雅的、不易理解的、反常规的设计，这些代码往往非常容易出错（例如反射、代码生成、强制类型转换等），而本来这些需求（如继承）在其他语言里是可以非常轻易地解决的。
TypeScript 的胜利
之前因为对 CoffeeScript 的喜爱，我的 TypeScript 使用经验非常少，终于今年我也不得不去接受 TypeScript 了。今年我用 TypeScript 开发了两个新的后端项目，也更深入地学习了 TypeScript，经过进一步的了解，我逐渐地发现了 TypeScript 的闪光点，之后我会单独写一篇文章来介绍 TypeScript。
TypeScript 有着一个先进的类型系统，这种先进并非是学术意义上的先进，而是工程意义上的先进。它几乎可以为所有 JavaScript 中常见的范式添加静态约束，得益于强大的类型推导，在大部分情况下并不需要自己添加类型标注，但却能在编译期提前发现错误、配合 Language Server 得到准确的代码补全和类型提示信息，完全没有前面提到的 Golang 中的那种束缚感。
因为 TypeScript 并不打算创造新的范式，而是尽可能将 JavaScript 社区中已有的范式用静态类型的语义描述起来。这样最大程度上地降低了 JavaScript 开发者学习的成本，提高了与标准 JavaScript 代码的互操作性，我认为这也是 TypeScript 能够取得成功的关键。
同时我也不得不接受 Atom 的市场已经几乎完全被 VS Code 取代的现实，切换到了对 TypeScript 支持更好的 VS Code。现在想想 Atom 失败的原因一方面是在 CoffeeScript 已经表现出没落的时候选择了 CoffeeScript；另一方面是希望依靠社区的力量，但又缺乏对社区的引导。例如对于插件的 GUI 改动引导不够导致界面卡顿，对于代码补全、调试等常见需求没能建立统一的标准等等。
Kubernetes 的阴谋
今年其中一个新项目是开发一个数据库调度平台，在 Kubernetes 上运行数据库容器，这和我之前在 DeployBeta 实现的原型非常相似，只不过这次是真的要上线的项目。
在去年和今年对 Kubernetes 的了解过程中我逐渐对 Kubernetes 由粉转黑。我现在认为 Kubernetes 是以 Google 为首的三大云计算巨头的垄断工具，他们开发出了一个如此复杂的系统，并引导其作为行业标准。虽然 Kubernetes 是开源并由社区维护的，但真正能够独立搭建好 Kubernetes 及其插件的公司是极少数，甚至可以说除了三大巨头之外，其他的云计算公司都不能提供稳定可靠的 Kubernetes 集群。最后大家在尝试过自己搭建之后，还是不得不购买三大巨头的 Kubernetes 云，毕竟这是行业标准嘛。
今年看过觉得最好的书是「数据密集型应用系统设计（DDIA）」，它给我的数据库调度平台带来了很多启发。书中介绍了分布式架构对于数据库的挑战，包括数据模型、复制、分区、事务、分布式共识等等，以及各个数据库在面对这些挑战时采取的解决方案，只有理清这些思路，才能在面对复杂的业务的时候采用一种或几种合适的数据库。
我的理解是当数据存在于两台或更多的计算机之上时（原因可能是容量或可用性要求），就可以称作「大数据」了。因为从一台到两台是一个质的变化，而从两台到更多只不过是量的变化。就如书中所说，在单机条件下，所有的称作都是确定的，一个操作要么成功要么失败（可能伴随着程序或系统的崩溃）；但在分布式条件下，对于经过网络的操作会引入成功和失败之外的第三种情况 —— 网络延迟，你无法预测一个操作会在下一秒完成还是永远都不会完成。所以分布式系统需要被设计成可以在容忍一定的错误（部分失效）的情况下继续运行。无论是一个分布式数据库还是一个分布式的容器平台，其实都在与这种不确定性的超时进行对抗。
写不下去的业余项目
现在我愈发认识到软件开发不是一个人的单打独斗，之前在做一些业余项目的时候还会有一些幻想，幻想自己能长期维护下去、能吸引到其他的贡献者、能建立起一个社区。但现在想想还是以内容作为主要的输出更有可行性。同时因为我对现在的工作非常满意，在工作中基本完全满足了我对于写代码和团队协作的欲望，所以我可以将业余时间放在其他的输出形式上，在接下来一年中输出更多的文章或视频，这样我的经验和知识会给读者带来更大的价值。