2023 回顾

技术债务

师生通

2023 年初，师生通频繁出现系统无法正常提供服务，不稳定情况。对原有的系统部署情况和硬件运行情况进行了综合的评估，发现整个公司的机房服务存在以下的情况：

• 1、部分硬件存在使用年限较久，内存小，磁盘小，占用机柜空间
• 2、师生通本地存储空间基本用完，存在清理清理，继续将就使用的情况
• 3、整体服务器利用率较低底，直接硬件上安装操作系统，不够灵活
• 4、数据库磁盘性能较低，高峰期间磁盘读写IO较高
• 5、系统服务全部单节点部署，缺少容灾方案

因此，在 2023年 1-2 月份期间，进行了公司生产环境服务迁移与集群推进的工作，工作成果如下：

• 1、梳理清楚了，机房的各个机器的规格和状况，并登记照册以便查找
• 2、迁移师生通服务使用的本地存储到MinIO对象存储，旧存储服务不再新增内容，并与后期进行了部分旧存储空间释放，解决了师生通因存储不足导致的写入和访问问题
• 3、复用旧机器降低成本同时获得足够虚拟机资源，更换新存储提高性能
  • 3.1、通过更换内存和存储的方式，成功的利用机房的已有的物理机改造出2台高配物理机
    • 1台R740xd物理机：192G(16Gx12), 40T (8Tx6 RAID 6)
    • 1台R750物理机：192G(32Gx6), 36T (8Tx6 RAID 6)
  • 3.2、通过采用“腾笼换鸟”，腾挪出5台旧型号（R630、R720）的物理机，并全部虚拟化
• 4、采购1台专用存储（20THDD、16T SSD），替换掉师生通旧数据库磁盘，极大的提高了师生通数据库的性能和稳定性
• 5、完成了师生通，棒小孩、幼儿报告单、等服务的双节点部署，有效的保障了服务的稳定性
• 6、搭建完成机房内的各主机、网络、服务的监控平台，实现对机器状况的监控预警

报告单

3月份份开始，在新版成长档案系统的持续开发中的发现，存在以下几点较为严重的问题：

• 1、因后端开发人员对微服务不熟练，成长档案没按照初期既定的服务架构进行开发设计
• 2、因后端开发人员能力问题不足，编写的代码逻辑不清晰，代码性能较差
• 3、高性能的报告单生成有一点的难度，一时间，前端无法解决这个问题
• 4、部署方式原始，也存在单节点部故障风险，没有可靠的支撑环境
• 5、六月份多所学校开始定制报告单，因报告单技术方案问题导致定制工作量较大，消耗了大量的研发资源
• 6、同时还存在逻辑不够严谨引发的数据覆盖丢失问题，产生很不好的影响
• 7、大量的报告单生成下载需求，对服务器CPU和带宽都产生了很大的压力，甚至对其他内网服务造成影响

因此，在2023年3月份至今，对报告单系统进行了框架更新与系统重构的工作，工作成果如下：

• 1、调整团队成员，安排资深开发介入，技术团队重新讨论确定提高报告单输出效率的技术方案，并在2-3个月内完成重构优化
• 2、借助人工智能，完成基于 Nodejs 技术方案生成报告单PDF功能
• 3、完成 MySQL 数据库、Redis 缓存、RocketMQ 等服务等集群部署并在报告单应用，为报告单服务提供了性能支持
• 4、报告单服务全部采用K8s容器化部署后，均按需进行了多个Pod部署，并能实现服务的弹性扩容
• 5、新团对完成以“少量投入即可支持较多学校”为目标的报告单技术方案讨论和逻辑实现，并支撑年底学校的报告单需求
• 6、改进报告单PDF生成方案，新增排队机制，使用Java技术方案，充分利用Java的多线程和线程池技术，有效的控制了服务端对资源的消耗
• 7、大胆创新，使用了客户端生成告单生PDF，将报告单PDF生成的资源消耗分散到客户的电脑主机，极大的提高了报告单生成的效率以及大规模推广的可行性

综合评价

6月份开始，在对综合评价系统原系统进行全面的了解后发现，存在以下几点较为严重的问题：

• 1、部署方式原始，版本更新迭代维护不便，效率较低
• 2、系统使用技术框架陈旧，存在安全漏洞
• 3、与师生通一样，也存在单节点部故障风险
• 4、多处接口性能较差，且难易确定原因
• 5、点评与活动的核心逻辑复杂，耦合比较严重
• 6、最为严重的是缺少权限体系，导致系统很容易被越权

因此，在 2023年6月份至今，除了业务需求的开发，还进行了框架更新与系统优化的工作，工作成果如下：

