本文探讨了一体化架构在电商系统中的应用及其痛点，如数据库连接扩容、代码耦合和运维难题。提出通过微服务拆分来解决这些问题，将用户模块独立为服务，减少数据库连接压力，并实现服务下沉，增强系统稳定性和可维护性。
目录
一、场景分析
工程的部署方式还是采用一体化架构。也就是说所有的功能模块，比如电商系统中的订单模块、用户模块、支付模块、物流模块等等都被打包到一个大的Web工程中，然后部署在应用服务器上。
系统发展到一定阶段都要做微服务化的拆分，将一体化架构拆分成微服务化架构
二、一体化架构的痛点
初期优势
- 开发简单直接，代码和项目集中式管理；
- 只需要维护一个工程，节省维护系统运行的人力成本；
- 排查问题方便，只需要排查这个应用进程就可以了，目标性强。
痛点
- 数据库连接的扩容问题
- 代码冲突耦合，模块相互依赖
- 运维困难，构建编译部署缓慢
- 出现问题导致应用整体不可用
二、如何使用微服务拆分
无论哪个业务池子用户模块都是请求量最大的模块儿，用户库也是请求量最大的数据库。这很好理解，无论是内容还是互动都会查询用户库获取用户数据，所以虽然我们做了业务池的拆分，但实际上每一个业务池子都需要连接用户库并且请求量都很大，这就造成了用户库的连接数比其它都要多一些，容易成为系统的瓶颈。
解决方式
按照业务做横向拆分，可以把与用户相关的逻辑部署成一个单独的服务，其它无论是用户池、内容池还是互动池都连接这个服务来获取和更改用户信息，也就是说只有这个服务可以连接用户库，其它的业务池都不直连用户库获取数据
将与业务无关的公用服务抽取出来，下沉成单独的服务。每一个服务的功能内聚，维护人员职责明确，增加了新的功能只需要测试自己的服务就可以了，而一旦服务出了问题，也可以通过服务熔断、降级的方式减少对于其他服务的影响
扫一扫
1307
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
