微服务性能调优02

在各项目组努力下,终于达成了几个目标:
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、第七轮,在运维小伙伴推动下,实现自动扩缩容,继续降本

Leave a Reply

Your email address will not be published. Required fields are marked *

*