知一杂谈

你有没有遇到过一个函数几百行长度，如果没有可以跳过本文章了，如果没有那么应该看看下面的内容。一个超长函数的复杂性不在于那些胶水代码，而是其中的逻辑分支，大量的逻辑分支导致你的代码难以理解。而重构的过程分为两步：

1. 编写单元测试，如果覆盖到了函数的每个分支，那么重构的风险性就会降到最低。
2. 重构代码，对代码进行拆分重写，为了使代码变得易于维护。

重构分为三个层次：

1. 小重构
   • 消除重复代码
   • 拆分小函数（单一职责）
2. 设计模式
   • GoF 23种
3. 抽象建模
   • 四色建模法
   • 风暴建模法

复杂度问题的应对办法，防止偶然复杂性。

TODO

背景介绍

首先介绍一下实体电商通用的售后流程。

1. 用户申请：在用户申请操作时需要填写退货、换货，以及原因。
2. 商家审核：商家会根据沟通情况审核售后申请。
3. 用户回寄：审核通过后需要用户回寄商品。
4. 确认退换：商家收货确认后会给用户退款或者邮寄新货。

虚拟商品的售后通用流程如下：

1. 管理员发起退换操作
2. 处理退换
   • 退：先退货后退款
   • 换：先退货后发货

在以上两个流程的处理流程有个共通的地方，就是一次操作需要涉及多个子流程的处理，这就是接下来需要讲的通用售后流程抽象。多个子流程的处理意味着要和多个子系统分别进行沟通处理退货、换货和退款。

这里就涉及到分布式系统的一致性问题了，售后模块作为资源的协调方，我们是否可以采用 TCC 的强一致性方案？答案是 No，成本有点高。普遍的做法是采用弱一致性方案保证最终一致性，我们可以考虑采用 Pipeline 机制。

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

• 迁移背景
• 前期准备
  • 迁移方案
  • 接口验证
  • 指标梳理
• 可用性保障
  • 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）。

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