• 1、完成综合评价部署方式从普通方式切换到K8s容器化方式，提高升级维护效率和异常排查效率
• 2、智慧校园（含综合评价）共计14个后端服务，全部完成与局端项目和报告单项目统一的技术框架的整合迁移
• 3、完成 RabbitMQ 集群部署，综合评价全部切换到集群版的 MySQL 数据库、Redis 缓存、RabbitMQ 服务
• 4、智慧校园（含综合评价）全部服务采用K8s容器化部署后，均按需进行了多个Pod部署，并能实现服务的弹性扩容
• 5、对各个接口从虚拟机、数据库索引、数据缓存、业务逻辑做了一波优化，使得接口平均响应速度得到较好的提升
• 6、从并发、缓存、逻辑微调三个方向对点评与活动的核心逻辑进行优化，性能有较多的提升，但因逻辑复杂还无法做到快速响应，有待在新版本中重写此逻辑
• 7、完成一套通用权限体系的框架整合，需要在新版中进行业务逻辑整合，以便解耦前端逻辑

规范债务

开发流程

2022年时，随着工作的推进，局校产品共同梳理了“项目管理流程”，而在工作的过程中执行比较好的是局端部门。局端逐渐建立了较好的开发流程规范，并形成习惯。校端这块在研发这块相对欠缺。
2023年为了更好的指导团队有序的进行生产工作，我们进一步的在原有的“项目管理流程”下明确了 “项目协助流程” 和 “版本发布流程”。并在工作中不管的宣讲和检查，并且有了较好的成效。
通过 “项目协助流程” 和 “版本发布流程” 有效的规范开发的行为，减少了出错的几率，提高了发版的速度。

开发规范

查看天音以前项目的代码，随处可见代码不规范之处，为了提高代码规范，一边宣传规范要求，也一边通过Codding 代码检查工具检查代码不规范之处，目前历史中存在大量注释不完善，编码不规范之处，后期将继续通过Codding 平台加强管控力度，不断强化规范执行效果。

特别值得说的是，目前统一了局端和校端的技术框架，目前除综合评价老服务无法完成统一，所有的新Java服务全部采用统一的技术框架。

• 1、建立了统一的基础技术脚手架 tianyin-boot，统一异常处理，统一返回给前端的结构，统一基础继承对象，统一三方依赖关系
• 2、建立了统一的基础服务脚手架 tianyin-cloud，抽象公共的认证授权、日志记录、短信发送、文件存储、服务初始化等模块，提高通用功能的复用，特别是用户体系
• 3、通过对后端开发的规范宣讲，开发也逐步建立统一的认知，
• 4、为了规范得以不断的传承，我们还建立了公司自己的知识库来记录各个产品的实施流程和部署方式

Git 规范

在2022年明确了 Git 的规范要求，并形成书面文档。在此之前，代码分支命名混乱，合并流程比较缺失，经常出现合并冲突，或者因为不规范导致的后面版本覆盖掉前面已经处理好的功能。
经过 2022年在局端明确规范要求，到2023年在局端和校端都进行宣传执行，目前局校两端在维护的项目Git分支管理基本都比较规范。

运维债务

在天音的这2年，渐渐的发现天音存在的一些比较严重的运维问题：

• 1、资源浪费严重，无主资源较多，不用资源未及时关停
• 2、开发可随意访问公司私有云服务器，而没有安全机制
• 3、缺少完善的运维环境监控平台
• 4、没有防火墙，网络处于裸奔状态，长期至于网络安全之下

为此，在2023年里，我们在运维方便付出了大量的精力，逐渐补充天音缺少的运维空白，工作成果如下：

• 1、对现有的所有资源进行梳理，了解清楚机房的各个机器的规格和状况，明确业务和归属，关停不用的主机
• 2、搭建堡垒机，为开发单独分配账号，方便回收管理
• 3、K8s容器按项目创建子管理员，分割管理权限，给到开发有限的管理权限
• 4、不断完善运维环境监控平台，实现 虚拟机、K8s容器、数据库、中间件、微服务 的各种监控
• 5、搭建链路追踪平台，有效的监控服务请求过程，提高服务状态的可观测性以及查找问题的效率
• 6、购买的深信服防火墙，上了防火墙后才知道，我们的系统每天被那么多的恶意请求扫描和攻击

运维是一个持续而漫长的工作，需要不断的完善和优化，2023年还有以下不足，期望 2024 早日完成。

• 1、江建斌在时，那时期的演示服务，正式服务等，100多个G的资源，尚未得到释放
• 2、林斌斌在时，搭建的Haddop大数据占用的机器因为还给校端做了CRM的统计，还需迁移功能和释放资源

2024 我们还需还上，综合评价过去的技术债务，整合成长档案，共创新篇章！