工作的第二年+第三年上半年

本来 19 年 7 月写的，结果一拖再拖，拖了半年。以后还是按年份写吧。

这篇写 2018-07 至 2019-12 的事情。

公司、部门

19 年 1 月，我在年会上拿到了公司级别的优秀员工。

这一段时间内，特别是半年内，人员变动非常大：

18 年 8 月，来了个新同事，后来被孙总称为小可爱。

19 年 4 月底，飞哥离职。少了个强力战友。

19 年 8 月，原组内女同事 4/5

19 年 9 月，产品经理离职。从此木有霸气的产品经理了。原组内女同事 3/5

19 年 10 月，原组内女同事 2/5

19 年 12 月，原组内女同事 1/5

产品经理换了三个，现在处于没有产品经理的状态。

人员是越来越少了，喜提 N+1 的也没几个。拿到 N+1 的各个开心得不得了（羡慕）。

部门每个离职的同事都会请一顿下午茶。外加最近部门几个关系好的小伙伴会比较经常地出去聚餐，以前一季度一次（称为季度总结），现在一个月最少一次。以至于我胖了 6 斤。

项目

分两个时期来写：维护和开发旧系统；设计和开发新系统（重写旧系统）。

旧系统就是 18 年那篇的 A 项目，拥有十年以上的历史。

为了方便，以下在必要时会将旧系统称为 V1，新系统称为 V2。

维护和开发旧系统（18-07 ~ 18-12）

这个时期的压力还算不是很大，没有什么任务是非常赶时间的。大部分都在八点半左右就下班回去了（此时的加班标准是达到八点半）。时间点跟宿舍换到离公司很远有关系，在生活篇中有提到。

比较可以一提的有：

• 写了套简易的异步任务管理器（18-10）
  V1 原先是这样的：发送一个任务给外部系统，然后流程流转到下一步执行检测。如果任务还没完成，就报错，然后每隔 1 分钟尝试一次，直到任务结束。
  但是后来碰到一个要发送的任务是在发送任务后，我们会得到一个发送成功的消息。等任务结束，对方会回调我们这边的接口。如果对方超时了，我方提示超时错误。
  于是结合 crontab 写了个处理，当对方调用我方接口后，才让流程执行检测步骤。业务上可容忍一分钟的延迟，所以不需要太复杂的组件。

• 引入服务容器（18-11）
  原先创建一个类是直接 new 或者使用 get/set 注入，而在 11 月的时候我把 Laravel 的 Container 库引入进来。使用服务容器获取服务对象。以便于测试。

• 优化了个冗长且经常改动的 if-else（18-11）
  这是一个根据多个条件判断选取哪些数据的 if-else，它直接嵌在某个业务代码里面，其他地方无法使用。
  开早会的时候经常看到需求方又提了个添加条件的需求。于是我请求组长给我点时间把它优化成需求方可以自主配置的形式。
  原先需求方提需求的时候，会发一个 Excel 过来，然后把变更点用特殊颜色标记。这个形式就不做变化了。在云云小姐姐的帮助下，与需求方共同确定了数据格式。
  我做了个读取 Excel 并转换为 Json 文本的转换器，在需要数据的时候读取 Json 判断。用户上传 Excel 后，会得到新旧的数据差异，确保没有问题。
  其实做成界面直接配置更好，然而我们这边没有专门的前端，我也不太想花时间在前端上（Vue 除外）。

设计和开发新系统（19-01 ~ 19-12）

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110

