总结一下自己，最近三年，我做了哪些工作

简单总结下吧，我算是业务架构师，确实对得起这个名字，经常冲在一线，业务和架构相关的东西都有做，系统比较复杂，不过逐步了解谁都会熟悉的
下面简单列一列我这三年的工作情况吧，也算是给自己一个交代，不全，但大体就这些了

2021年

业务系统熟悉，技术框架熟悉

参与交易模式开发

2022年

工作流改造

工作流支持前台用户的参与：（原设计只能后台进行审核，前台用户也无法审核参与）

1. 兼容老工作流使用

2. 重新封装接口，前端使用组件不用变化

3. 支持后台审核

4. 支持前台用户程序调用提交

5. 支持动态指定下一个审核人

6. 支持接口调用流转节点

7. 支持新增审核节点，可跳过业务，只做多节点的审核动作，无需更改代码

8. 支持业务审核记录的查看追踪

9. 支持审核过程中动态传递变量供决策等操作；支持多条线决策

容器化的搭建

功能能够给用户建立完整的系统，可通过运维平台查看操作相关功能，包括节点管理，容器组管理，容器管理工作负载，存储，配置等等，同时可部署常用的组件。

制作dockerfile，编写maven脚本打包安装包、镜像包推送到远程仓库

docker命令熟悉以及使用

可视化对接转化工具使用

一个公司的工具，比如对接银行时的报文不用写代码，像低码一样进行转化处理，弊端颇多，后来我封装了common包进行优化，定义规范，使调用方方便，使工具开发简洁，支持原来不支持的功能，记录报文

工具经过使用已暴露出多个缺点

1. 有门槛

2. JSON转JSON翻译key不支持可视化，只能自定义插件写代码，增加复杂度

3. List如果只有一个对象，XML转换JSON后变成对象 （已通过自定义插件并引入解决此问题，略微麻烦）

4. 无法指定类型如int，只能是String，如果银行方接收是其他类型，需要手动兼容处理，处理麻烦

5. 没有设计性，lua脚本的编写只是为了转换参数，且开发困难，必须了解整个链路调用才能知道变量是从哪里定义的

6. 异常处理机制不完善，无法调试，只能通过打印日志，且报错没有明确位置

7. 每个对接一个微服务，浪费资源

交易服务代码抽取

交易模式慢慢变多，交易需要的各个资源很多都耦合到了整体的common中，其实交易可以看成整体的模块，很多校验相同，外部调用相同等等，现在的问题是各个交易模式相同的代码来回拷贝，有的相同的功能不同人用不同的方式来做，一般涉及共性修改，则所有项目都要修改，可维护性比较差

抽取common-trade公共模块治理代码，统一请求减少差异性，向下兼容，打通各个交易模块的服务壁垒，减少重复性工作，增强可维护性

1. 生成交易编号封装

2. 对外部服务的调用进行封装等等，此封装不仅仅是调用，要解析提供给当前服务所需要的东西

3. 校验封装

4. 共性交易相关Bean、枚举、常量、注解定义

5. 共性交易工具类相关，如金额业务处理

6. 共性业务封装，能够确定的共性业务，否则不要封装

框架升级

升级框架，提高了框架的可维护性和安全性

大家可以看这篇文章，这是我升级整理出来的 https://blog.csdn.net/Goligory/article/details/128314051?spm=1001.2014.3001.5502

项目开发

外部港口以及区块链对接

协议转让模块，监管模块，对外对接相关对接及改造等

工作流封装以及使用

脚手架的定义及维护；

相关项目的需求开发

其他

日志中心功能包括全链路日志检索，链路追踪、图表分析，链路分析包括耗时信息等可以很快定位问题

低码平台预研：功能还可以，版本比较低，业务最终没用起来

网关服务优化对内对外接口并落地标准文档；

设计滑动窗口限流方案；

设计个性化重推方案

---

2023年

产品

1. 公共包完善：
2. 工作流封装完善
3. 接手产品仓单仓储业务；优化代码、日志以及注释，提高可读性和可维护性；解决遗留问题
4. 仓单仓储完善相关索引设计；解决相关并发问题
5. 产品仓单外部操作接口增加业务编号和合同编号并记录到日志中，提高交易与仓单的可追溯性

架构

1. 框架维护升级
2. 工作流维护升级；解决标题过长问题以及自定义标题问题
3. 用户中心升级：使用表单自定义功能嵌入自己的业务规则，提高工作流使用的扩展性；
4. 增加拦截器解决页面重复提交问题
5. MQ死信队列丢失问题预研，目前死信队列的消息没有专门处理，超过规则限制会存在丢失的情况，需要整体整理topic以及队列管理，对死信队列有专门的处理并持久化等操作
6. 数据库表索引问题：目前有一部分表没有常用索引，有些功能查询效率比较低下，最好规划预研Sql建立基础索引并优化大sql，提高查询效率，提高用户体验
7. 统一网关完善：完善对接使用文档；增加获取文件接口；增加验签方式；增加对方访问我方的接口标准；
8. 建立用户中心封装包并封装相关功能，后面需陆续在使用过程中迁移封装相关功能，易于产品管理

项目1

