基于SpringCloud的Microservices架构实战案例-架构拆解
自第一篇《 基于SpringCloud的Microservices架构实战案例-序篇》发表出来后,差不多有半年时间了,一直也没有接着拆分完,有如读本书一样,也是需要契机的,还是要把未完成的工作做完,虽然并不是什么经典应用,还是有必要将simplemall的形成过程拆解下,也便于对此案例的理解。
服务拆分具体拆分到多细,业内没有一个统一的标准。当然也不能为了拆分而拆分,还要依据具体的业务场景应用情况而定,读过《淘宝技术这十年》的朋友,相信对淘宝的技术演进有一个很直观的感受。虽然当时微服务的概念并不今天这般火热,但实际已经在生产环境中运行。
simplemall项目的业务背景基于简单的购物场景,也即是常见的电商业务。实现完备的电商业务流程非常复杂庞大,此项目仅中拆分出基础的简单的5个基础服务,用户模块、订单模块、支付模块、产品模块、消息模块。实际的业务应用中可能拆解的更加细致,比如产品服务中还可以细分出库存、促销、价格、产品分类、推荐等等,本项目仅以最简单的服务展现,以达成简单了解并使用spring cloud组件的目的。
全部模块基于SpringBoot,采用maven进行项目管理。
项目架构结构图如下:
基础业务服务分为:
-
account-service用户子服务
-
product-service产品子服务
-
payment-service支付子服务
-
order-service订单子服务
-
msg-service消息子服务
-
front-app业务前端展示
每个业务服务有自己的单独的DB,数据存储基于mysql 5.6+,sql文件夹下面存放着基础的初始化脚本,直接执行即可。每个服务连接db的配置依本地配置为准。
基础支撑服务分为:
-
admin-server服务监控
-
conf-server配置中心
-
eureka-server服务注册中心
-
hystrix-dashborad服务熔断监控面板
-
sleuth-server链接跟踪监控
-
turbine-server服务熔断集合监控
-
zuul-server网关服务器
-
common-module基础模块
必备服务是eureka-server,用于服务注册、发现。其余基础服务模块是慢慢演变优化加入进去的。
common-module模块中存放redis的连接配置及相关模块的实体。有朋友问entity为何存储在common模块中,此种做法有利有弊。好处是所有子模块直接依赖此common模块,可以拿到所以模块相关的实体及接口,弊端是服务增多时,Java类繁多庞大,会引入很多无关代码。比较常见的做法时,每个子服务模块中独立一个api模块,存放实体及对外的api接口。如下图:
小节一下:本文介绍了simplemall项目的代码结构,重点述说了下子服务的实体及接口代码的存储,后续深入具体模块详细介绍。
源码地址:https://github.com/backkoms/simplemall
扩展阅读:
上一篇: javascript字体颜色控件的开发 JS实现字体控制
下一篇: MySql 数据库常用设置
推荐阅读
-
基于SpringCloud的Microservices架构实战案例-架构拆解
-
基于EF的一个简单实战型分层架构
-
基于Spring Boot 和Spring Cloud和Docker的微服务架构项目实战
-
基于.NET平台的分层架构实战(八)数据访问层的第二种实现:
-
基于springboot+redis+bootstrap+mysql开发一套属于自己的分布式springcloud云权限架构
-
基于.NET平台的分层架构实战(七)数据访问层的第一种实现:A
-
基于SpringCloud的Microservices架构实战案例-架构拆解
-
基于EF的一个简单实战型分层架构
-
h5深度优化实战案例:手机QQ Hybrid 的架构如何优化演进?
-
h5深度优化实战案例:手机QQ Hybrid 的架构如何优化演进?