+ 201901
|
|        用 户 登 录 （ Token） 和 信 息 获 取 ， 学 习 和 应 用 Restful
|
| 201902
|
|        引 入 流 程 引 擎 （ Camunda）， 实 现 创 建 流 程 实 例 、 表 单 暂 存 、 获 取 流 程 信 息 的 Adapter
|
| 201903
|
|        提 供 流 程 引 擎 查 询 接 口
|
|        流 程 实 例 执 行 日 志 记 录
|
|        参 考 Java 版 的 Camunda External Task Client 写 了 PHP 版
|
|        实 现 External Task Client 根 据 流 程 节 点 ID 计 算 请 求 的 API 地 址
|
|        实 现 了 节 点 跳 转 (向 任 意 目 标 节 点 )、 跳 过 当 前 节 点 、暂 停 /继 续 的 Adapter
|
|        添 加 GraphQL 客 户 端
|
|        实 现 流 程 节 点 逻 辑 （ 业 务 ）， 共 15 个 节 点
|
| 201904
|
|        实 现 流 程 节 点 逻 辑 （ 业 务 ）， 共 23 个 节 点
|
|        实 现 流 程 节 点 重 试 的 Adapter
|
|        实 现 终 止 / 激 活 的 Adapter
|
| 201905
|
|        实 现 流 程 节 点 逻 辑 （ 业 务 ） ， 共 5 个 节 点
|
|        使 用 MinIO 作 为 文 件 服 务 器 ， 实 现 了 文 件 版 本 支 持
|
|        封 装 脚 本 传 输 和 执 行 工 具
|
|        实 现 Elastic Search 查 询 Adapter
|
|        使 用 Redis 作 为 缓 存 服 务
|
|
| 201906
|
|        实 现 流 程 节 点 逻 辑 （ 业 务 ） ， 共 30 个 节 点
|
|        添 加 静 态 代 码 检 测 ( PHPCS )， 使 用 Gitlab CI 执 行
|
|        同 步 流 程 流 转 改 为 异 步 ， 添 加 检 测 器 ( 将 循 环 检 测 转 移 到 流 程 外 部 )
|
|        流 程 实 例 出 现 非 预 期 错 误 时 ， 自 动 转 交 给 值 班 人 员 ( 涉 及 值 班 轮 班 规 则 )
|
|        脚 本 传 输 和 执 行 添 加 批 量 并 发 支 持
|
| 201907
|
|        实 现 流 程 节 点 逻 辑 （ 业 务 ） ， 共 6 个 节 点
|
|        整 理 流 程 的 业 务 文 档 ( 约 28 个 节 点 )
|
|
| 201908
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
v

耗时一个月写 Camunda 的 Adapter，使得它能够满足当前业务的需要。

疑问：

GraphQL 什么时候引入？

RPC Shell Wrapper 什么时候重写？

文档什么时候写？

将 V2 的东西搬到 V1

日志

难度不大，收益明显。不太值得一提，仅作为记录。

V1 的场景：V1 经常会有问题，后台有经常查当天日志的需求。

我们在内部交流工具里有创建一个服务号，项目内的四五个成员一人一天轮流值班。

查业务日志的做法已经很少有一台台服务器去查的了，通常都是将所有服务器日志统一到一个地方。比较常见的是 ELK。

V2 的日志是用 Filebeat 采集然后放到 ELK，但 V1 不是，导致 V1 查日志的体验很不好。

V1 的做法是：把查询请求发送到每台服务器上，对 grep 日志文件，然后返回并汇总结果展示在界面上。

优点：实现简单

缺点：

• 没有实现分页查询和多条件查询（但有某个月内时间范围查询）
  因此查日志的时候是用某个字符串查出所有相关日志，再用浏览器上的 ctrl + f 查询到想要的数据。
• 查询缓慢，如果想要查半年前的数据，一般要半小时。有时候甚至要查一年前的数据。等得很痛苦。
  有时候会有这样的问题排查需求：系统有个数据有问题，但不知道这个数据是什么时候变更的。结果一查日志发现是一年前的变更。不过这种需求极少，通常只需要查当天的日志。
• 日志查询中有个指定日志文件的参数，不能传范围。如果想查半年前的数据，得一个个月去查或者查一整年的日志。

我后来用 rsyslog 把这些日志收集起来，丢到 ELK。由于通常只查当天数据，偶尔查 7 天内的数据，所以 E 和 L 不需要做什么特别的优化，只是设置日志的索引粒度为一天。

为什么不用 Filebeat ？因为 V1 这个项目跑在 CentOS 5 上面，Filebeat 是用 Go 写的，Go 不支持 CenOS 5（内核版本过低，至少要 2.6.23）。
如果只是为了收集日志而把系统升上去了，到时就要面对更多问题，搞了半天却发现已经偏离收集日志这项工作了。

结果是：

• 当天数据查询耗时降低到原来的三分之一
• 一个月内的日志查询耗时降低到原来的三十五分之一
• 半年前的数据查询耗时为原来的三分之一

自从把日志收集到 ES 后，大大地提高了值班体验（虽然仍然很痛苦）。