建手机网站的平台,网站制作软件安卓版,物流网站毕业设计论文,2023近期舆情热点事件简单总结下吧#xff0c;我算是业务架构师#xff0c;确实对得起这个名字#xff0c;经常冲在一线#xff0c;业务和架构相关的东西都有做#xff0c;系统比较复杂#xff0c;不过逐步了解谁都会熟悉的 下面简单列一列我这三年的工作情况吧#xff0c;也算是给自己一个交…简单总结下吧我算是业务架构师确实对得起这个名字经常冲在一线业务和架构相关的东西都有做系统比较复杂不过逐步了解谁都会熟悉的 下面简单列一列我这三年的工作情况吧也算是给自己一个交代不全但大体就这些了
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?spm1001.2014.3001.5502
项目开发
外部港口以及区块链对接
协议转让模块监管模块对外对接相关对接及改造等
工作流封装以及使用
脚手架的定义及维护
相关项目的需求开发
其他
日志中心功能包括全链路日志检索链路追踪、图表分析链路分析包括耗时信息等可以很快定位问题
低码平台预研功能还可以版本比较低业务最终没用起来
网关服务优化对内对外接口并落地标准文档
设计滑动窗口限流方案
设计个性化重推方案 2023年
产品
公共包完善工作流封装完善接手产品仓单仓储业务优化代码、日志以及注释提高可读性和可维护性解决遗留问题仓单仓储完善相关索引设计解决相关并发问题产品仓单外部操作接口增加业务编号和合同编号并记录到日志中提高交易与仓单的可追溯性
架构
框架维护升级工作流维护升级解决标题过长问题以及自定义标题问题用户中心升级使用表单自定义功能嵌入自己的业务规则提高工作流使用的扩展性增加拦截器解决页面重复提交问题MQ死信队列丢失问题预研目前死信队列的消息没有专门处理超过规则限制会存在丢失的情况需要整体整理topic以及队列管理对死信队列有专门的处理并持久化等操作数据库表索引问题目前有一部分表没有常用索引有些功能查询效率比较低下最好规划预研Sql建立基础索引并优化大sql提高查询效率提高用户体验统一网关完善完善对接使用文档增加获取文件接口增加验签方式增加对方访问我方的接口标准建立用户中心封装包并封装相关功能后面需陆续在使用过程中迁移封装相关功能易于产品管理
项目1
协议转让业务随着各个版本需求完善监管功能支持工作流使用完善结合区域市场是否开启审核等等进一步控制工作流节点审核的权限数据权限开发根据不同规则进行sql路由
仓单项目
接手电子仓单业务随着各个版本需求完善解决遗留问题代码优化日志优化注释优化对接区块链解决推送的高性能以及不丢失方案支持定时失败重推解决线程不释放导致线程池耗尽的问题多港口港口对接代码重构减少对接一个港口分散各处的改动易于扩展易于对接对后面的对接提供了标准仓单模块逆流程开发仓单注册和仓单质押签章核心代码优化注销、拆分、部分解质押增加签章背书支持融资需求网关支持完善SM2加密方式增加根据fileId获取文件外部接口多级审核可设置人员以及顺序
项目3
接手仓储模块此时前女友开发了一版但是没有提测仓单模块改造对接仓储模块随着各个版本需求完善功能解决仓储环境部署配置问题菜单问题整理全量脚本仓储功能入库预约单、入库单、在库库存、货主库存、库位库存、过户预约单、过户单、提货预约单、发货单、出库单的管理以及审核等功能在原基础上全流程开发关于库存的问题点较多也比较严谨各个业务功能都有库存的正向以及逆向处理解决优化仓单仓储打通仓单的注册改造、注销、合并、转让-过户单、提货-发货单、仓管员帮货主注册、过户、提货等功能打通并增加仓储相关审核仓单仓储有开关控制对接仓储和不对接仓储仓储费个性化开发支持指定人或市场自动初始化、自动收取仓储后台建设用乐观锁解决并发问题完善库存相关的乐观锁判断APP接口支持
仓单仓储的熟悉改造并没有降低产品的质量在改造过程中坚持更好的设计注意其可扩展性以及可维护性为后面继续变动提供了好的基础
项目4
撮合引擎开发基于期限、用户、部分成交标识的算法匹配日终对账逻辑开发以撮合为核心对委托单进行对账并通知上下游监控统计接口开发支持其他查询等功能
业务开发总结
有时急于满足客户需求没走正常流程导致开发设计质量低下开发和测试没有足够的自测测试时间存在返工情况或其他风险后面尽量沟通好确定的需求再移交开发需求以及设计文档考虑不够详细开发过程中发现有细节业务问题会导致返工或工时不够的情况后面需求设计尽量有业务闭环原型、如涉及现有系统改动需提供改动点等不仅仅完善了文档同时减少了开发以及测试的问题开发存在临时解决问题的情况后面会很难维护需要从一开始做好设计提高开发觉悟开发前自发组织简单的评审讨论客户推动的业务时间很有限和第一条类似开发人员需把关质量且评估是否能够完成提早暴露风险最好减少极致压缩时间的情况提高产品质量同时这一条也取决于上一条的设计如果比较灵活那么交付效率就会更高质量更好有个别生产问题由于升级时没有配置相关配置导致部署需严格按照交付文档来配置做好具体的版本管理否则如果有的配置比较重要会有很大的业务风险
架构开发设计为了建设产品解决客户问题产品的建设为了快速交付应关注研发产品以及我们业务产品用技术赋能业务提高客户满意度
多会用更多的时间在架构和产品层面做出成果帮助团队减负提效提高交付效率提高整个系统的扩展性易用性稳定性
2024年
仓单项目-树结构需求和客户沟通逆流程开发仓储服务业务需求开发仓单服务仓库和平台审核顺序是否需要审核的动态配置
结尾
三年时间说长不长说短不短很感谢现在这个公司也感谢领导对我的重用系统的业务复杂程度还是蛮高的我们想方设法做产品但是比较难的正是做产品既不能过于灵活增加太大的复杂度又不能个性化严重很难快速交付期间我们会写概设操作手册需求沟通落地文档开发进度把控项目进度把控测试进度难点攻关等等等等后面还是需要继续磨炼技术做一些架构选型
在此过程中发现大多数人还是只是搬砖if临时方案日志混乱注释缺失没有流程图没有设计文档一旦有需求修改就要各个地方都改影响老功能一旦有问题一脸蒙圈也忘记了当初的设计初衷。排除能力在外首先需要摆正的是心态而日志注释这些并不难
所以我们需要想一下怎么才能提高自身的效率进而提升团队的效率当我们有这个想法的时候我想就不存在为了省事xxxx了工作过程中不求一定会遇到一个伯乐领导但是首先自己有个好的心态工作也会开心同时遇到的问题也会变少因为排查问题需求扩展等等各方面都比较容易反而不需要加班加点
祝大家好运祝我自己好运~
