我今天拆了公司的“烂系统”,老板:你可以另谋高就了...
Python涨薪研究所
共 6518字,需浏览 14分钟
· 2021-04-11
源 /cnblog 文/ zhanlijun
本篇文章作者给大家分享一个复杂系统的拆分改造实践!
为什么要拆分?
应用间耦合严重。系统内各个应用之间不通,同样一个功能在各个应用中都有实现,后果就是改一处功能,需要同时改系统中的所有应用。 这种情况多存在于历史较长的系统,因各种原因,系统内的各个应用都形成了自己的业务小闭环。 业务扩展性差。数据模型从设计之初就只支持某一类的业务,来了新类型的业务后又得重新写代码实现,结果就是项目延期,大大影响业务的接入速度。 代码老旧,难以维护。各种随意的 if else、写死逻辑散落在应用的各个角落,处处是坑,开发维护起来战战兢兢。 系统扩展性差。系统支撑现有业务已是颤颤巍巍,不论是应用还是DB都已经无法承受业务快速发展带来的压力。 新坑越挖越多,恶性循环。不改变的话,最终的结果就是把系统做死了。
拆前准备什么?
多维度把握业务复杂度
定义边界,原则:高内聚,低耦合,单一职责
确定拆分后的应用目标
确定当前要拆分应用的架构状态
例如,代码情况、依赖状况,并推演可能的各种异常。
给自己留个锦囊,“有备无患”
放松心情,缓解压力
改造实践
DB 拆分实践
①主键 id 接入全局 id 发生器
Snowflake:非全局递增。 MySQL 新建一张表用来专门生成全局唯一 id(利用 auto_increment 功能)(全局递增)。 有人说只有一张表怎么保证高可用?那两张表好了(在两个不同 db),一张表产生奇数,一张表产生偶数。或者是 n 张表,每张表的负责的步长区间不同(非全局递增) ……
对按主键 id 排序的 SQL 要提前改造。因为 id 已经不保证递增,可能会出现乱序场景,这时候可以改造为按 gmt_create 排序。 报主键冲突问题。这里往往是代码改造不彻底或者改错造成的,比如忘记给某一 insert sql 的 id 添加 #{},导致继续使用自增,从而造成冲突。
②建新表&迁移数据&binlog 同步
cannal/otter:https://github.com/alibaba/canal?spm=5176.100239.blogcont11356.10.5eNr98
https://github.com/alibaba/otter/wiki/QuickStart?spm=5176.100239.blogcont11356.21.UYMQ17
③联表查询 SQL 改造
适合 job 类的 SQL,或改造后 RPC 查询量较少的 SQL。 不适合大数据量的实时查询 SQL。
④切库方案设计与实现(两种方案)
如果要回滚得联系 DBA 执行线上停写操作,风险高,因为有可能在业务高峰期回滚。 只有一处地方校验,出问题的概率高,回滚的概率高。
SQL 联表查询改造不完全。 SQL 联表查询改错&性能问题。 索引漏加导致性能问题。
将复杂任务分解为一系列可测小任务,步步为赢。 线上不停服,回滚容易。 字符集问题影响小。
流程步骤多,周期长。 双写造成 RT 增加。
⑤开关要写好
拆分后一致性怎么保证?
分布式事务,性能较差,几乎不考虑。 消息机制补偿(如何用消息系统避免分布式事务?) 定时任务补偿用得较多,实现最终一致,分为加数据补偿,删数据补偿两种。
应用拆分后稳定性怎么保证?
遵循接口最少暴露原则:很多同学搭建完新应用后会随手暴露很多接口,而这些接口由于没人使用而缺乏维护,很容易给以后挖坑。听到过不只一次对话,“你怎么用我这个接口啊,当时随便写的,性能很差的”。 不要让使用方做接口可以做的事情:比如你只暴露一个 getMsgById 接口,别人如果想批量调用的话,可能就直接 for 循环 RPC 调用,如果提供 getMsgListByIdList 接口就不会出现这种情况了。 避免长时间执行的接口:特别是一些老系统,一个接口背后对应的可能是 for 循环 select DB 的场景。 …
按应用优先级进行流控:不仅有总流量限流,还要区分应用,比如核心应用的配额肯定比非核心应用配额高。 业务容量控制:有些时候不仅仅是系统层面的限制,业务层面也需要限制。举个例子,对 Saas 化的一些系统来说,“你这个租户最多 1w 人使用”。
正则匹配耗 CPU 耗性能的 job 优化、降级、下线(循环调用 RPC 或SQL) 慢 SQL 优化、降级、限流 Tair/Redis、DB 调用量要可预测 例:Tair、DB
总结
推荐阅读
为什么CTO、技术总监、架构师都不写代码,还这么牛逼?
“因为你不懂技术…” 警察:???
拼多多终于被砍了一刀
一键三连「分享」、「点赞」和「在看」
技术干货与你天天见~
评论
真高!比亚迪员工爆料比亚迪在越南的薪资水平:基本工资480万,全勤奖35万,交通补助20万,餐补110万,每周6天,每天10小时
上一篇:某大公司为逼迫员工离职,竟然把他的工位安排到厕所旁,没想到他直接开始记录领导的如厕时间,还发到公司大群...对此,你怎么看?--完--PS:欢迎在留言区留下你的观点,一起讨论提高。如果今天的文章让你有新的启发,欢迎转发分享给更多人。全文完,感谢你的耐心阅读。如果你还想看到我的文章,请一定给本
开发者全社区
0
太敢穿了!透视纱裙!性感火辣的身材
绝了呀今天的厂花:吴宣仪1995年1月26日,吴宣仪出生于海南省海口市,中国内地流行乐女歌手、影视演员。2016年2月,吴宣仪随宇宙少女发行首张迷你专辑正式出道。2018年4月,她参加《创造101》综艺选秀,获得第二名,成功加入火箭少女101组合。吴宣仪的颜值一直备受称赞,她的五官立体精致,皮肤白皙
逆锋起笔
0
某大公司为逼迫员工离职,竟然把他的工位安排到厕所旁,没想到他直接开始记录领导的如厕时间,还发到公司大群...
上一篇:字节的跳动职级与薪资(2024年)我们与公司间的合作,宛如两艘船只在茫茫大海上相互依靠,共同抵御风浪,携手驶向成功的彼岸。然而,当航向开始产生分歧,或是波涛汹涌的风浪改变了我们的初衷,我们或许应当冷静地选择和平分手,而非在风雨中硬撑。最近,一位网友的遭遇引起了广大职场人的关注和热议。这位网友
开发者全社区
0
金融研究 | 使用Python测量关键审计事项的「信息含量」
Tips: 公众号推送后内容只能更改一次,且只能改20字符。如果内容出问题,或者想更新内容, 只能重复推送。为了更好的阅读体验,建议阅读本文博客版, 链接地址https://textdata.cn/blog/2023-01-13-information-content-of-critical-aud
大邓和他的Python
0
我看阿里的年终奖总算发了!
到4月底了,这两天看朋友圈,发现阿里的年终奖终于发了,问了问老同学,也从网上检索了不少信息,基本搞清楚了阿里今年的年终奖情况。近来来阿里一些集团对绩效等级做了较大的调整,以前的旧绩效系统中,绩效分为3.25、3.5、3.75、4和5五个等级,其中4和5是较高绩效等级,较少见。而且之前3.5绩效内部划
公子龙
0
CVPR 2024|大视觉模型的开山之作!无需任何语言数据即可打造大视觉模型
↑ 点击蓝字 关注极市平台作者丨科技猛兽编辑丨极市平台极市导读 本文提出一种序列建模 (sequential modeling) 的方法,不使用任何语言数据,训练大视觉模型。>>加入极市CV技术交流群,走在计算机视觉的最前沿本文目录1 序列建模打造大视觉模型(来自 U
极市平台
1
金融研究(更新) | 使用Python构建关键审计事项的「信息含量」
Tips: 公众号推送后内容只能更改一次,且只能改20字符。如果内容出问题,或者想更新内容, 只能重复推送。为了更好的阅读体验,建议阅读本文博客版, 链接地址https://textdata.cn/blog/2023-01-13-information-content-of-critical-aud
大邓和他的Python
0
字节的跳动职级与薪资(2024年)
上一篇:阿里公布年终奖,P7, 3.5+,22W年终奖,还有35W长期现金激励,真香字节跳动自2012年3月成立以来,已经迅速成长为一个全球性的科技公司。其产品和服务已经遍布全球150多个国家与地区,并且支持超过75种不同的语言。在字节跳动的官方网站上,列出了一系列引人注目的产品和服务,包括但不限于
开发者全社区
0