基于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/s...

扩展阅读：
来听听一位『大龄程序员』的心声
如何从传统软件开发顺利过渡到互联网技术开发
学习新技术时你应当掌握的『最少必要知识』
作了七年软件开发后反而更迷茫
软技能：代码以外的生存指南
基于SpringCloud的Microservices架构实战案例