写点什么

模块 6 作业

用户头像
gevin
关注
发布于: 2 小时前

作业要求


假设你现在是一个创业公司的 CTO,开发团队大约 30 人左右,包括 5 个前端和 25 个后端,后端开发人员全部都是 Java,现在你们准备从 0 开始做一个小程序电商业务,请你设计微服务拆分的架构以及微服务基础设施选型。


  1. 需要明确服务拆分思路,并且将拆分后的系统架构图画出来;

  2. 需要明确微服务基础设施选型思路,并选择一个微服务框架;


复杂度分析

业务复杂度


由于我并不熟悉电商的业务,故直接从网上查找电商业务的分析,本文参考从「极客时间」文章中提过的一份电商业务为基础,主要的业务模块如下:



其中,

  1. 系统服务层的全部服务,业务需求相对简单,但对性能、可用性等有较高的要求,定性为业务复杂度低,质量复杂度高

  2. 共享服务层的服务,相当于业务中台,每个服务,业务流程复杂,或业务逻辑复杂,且定位是业务中台,故业务复杂度高、质量复杂度高

  3. 业务服务层,业务需求与贡献服务层类似,但业务量级相对小,团队处于创业期,业务总量级也不会大到特别离谱,且如果某个业务宕机,整体影响不会特别严重,故暂定安业务复杂度高、质量复杂度低设计

质量复杂度


上一节已对业务本身的质量复杂度做了定性分析,本节再做一点补充:


由于当前场景是创业期,从 0 到 1 初创业务过程,故业务总量不会特别大,由于业务本身的特点整体上适合采用微服务架构,而微服务架构本身比较容易扩展,故不打算在本文做业务量级的定量分析,


架构设计思路


直接使用阿里云资源,降低运维成本


系统服务层设计思路


  1. 缓存服务采用阿里云现成的 redis 集群

  2. 消息服务使用阿里云现成的 Rocket MQ(Rocket MQ 方便实现最终一致性)

  3. 存储服务直接使用阿里云的对象存储(OSS)和文件存储(NAS)

  4. 短信服务和邮件服务使用阿里云的短信机和企业邮箱,用 java sdk 封装为微服务使用和维护


共享服务层和业务服务层服务拆分思路


共享服务层的服务,基本思路是,总体先基于业务领域进行粗粒度拆分,需要进一步拆分时,再按业务的重要程度、可用性和可维护性细分


业务层服务,均从业务视角进行拆分


注:


本文的业务架构来自外部参考资料,其第一层级的业务领域拆分,并非单从业务需求角度拆分,而是考虑了非功能需求,考虑了业务的性质和层级后做的领域拆分,这应该是演化再次梳理后,由架构师提出的领域拆分,业务专家较难一步到位做出这样的领域拆分


微服务基础设施选型思路


由于后台都是 Java,且业务处于初创阶段,业务量级不会太大,用嵌入式 SDK 微服务框架即可,可以直接使用 Spring Cloud 进行微服务开发。


优先使用的微服务基础设施如下:

  • nacos

  • spring cloud gateway

  • histrix

  • Spring Cloud Sleuth

  • spring cloud stream


人力与分工


  1. 短信、邮件服务,和运维工作,由后台人员轮值维护,不再额外管理

  2. 按照本文的业务架构,可以按 1 个前端+2 个后台的方式开发每个微服务

  3. 以 Merge Request 方式合并代码,合并前做 code review,以此保证团队成员对业务和代码的熟悉和人力的备份


架构图



发布于: 2 小时前阅读数: 2
用户头像

gevin

关注

技术、生活都要折腾 2013.07.26 加入

还未添加个人简介

评论

发布
暂无评论
模块6作业