简单总结下吧，我算是业务架构师，确实对得起这个名字，经常冲在一线，业务和架构相关的东西都有做，系统比较复杂，不过逐步了解谁都会熟悉的
下面简单列一列我这三年的工作情况吧，也算是给自己一个交代，不全，但大体就这些了
2021年
业务系统熟悉，技术框架熟悉
参与交易模式开发
2022年
工作流改造
工作流支持前台用户的参与：（原设计只能后台进行审核，前台用户也无法审核参与）
-
兼容老工作流使用
-
重新封装接口，前端使用组件不用变化
-
支持后台审核
-
支持前台用户程序调用提交
-
支持动态指定下一个审核人
-
支持接口调用流转节点
-
支持新增审核节点，可跳过业务，只做多节点的审核动作，无需更改代码
-
支持业务审核记录的查看追踪
-
支持审核过程中动态传递变量供决策等操作；支持多条线决策
容器化的搭建
功能能够给用户建立完整的系统，可通过运维平台查看操作相关功能，包括节点管理，容器组管理，容器管理工作负载，存储，配置等等，同时可部署常用的组件。
制作dockerfile，编写maven脚本打包安装包、镜像包推送到远程仓库
docker命令熟悉以及使用
可视化对接转化工具使用
一个公司的工具，比如对接银行时的报文不用写代码，像低码一样进行转化处理，弊端颇多，后来我封装了common包进行优化，定义规范，使调用方方便，使工具开发简洁，支持原来不支持的功能，记录报文
工具经过使用已暴露出多个缺点
-
有门槛
-
JSON转JSON翻译key不支持可视化，只能自定义插件写代码，增加复杂度
-
List如果只有一个对象，XML转换JSON后变成对象 （已通过自定义插件并引入解决此问题，略微麻烦）
-
无法指定类型如int，只能是String，如果银行方接收是其他类型，需要手动兼容处理，处理麻烦
-
没有设计性，lua脚本的编写只是为了转换参数，且开发困难，必须了解整个链路调用才能知道变量是从哪里定义的
-
异常处理机制不完善，无法调试，只能通过打印日志，且报错没有明确位置
-
每个对接一个微服务，浪费资源
交易服务代码抽取
交易模式慢慢变多，交易需要的各个资源很多都耦合到了整体的common中，其实交易可以看成整体的模块，很多校验相同，外部调用相同等等，现在的问题是各个交易模式相同的代码来回拷贝，有的相同的功能不同人用不同的方式来做，一般涉及共性修改，则所有项目都要修改，可维护性比较差
抽取common-trade公共模块治理代码，统一请求减少差异性，向下兼容，打通各个交易模块的服务壁垒，减少重复性工作，增强可维护性
-
生成交易编号封装
-
对外部服务的调用进行封装等等，此封装不仅仅是调用，要解析提供给当前服务所需要的东西
-
校验封装
-
共性交易相关Bean、枚举、常量、注解定义
-
共性交易工具类相关，如金额业务处理
-
共性业务封装，能够确定的共性业务，否则不要封装
框架升级
升级框架，提高了框架的可维护性和安全性
大家可以看这篇文章，这是我升级整理出来的 https://blog.csdn.net/Goligory/article/details/128314051?spm=1001.2014.3001.5502
项目开发
外部港口以及区块链对接
协议转让模块，监管模块，对外对接相关对接及改造等
工作流封装以及使用
脚手架的定义及维护；
相关项目的需求开发
其他
日志中心功能包括全链路日志检索，链路追踪、图表分析，链路分析包括耗时信息等可以很快定位问题
低码平台预研：功能还可以，版本比较低，业务最终没用起来
网关服务优化对内对外接口并落地标准文档；
设计滑动窗口限流方案；
设计个性化重推方案
2023年
产品
- 公共包完善：
- 工作流封装完善
- 接手产品仓单仓储业务；优化代码、日志以及注释，提高可读性和可维护性；解决遗留问题
- 仓单仓储完善相关索引设计；解决相关并发问题
- 产品仓单外部操作接口增加业务编号和合同编号并记录到日志中，提高交易与仓单的可追溯性
架构
- 框架维护升级
- 工作流维护升级；解决标题过长问题以及自定义标题问题
- 用户中心升级：使用表单自定义功能嵌入自己的业务规则，提高工作流使用的扩展性；
- 增加拦截器解决页面重复提交问题
- MQ死信队列丢失问题预研，目前死信队列的消息没有专门处理，超过规则限制会存在丢失的情况，需要整体整理topic以及队列管理，对死信队列有专门的处理并持久化等操作
- 数据库表索引问题：目前有一部分表没有常用索引，有些功能查询效率比较低下，最好规划预研Sql建立基础索引并优化大sql，提高查询效率，提高用户体验
- 统一网关完善：完善对接使用文档；增加获取文件接口；增加验签方式；增加对方访问我方的接口标准；
- 建立用户中心封装包并封装相关功能，后面需陆续在使用过程中迁移封装相关功能，易于产品管理
项目1
- 协议转让业务随着各个版本需求完善
- 监管功能支持
- 工作流使用完善，结合区域，市场，是否开启审核等等进一步控制工作流节点审核的权限
- 数据权限开发，根据不同规则进行sql路由
仓单项目
- 接手电子仓单业务；随着各个版本需求完善，解决遗留问题
- 代码优化，日志优化，注释优化
- 对接区块链，解决推送的高性能以及不丢失方案，支持定时失败重推，解决线程不释放导致线程池耗尽的问题
- 多港口港口对接代码重构，减少对接一个港口分散各处的改动，易于扩展，易于对接，对后面的对接提供了标准
- 仓单模块逆流程开发仓单注册和仓单质押
- 签章核心代码优化；注销、拆分、部分解质押增加签章背书
- 支持融资需求；网关支持完善SM2加密方式，增加根据fileId获取文件外部接口
- 多级审核（可设置人员以及顺序）
项目3
- 接手仓储模块（此时前女友开发了一版但是没有提测），仓单模块改造，对接仓储模块，随着各个版本需求完善功能
- 解决仓储环境部署配置问题；菜单问题；整理全量脚本
- 仓储功能入库预约单、入库单、在库库存、货主库存、库位库存、过户预约单、过户单、提货预约单、发货单、出库单的管理以及审核等功能在原基础上全流程开发；关于库存的问题点较多也比较严谨，各个业务功能都有库存的正向以及逆向处理，解决优化
- 仓单仓储打通：仓单的注册改造、注销、合并、转让-过户单、提货-发货单、仓管员帮货主注册、过户、提货等功能打通，并增加仓储相关审核，
- 仓单仓储有开关控制对接仓储和不对接仓储
- 仓储费（个性化）开发，支持指定人或市场自动初始化、自动收取
- 仓储后台建设
- 用乐观锁解决并发问题，完善库存相关的乐观锁判断
- APP接口支持
仓单仓储的熟悉改造并没有降低产品的质量，在改造过程中坚持更好的设计，注意其可扩展性以及可维护性，为后面继续变动提供了好的基础
项目4
- 撮合引擎开发
- 基于期限、用户、部分成交标识的算法匹配；
- 日终对账逻辑开发，以撮合为核心对委托单进行对账并通知上下游
- 监控统计接口开发；
- 支持其他查询等功能
业务开发总结
- 有时急于满足客户需求没走正常流程，导致开发设计质量低下，开发和测试没有足够的自测测试时间，存在返工情况或其他风险，后面尽量沟通好确定的需求再移交开发
- 需求以及设计文档考虑不够详细，开发过程中发现有细节业务问题，会导致返工或工时不够的情况；后面需求设计尽量有业务闭环，原型、如涉及现有系统改动需提供改动点等，不仅仅完善了文档，同时减少了开发以及测试的问题
- 开发存在临时解决问题的情况，后面会很难维护：需要从一开始做好设计，提高开发觉悟，开发前自发组织简单的评审讨论
- 客户推动的业务时间很有限，和第一条类似，开发人员需把关质量，且评估是否能够完成，提早暴露风险，最好减少极致压缩时间的情况，提高产品质量；同时这一条也取决于上一条的设计，如果比较灵活，那么交付效率就会更高，质量更好
- 有个别生产问题由于升级时没有配置相关配置导致，部署需严格按照交付文档来配置，做好具体的版本管理，否则如果有的配置比较重要会有很大的业务风险；
架构开发设计为了建设产品解决客户问题，产品的建设为了快速交付，应关注研发产品以及我们业务产品，用技术赋能业务，提高客户满意度；
多会用更多的时间在架构和产品层面做出成果，帮助团队减负提效，提高交付效率，提高整个系统的扩展性，易用性，稳定性
2024年
- 仓单项目-树结构需求和客户沟通；逆流程开发
- 仓储服务业务需求开发；
- 仓单服务仓库和平台审核顺序+是否需要审核的动态配置
结尾
三年时间说长不长，说短不短，很感谢现在这个公司，也感谢领导对我的重用，系统的业务复杂程度还是蛮高的，我们想方设法做产品，但是比较难的正是做产品，既不能过于灵活增加太大的复杂度，又不能个性化严重，很难快速交付，期间我们会写概设，操作手册，需求沟通，落地文档，开发进度把控，项目进度把控，测试进度，难点攻关，等等等等；后面还是需要继续磨炼技术，做一些架构选型
在此过程中发现大多数人还是只是搬砖，if，临时方案，日志混乱，注释缺失，没有流程图，没有设计文档，一旦有需求修改就要各个地方都改，影响老功能；一旦有问题一脸蒙圈，也忘记了当初的设计初衷。排除能力在外，首先需要摆正的是心态，而日志注释这些并不难
所以我们需要想一下怎么才能提高自身的效率？进而提升团队的效率，当我们有这个想法的时候，我想就不存在为了省事xxxx了，工作过程中不求一定会遇到一个伯乐领导，但是首先自己有个好的心态工作也会开心，同时遇到的问题也会变少，因为排查问题，需求扩展等等各方面都比较容易，反而不需要加班加点
祝大家好运，祝我自己好运~
)
 PySpark SQL 简介)
