在各项目组努力下，终于达成了几个目标：
1、springboot升级到2.x
2、干掉了老技术中台，全部系统对接到新技术中台，实现了技术中台统一
3、填了一波史前巨坑
今年希望达到几个目标
1、科技降本600万
2、升级k8s到1.20
3、如果时间来得及，实现动态扩缩容
4、日常，继续填历史的技术坑
1、redis调优
数据流：
数据库查询结果-》缓存到redis-》缓存使用者
表现：
bigkey一大堆，单个key存放数据3M多（你咋不把整个JVM塞到redis里去呢），redis服务器所需内存、带宽都特别高
原因：
分析后发现，之前架构确定的技术方案有问题
解决：
a、改变序列化方式，从jvm序列化，调整为protobuff，调整后，带宽瞬间大幅下降
b、减少序列化的数据内容，只保存真正需要的，调整后，redis内存大幅下架，带宽大幅下降
c、对redis进行拆分，将一个大redis，按领域拆分为多个小redis，性能提升明显
d、对于热数据不明显的低频访问场景，不缓存到redis，大家慢慢优化去吧
2、网关调优
数据流：
外网请求-》外网网关-》外网鉴权-》内网转发-》内网网关-》内网鉴权
表现：
外网网关和内网网关功能一样，而且逻辑超级复杂，性能垃圾的一塌糊涂
原因：
分析后发现，之前架构确定的技术方案有问题
解决：
a、干掉外网网关鉴权内容
b、增加外网网关黑名单过滤、访问频率限制等功能
c、外网网关性能大幅提升
3、数据流优化
数据流（大幅简化后）：
C系统-》数据中台-》逻辑加工-》H系统
Y系统-》数据中台-》逻辑加工-》H系统
H系统-》数据中台-》逻辑加工-》C系统
C系统-》数据中台-》逻辑加工-》H系统
H系统-》F系统
表现：
业务逻辑分散到各业务系统，数据来回传递多次，多个系统加工同一批数据，一旦出问题，要多个系统联查，花费很长时间才能定位到问题
原因：
分析后发现，之前架构确定的技术方案有问题
解决：
C系统-》Y系统-》H系统-》逻辑加工-》F系统
C系统-》数据中台
Y系统-》数据中台
H系统-》数据中台
在哪个环节出了问题十分清晰，用户自己都能初步定位到问题
4、数据修改请求超级多
数据流：
问题1、问题2、、、问题X-》老子就要修改数据-》提工单
表现：
数据质量差，任务都给到了IT，管理方没有管理动力，数据质量持续差，修改量逐年上升
原因：
分析后发现，各业务条线管控要求很多，不放权，与各地执行机构有轻度脱节
数据生产者，不承担数据质量差的职责，没有提升数据质量动力
总部管理部门，不承担数据质量差的职责，不清楚数据质量哪里差，没有工作重点
解决：
a、分析数据修改工单，归纳前几类修改请求
b、与业务方沟通，对分支机构可以修改的数据，将功能开放给各分支结构，定期公示修改量、业务影响程度等数据，作为总部管理部门的管理抓手
c、对于分支结构不可以修改的，开放数据修改功能给总部管理部门，进行统一管控，定期公示修改量、业务影响程度等数据，作为总部管理部门的管理抓手
d、数据质量与考核挂钩
e、数据质量快速提升，工单量大幅下降
5、降本
数据流：
应集团要求，降本压力巨大，科技承接了600万降本指标
表现：
科技方压力山大
原因：
一开始几年，没有这么大的压力，大家手都比较松，各条线都存在较大浪费，科技也是如此
最近几年，都是在之前资源上，不断的挤压资源，来满足每年业务快速增长的需要
今年，一方面业务继续快速增加，另一方面要大幅降本，压力山大
解决：
a、第一轮，运维小伙伴拉流量，无流量服务应关尽关，应下尽下，应合尽合
b、第二轮，运维小伙伴拉各类峰值，先统一砍一刀（网络、数据库、主机）
c、第三轮，运维小伙伴看账单，按账单大头，如网络、数据库、主机等逐条应用降本方案
d、第四轮，运维小伙伴看账单，对于不合理的条目逐条检视，逐个逐个扣
e、第五轮，各项目组，结合业务实际情况，各自制定降本方案，限时落地
f、第六轮，技术委员会，对于20%的关键业务进行性能优化，逐步降本
g、第七轮，在运维小伙伴推动下，实现自动扩缩容，继续降本