Spring Cloud 环境和工程基本搭建
1. 开发环境安装
1.1 JDK
1.1.1 JDK 版本介绍
Oracle 从 JDK9 开始每半年发布一个新版本,新版本发布后,老版本就不再进行维护。但是会有几个长期维护的版本。 目前长期维护的版本有:JDK8, JDK11, JDK17, JDK21。在 JDK 版本的选择上,尽量选择长期维护的版本。 为什么选择 JDK17? Spring Cloud 是基于 SpringBoot 进行开发的,SpringBoot 3.X 以下的版本,Spring 官方已不再进行维护(还可以继续使用),SpringBoot 3.X 的版本,使用的 JDK 版本基线为 JDK17。所以本文选择使用 JDK17。
2. 案例介绍
2.1 需求
实现一个电商平台(不真实实现,仅为演示)。一个电商平台包含的内容非常多,以京东为例,仅从首页上就可以看到巨多的功能。 我们该如何实现呢?如果把这些功能全部写在一个服务里,这个服务将是巨大的。巨多的会员,巨大的流量,微服务架构是最好的选择。 微服务应用开发的第一步,就是服务拆分。拆分后才能进行各自开发。
2.2 服务拆分
服务拆分原则: 微服务到底多小才算'微',这个在业界并没有明确的标准。微服务并不是越小越好,服务越小,微服务架构的优点和缺点都会越来越明显。 服务越小,微服务的独立性就会越来越高,但同时,微服务的数量也会越多,管理这些微服务的难度也会提高。所以服务拆分也要考虑场景。
还是以企业管理为例 企业中一个员工的工作内容与企业规模、项目规模等都有关系。 在小公司,一个员工可能需要负责很多部门的事情,大公司的话,一个部门的工作可能需要多个员工来处理。
拆分微服务一般遵循如下原则:
- 单一职责原则 单一职责原则原本是面向对象设计中的一个基本原则,它指的是一个类应该专注于单一功能。不要存在多于一个导致类变更的原因。在微服务架构中,一个微服务也应该只负责一个功能或业务领域,每个服务应该有清晰的定义和边界,只关注自己的特定业务领域。
- 服务自治 服务自治是指每个微服务都应该具备高度自治的能力,即每个服务要能做到独立开发,独立测试,独立构建,独立部署,独立运行。 以上面的电商系统为例,每一个微服务应该有自己的存储,配置,在进行开发、构建、部署、运行和测试时,并不需要过多关注其他微服务的状态和数据。
- 单向依赖 微服务之间需要做到单向依赖,严禁循环依赖,双向依赖。 循环依赖:A -> B -> C -> A 双向依赖:A -> B, B -> A
微服务架构并无标准架构,合适的就是最好的,不然架构师大会也不会各个系统架构百花齐放了。 在架构设计的过程中,坚持'合适优于业界领先',避免'过度设计'(为了设计而设计)。很多业界领先方案并不是一群天才在某个时期一下子做出来的,而是经过数年的发展逐步完善。业界领先的方案大多是'逼'出来的,随着业务的发展,量变导致质变,新的问题出现了,当前的方案无法满足需求,需要用新的方案来解决。通过不断的创新和尝试,业界领先的方案才得以形成。
服务拆分示例: 一个完整的电商系统是庞大的,咱们课程中重点关注如何使用 SpringCloud 解决微服务架构中遇到的问题。 以订单列表为例:订单列表需要包含的主要信息有:
- 订单列表
- 商品信息
根据服务的单一职责原则,我们把服务进行拆分为:订单服务,商品服务。 订单服务:提供订单 ID,获取订单详细信息。 商品服务:根据商品 ID,返回商品详细信息。
3. 数据准备
根据服务自治原则,每个服务都应有自己独立的数据库。
订单服务:
-- 建库
create database if not exists cloud_order charset utf8mb4;
-- 订单表
DROP TABLE IF EXISTS order_detail;
CREATE TABLE order_detail (
`id` AUTO_INCREMENT COMMENT ,
`user_id` () COMMENT ,
`product_id` () COMMENT ,
`num` () COMMENT ,
`price` () COMMENT ,
`delete_flag` TINYINT() ,
`create_time` DATETIME now(),
`update_time` DATETIME now(),
(id)
) ENGINE INNODB utf8mb4 COMMENT ;
order_detail (user_id, product_id, num, price)
(, , , ), (, , , ), (, , , ), (, , , ), (, , , ), (, , , );


