从为什么要重构到微服务架构.pdf
版权申诉
111 浏览量
2022-12-17
15:09:54
上传
评论
收藏 469KB PDF 举报
从为什么要重构到微服务架构
公司决定将支付业务从原来所在部门剥离出来，成为一个独立的团队，以应付迅速发展的
业务需求。原团队负责支付系统开发的几位同学转到现团队，形成开发班底。此后开始招聘，三
个月团队扩充到 10 多个人。与此同时，公司业务也在快速发展，6 月份宣布会员突破 2 千万。
一些热片上映往往也会引发会员注册缴费的小高峰。其他业务，包括直播，阅读，动漫等，也都
进入了发展的快车道。每天订单量早已经超过百万，比去年某片上映时把系统打垮时还早高。移
动端每个月发布一个版本，桌面则是半个月。产品经理们夜以继日地规划各种功能，待开发功能
都排到好几个月之后。而随着项目团队的日益扩大，却出现一些奇怪的事情：
开发效率和以前没有太大区别，尽管队伍扩大了 4 倍多，人员素质则有所提升。
大部分开发工作还是几位老员工在忙，新员工还比较难介入核心开发工作。
除了管理因素，作为工程师，我们还是期待从技术上找到根源所在，解决问题，提高效率。
最终的决策，是使用微服务架构来重构现有系统。这一系列博文，描述在这过程中我们做的选择、
取得的成果、走过的弯路，以及经验教训。
一、原有架构
从技术角度看，原有系统是一个基于 SSH 架构的传统实现，软件架构整体上是大家所熟知
的多层 Java 软件架构：
代码让人看的非常怀旧，虽然开发人员和我说是 4 年前开发的，但这熟悉的 SSH 架构，可
是妥妥 10 年前的东西。使用 Apache Struts 做展示层，对数据访问层做个简单封装实现业务逻
辑层，基于 Spring 的 AOP 以及 Hibernate 实现数据访问。 数据保存在 MySQL 中，单库多表的
结构。
二、架构问题
1. DAO 层
资源评论
