拆分电商系统为微服务
背景
假设你现在是一个创业公司的 CTO,开发团队大约 30 人左右,包括 5 个前端和 25 个后端,后端开发人员全部都是 Java,现在你们准备从 0 开始做一个小程序电商业务,请你设计微服务拆分的架构以及微服务基础设施选型。
微服务拆分
拆分思路
因为是从 0 到 1 构建一个业务系统,所以选择按业务拆分微服务
因为电商业务发展的已经相当成熟,所以直接参考业界类似业务的划分方式即可
拆分过程
业务划分
参考业界类似业务划分方式,电商业务主要划分为如下几个模块:
订单中心:负责订单创建、管理,促销和优惠的计算等
会员中心:负责用户信息的管理,以及用户名下订单、优惠券、权益等的管理
店铺中心:负责店铺的日常运营、秒杀活动、优惠活动等
商品中心:负责商品分类、商品列表、商品详情页、商品检索、商品评价等业务
财务中心:负责支付相关的业务流程和财务结算
仓储物流中心:负责库存管理和物流管理
管理中心:负责系统的后台管理和数据统计
微服务划分
团队一共 25 个后端,按照三个火枪手原则,大约可以划分为 8-9 个微服务,与上述业务划分的方式比较匹配,所以采用一对一的方式,即以上 7 个业务被一对一的拆分成 7 个微服务。
团队分工
3 个人负责一个微服务,一共需要 21 人,剩余 4 人可负责微服务基础设施的建设。
系统架构图
微服务基础设施
选型原则
团队技术栈
团队技术栈单一,统一为 Java
是否需要高性能 RPC
创业初期,业务量大概率不会很大,系统的性能要求并不高,可以不需要高性能 RPC,随着业务的发展,后续可以继续演进。
最终选型
根据上述原则 1,选用嵌入式 SDK 的方式
团队技术栈一致,只写一种 SDK 即可,同时无需搭建反向代理集群或网络代理服务,而且天然支持高可用、高性能。
根据上述原则 2,最终选用 Spring Cloud
Spring 社区支持强大,更新非常快,所以开发效率高;
而且目前性能需求无需更高性能的二进制 RPC 传输,所以不用上比较重的 Dubbo。
评论