# ximi-mall

**Repository Path**: ximidefeng/ximi-mall

## Basic Information

- **Project Name**: ximi-mall
- **Description**: 采用springcloud搭建的一个商城demo
- **Primary Language**: Java
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 2
- **Forks**: 0
- **Created**: 2022-10-30
- **Last Updated**: 2025-04-13

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# ximi-mall

## 介绍
采用springcloud搭建的一个商城demo

ximimall = Spring cloud alibaba后端 + 微信小程序用户前端 + 

后续将增加Vue管理员前端+Vue用户移动端

## 体验版

请手机扫描以下二维码访问:

![](./doc/体验版demo.jpg)

## 软件架构
软件架构说明
本项目借鉴与litemall商城项目
目前大多数项目是单体springboot架构，本项目基于springboot 进行拆分整改，改进城微服务架构，以便于项目的解耦，业务扩展，分布式部署，高可用，高并发
### 单体架构vs微服务架构
#### 单体架构

一个归档包（例如war格式）包含了应用所有功能的应用程序，我们通常称之为单体应用。架构单体应用的方法论，我们称之为单体应用架构。（就是一个war包打天下）

![](./doc/单体架构.png)

####  单体架构的优缺点

优点:
①: 架构简单明了，没有”花里胡哨“的问题需要解决。
②:开发，测试，部署简单（尤其是运维人员 睡着都会笑醒）
缺点:
①：随着业务扩展，代码越来越复杂，代码质量参差不齐(开发人员的水平不一),会让你每次提交代码 ，修改每一个小bug都是心惊胆战的。
②:  部署慢(由于单体架构，功能复杂) 能想像下一个来自200W+代码部署的速度(15分钟)
③:  扩展成本高，根据单体架构图 假设用户模块是一个CPU密集型的模块(涉及到大量的运算)，那么我们需要替换更加牛逼的CPU，而我们的订单模块是一个IO密集模块（涉及大量的读写磁盘）,那我们需要替换更加牛逼的内存以及高效的磁盘。但是我们的单体架构上 无法针对单个功能模块进行扩展，那么就需要替换更牛逼的CPU，更牛逼的内存，更牛逼的磁盘，价格蹭蹭的往上涨。
④:  阻碍了新技术的发展。。。。。。比如我们的web架构模块 从struts2迁移到springboot，那么就会成为灾难

#### 微服务架构
独立部署，灵活扩展
![](./doc/微服务.png)
资源的有效隔离
![](./doc/微服务数据库.png)
微服务架构风格是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。 这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。 这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。
SOA架构强调的是异构系统之间的通信和解耦合，而微服务架构强调的是系统按业务边界做细粒度的拆分和部署
微服务架构是一个架构风格, 提倡: 
①:将一个单一应用程序开发为一组小型服务.
②:每个服务运行在自己的进程中
③:服务之间通过轻量级的通信机制(http rest api)
④:每个服务都能够独立的部署
⑤:每个服务甚至可以拥有自己的数据库
微服务以及微服务架构的是二个完全不同的概念。微服务强调的是服务的大小和对外提供的单一功能，而微服务架构是指把 一个一个的微服务组合管理起来，对外提供一套完整的服务。

#### 微服务的优缺点
优点:
①：每个服务足够小,足够内聚，代码更加容易理解,专注一个业务功能点(对比传统应用，可能改几行代码 需要了解整个系统)
②: 开发简单，一个服务只干一个事情。（加入你做支付服务，你只要了解支付相关代码就可以了）
③: 微服务能够被2-5个人的小团队开发，提高效率
④: 按需伸缩，服务松耦合，每个服务都能够开发部署
⑤: 前后端分离, 作为java开发人员，我们只要关系后端接口的安全性以及性能，不要去关注页面的人机交互(H5工程师)根据前后端接口协议，根据入参，返回json的回参。
⑥:一个服务可用拥有自己的数据库，也可以多个服务连接同一个数据库。
缺点:
①:增加了运维人员的工作量，以前只要部署一个war包，现在可能需要部署成百上千个war包 (k8s+docker+jenkins )
②: 服务之间相互调用，增加通信成本
③:数据一致性问题(分布式事务问题)
④:性能监控等,问题定位.........................
#### 微服务的适用场景
合适
①:大型复杂的项目............(来自单体架构200W行代码的恐惧)
②:快速迭代的项目............(来自一天一版的恐惧)
③:并发高的项目................(考虑弹性伸缩扩容的恐惧)
不合适
①：业务稳定，就是修修bug ，改改数据
②：迭代周期长 发版频率 一二个月一次.

本项目就是基于微服务的思想 改进的 
最终实现的目标如下
![](./doc/ximimall商城微服务架构图.jpg)


#### 技术栈
目前使用的如下：
> 1. Spring cloud alibabab
> 2. Vue
> 3. 微信小程序
> 4. docker

未来讲持续增加 对应的分布式组件

#### 使用说明

1. 配置最小开发环境：
    * [MySQL](https://dev.mysql.com/downloads/mysql/)
    * [JDK1.8或以上](http://www.oracle.com/technetwork/java/javase/overview/index.html)
    * [Maven](https://maven.apache.org/download.cgi)
    * [Nodejs](https://nodejs.org/en/download/)
    * [微信开发者工具](https://developers.weixin.qq.com/miniprogram/dev/devtools/download.html)
    
2. 数据库依次导入db/sql下的数据库文件
    * litemall_schema.sql
    * litemall_table.sql
    * litemall_data.sql

3. 采用docker容器化安装 需要打包后编写dockerfile 用dockercompose 编排，后续将使用K8S 进行编排发布

#### 开发计划

1.  目前版本先搭建基本框架以及相应的组件
2.  实现商城所有功能点
 小商城功能

* 首页
* 专题列表、专题详情
* 分类列表、分类详情
* 品牌列表、品牌详情
* 新品首发、人气推荐
* 优惠券列表、优惠券选择
* 团购
* 搜索
* 商品详情、商品评价、商品分享
* 购物车
* 下单
* 订单列表、订单详情、订单售后
* 地址、收藏、足迹、意见反馈
* 客服