1. 协议转让业务随着各个版本需求完善
2. 监管功能支持
3. 工作流使用完善，结合区域，市场，是否开启审核等等进一步控制工作流节点审核的权限
4. 数据权限开发，根据不同规则进行sql路由

仓单项目

1. 接手电子仓单业务；随着各个版本需求完善，解决遗留问题
2. 代码优化，日志优化，注释优化
3. 对接区块链，解决推送的高性能以及不丢失方案，支持定时失败重推，解决线程不释放导致线程池耗尽的问题
4. 多港口港口对接代码重构，减少对接一个港口分散各处的改动，易于扩展，易于对接，对后面的对接提供了标准
5. 仓单模块逆流程开发仓单注册和仓单质押
6. 签章核心代码优化；注销、拆分、部分解质押增加签章背书
7. 支持融资需求；网关支持完善SM2加密方式，增加根据fileId获取文件外部接口
8. 多级审核（可设置人员以及顺序）

项目3

1. 接手仓储模块（此时前女友开发了一版但是没有提测），仓单模块改造，对接仓储模块，随着各个版本需求完善功能
2. 解决仓储环境部署配置问题；菜单问题；整理全量脚本
3. 仓储功能入库预约单、入库单、在库库存、货主库存、库位库存、过户预约单、过户单、提货预约单、发货单、出库单的管理以及审核等功能在原基础上全流程开发；关于库存的问题点较多也比较严谨，各个业务功能都有库存的正向以及逆向处理，解决优化
4. 仓单仓储打通：仓单的注册改造、注销、合并、转让-过户单、提货-发货单、仓管员帮货主注册、过户、提货等功能打通，并增加仓储相关审核，
5. 仓单仓储有开关控制对接仓储和不对接仓储
6. 仓储费（个性化）开发，支持指定人或市场自动初始化、自动收取
7. 仓储后台建设
8. 用乐观锁解决并发问题，完善库存相关的乐观锁判断
9. APP接口支持

仓单仓储的熟悉改造并没有降低产品的质量，在改造过程中坚持更好的设计，注意其可扩展性以及可维护性，为后面继续变动提供了好的基础

项目4

1. 撮合引擎开发
2. 基于期限、用户、部分成交标识的算法匹配；
3. 日终对账逻辑开发，以撮合为核心对委托单进行对账并通知上下游
4. 监控统计接口开发；
5. 支持其他查询等功能

业务开发总结

1. 有时急于满足客户需求没走正常流程，导致开发设计质量低下，开发和测试没有足够的自测测试时间，存在返工情况或其他风险，后面尽量沟通好确定的需求再移交开发
2. 需求以及设计文档考虑不够详细，开发过程中发现有细节业务问题，会导致返工或工时不够的情况；后面需求设计尽量有业务闭环，原型、如涉及现有系统改动需提供改动点等，不仅仅完善了文档，同时减少了开发以及测试的问题
3. 开发存在临时解决问题的情况，后面会很难维护：需要从一开始做好设计，提高开发觉悟，开发前自发组织简单的评审讨论
4. 客户推动的业务时间很有限，和第一条类似，开发人员需把关质量，且评估是否能够完成，提早暴露风险，最好减少极致压缩时间的情况，提高产品质量；同时这一条也取决于上一条的设计，如果比较灵活，那么交付效率就会更高，质量更好
5. 有个别生产问题由于升级时没有配置相关配置导致，部署需严格按照交付文档来配置，做好具体的版本管理，否则如果有的配置比较重要会有很大的业务风险；

架构开发设计为了建设产品解决客户问题，产品的建设为了快速交付，应关注研发产品以及我们业务产品，用技术赋能业务，提高客户满意度；

多会用更多的时间在架构和产品层面做出成果，帮助团队减负提效，提高交付效率，提高整个系统的扩展性，易用性，稳定性

2024年

1. 仓单项目-树结构需求和客户沟通；逆流程开发
2. 仓储服务业务需求开发；
3. 仓单服务仓库和平台审核顺序+是否需要审核的动态配置

结尾

三年时间说长不长，说短不短，很感谢现在这个公司，也感谢领导对我的重用，系统的业务复杂程度还是蛮高的，我们想方设法做产品，但是比较难的正是做产品，既不能过于灵活增加太大的复杂度，又不能个性化严重，很难快速交付，期间我们会写概设，操作手册，需求沟通，落地文档，开发进度把控，项目进度把控，测试进度，难点攻关，等等等等；后面还是需要继续磨炼技术，做一些架构选型

在此过程中发现大多数人还是只是搬砖，if，临时方案，日志混乱，注释缺失，没有流程图，没有设计文档，一旦有需求修改就要各个地方都改，影响老功能；一旦有问题一脸蒙圈，也忘记了当初的设计初衷。排除能力在外，首先需要摆正的是心态，而日志注释这些并不难

所以我们需要想一下怎么才能提高自身的效率？进而提升团队的效率，当我们有这个想法的时候，我想就不存在为了省事xxxx了，工作过程中不求一定会遇到一个伯乐领导，但是首先自己有个好的心态工作也会开心，同时遇到的问题也会变少，因为排查问题，需求扩展等等各方面都比较容易，反而不需要加班加点

祝大家好运，祝我自己好运~