知一杂谈

本文主要介绍知乎订单系统后端语言栈的转型升级过程，包括其间踩过的一些坑和遇到的一些问题。一来是想通过本篇文章为其它应用服务转型提供借鉴经验，二来是总结对于订单系统的理解。鉴于文字功底不足，对于业务理解不充分的地方，欢迎留言交流。文章大纲如下：

• 迁移背景
• 前期准备
  • 迁移方案
  • 接口验证
  • 指标梳理
• 可用性保障
  • MTTR 快速响应
  • MTBF 降低故障率
• 一致性保障
• 事后总结
  • 目标回顾
  • 执行计划
  • 执行结果
  • 问题整理
• 业务沉淀
• 方法论实践
• 参考文章
• 招聘信息

迁移背景

随着知乎整体技术栈的变化，原有的 Python 技术栈逐渐被抛弃，新的 Go 和 Java 技术栈逐渐兴起。知乎交易系统的稳定性相比其它业务系统的稳定性重要很多，因为交易系统核心链路发生故障不仅会造成数据问题，还会造成严重的资损问题。
随着公司业务的不断壮大发展，交易场景变得复杂，重构和优化难以避免，因为语言特性，Python 虽然开始撸代码很爽，但是后期的维护成本慢慢变高，不过 Python 在数据分析和人工智能方向上还是有很大优势的，只是在交易领域目前看起来不太合适。从技术生态上来说，用 Java 做交易系统会更有优势，所以接下来要说的知乎订单系统语言栈转型。
另外一个因素是 Python 的 GIL 锁导致它无法发挥多核的优势，性能上受到很大限制，在实际情况中遇到过多次主线程被 hang 住导致的可用性故障，所以坚定决心来迁移掉旧系统。

本文是对于订单建模的一点思考整理，里面应用一些对领域驱动设计的思考，默认读者对于领域概念有一些基本了解。

基本元素

交易最早是通过以物易物的方式来交换，后面产生等价通用物品即货币。交易上下文领域对象包括：

1
2
3
4

顾客 Consumer
货 Goods
货币 Currency
商家 Merchant

对于交易一句话描述就是，顾客在商家那里通过等价货币购换取了货物。

BPMN 有什么优势呢，用了一段时间主要使用在业务流程表达上，表达符号比较多，相比流程图可以更清楚的表达业务流程，同步、异步，异常中断、事件消息等等，如果看图的人都对这些符号有概念，可以比较轻松的看懂业务流程。缺点就是符号太多，学习成本相对高一些。学会了就会对业务表达上有很好的助力。

范围

BPMN仅限于支持对业务流程有用的建模概念。这意味着组织所做的非业务目的其他类型建模将排除在BPMN之外。例如，以下方面的建模不属于BPMN的一部分：

• 组织结构
• 职能分解
• 数据模型

此外，虽然BPMN会显示数据的流（消息）以及活动与数据器物的关联，但它并非数据流图（data flow diagram）。

领域驱动设计中定义了超多的概念，如果不多找几篇资料综合的去看，正确的理解比较困难，下面搜集整理了大部分的领域驱动中的概念，并加以理解描述。

关注树莓派很久了，只是没有很感兴趣的应用场景，就没有买来玩。几个月前偶然得到一个小度音箱，发现了新大陆，各种语音控制功能，便捷性不言而喻，还买了一些外部设备可以通过小度控制，发现有红外遥控器可以控制家里的大部分红外家电，奈何码库不是很全，有些设备还是不能控制的，而且不支持定制功能。恰好在知乎看到了一些 geek 视频，想着自己也做一个，可以支持红外数据的定制，做到自由遥控。于是乎说干就干，从一个什么硬件都不懂的小白一步步的了解了点硬件知识，软件部分相对好实现一些。主要计划的功能是通过语音来控制红外家电、温湿度监控以及智能提醒等功能，先完成主体框架然后再不断开发插件形式来增强可玩性。

这个标题看起有点鸡汤文，不过我还是建议对以下总结出的几点做些深入思考，这些会在今后的工作中越来越多的感受到它的作用。

寻找你行业内的专家

找到你所属行业内的专家，这些人往往做事高效并且很有才华。你要做的是跟随他们所关注的方向，学习他们做事的方法，思考如何应用到你的工作和生活上。找到他们，和他们去交流思考，提出自己的观点和想法。不要仅仅把眼光放到身边的人身上，这样会局限住你的视野。