Spring Cloud环境和工程基本搭建过程

一、开发环境安装

聊到微服务开发，环境的准备是绕不开的第一步。这里先把基础环境搭好，后面的组件演示才能顺利展开。

1. JDK环境

1.1. JDK版本选择

从JDK 9开始，Oracle的版本策略就走上了快车道——每半年一个大版本，旧版翻篇翻得比翻书还快。当然，这里面有几个“钉子户”是长期维护的，分别为JDK 8、11、17和21。选版本时，优先盯住这几个就好。

为什么这次选择JDK 17？

原因很直接：Spring Cloud是基于Spring Boot构建的。Spring Boot 3.x以下的版本官方已停止维护（虽然还能用），而3.x版本已经把JDK基线定在了17。所以，跟着官方节奏走，JDK 17是最稳妥的选择。

2. 案例介绍

2.1. 需求

这次我们拿一个电商平台来举例——注意，只是演示，不会真去实现全部功能。一个成熟电商平台的复杂程度，光看京东首页就能感受一二。

这么庞大的系统，怎么下手？如果所有功能都堆在一个服务里，那这个服务的体量会变得难以承受——海量会员、高并发流量，微服务架构几乎是唯一的选择。

而微服务应用开发的第一步，就是服务拆分。拆分完成，才能进行各自的独立开发。

2.2. 服务拆分原则

一个问题经常被问到：微服务到底拆到多小才算“微”？

业界其实没有标准答案。服务越小，独立性越强，但同时服务数量也越多，管理复杂度随之上升。所以，拆分要结合实际场景来权衡。

这就像一个公司：小公司里一个员工可能身兼多职，大公司里一个岗位可能需要多人协作。场景不同，组织方式就不同。

通常情况下，拆分微服务可以遵循这几个原则：

• 单一职责原则
  这个原则原本来自面向对象设计——一个类应该只负责一个功能。放到微服务里同样适用：每个服务只负责一个明确的业务领域，有自己的边界和定义。
• 服务自治
  每个微服务都应该能独立开发、测试、构建、部署和运行。拿电商系统来说，每个服务要有自己的存储、自己的配置，不需要过多关注其他服务的数据和状态。
• 单向依赖
  服务之间必须单向依赖，严禁循环依赖（A→B→C→A）和双向依赖（A→B，B→A）。

微服务架构没有统一标准，合适才是最好的。不然每年的架构师大会，也不会出现那么多风格迥异的方案。在架构设计时，坚持“合适优于业界领先”，避免为了设计而设计。很多所谓的“领先方案”并不是凭空诞生的，而是在业务发展的过程中，问题积累到一定程度，量变引发质变后，才被“逼”出来的。

来看一个具体的拆分示例：

一个完整的电商系统很庞大，但我们的重点在于演示Spring Cloud如何解决微服务中的问题。以订单列表为例，它通常需要包含订单信息和商品信息。

按单一职责原则，我们可以把服务拆分为：

• 订单服务：根据订单ID获取订单详情
• 商品服务：根据商品ID获取商品详情

3. 数据准备

根据服务自治原则，每个服务都应该有自己的独立数据库。

订单服务数据库：

-- 建库
create database if not exists cloud_order charset utf8mb4;
-- 订单表
DROP TABLE IF EXISTS order_detail;
CREATE TABLE order_detail (
 `id` INT NOT NULL AUTO_INCREMENT COMMENT '订单id',
 `user_id` BIGINT ( 20 ) NOT NULL COMMENT '用户ID',
 `product_id` BIGINT ( 20 ) NULL COMMENT '产品id',
 `num` INT ( 10 ) NULL DEFAULT 0 COMMENT '下单数量',
 `price` BIGINT ( 20 ) NOT NULL COMMENT '实付款',
 `delete_flag` TINYINT ( 4 ) NULL DEFAULT 0,
 `create_time` DATETIME DEFAULT now(),
 `update_time` DATETIME DEFAULT now(),
PRIMARY KEY ( id )) ENGINE = INNODB DEFAULT CHARACTER
SET = utf8mb4 COMMENT = '订单表';
-- 数据初始化
insert into order_detail (user_id,product_id,num,price)
values(2001, 1001,1,99), (2002, 1002,1,30), (2001, 1003,1,40),
(2003, 1004,3,58), (2004, 1005,7,85), (2005, 1006,7,94);

商品服务数据库：

create database if not exists cloud_product charset utf8mb4;
-- 产品表
DROP TABLE IF EXISTS product_detail;
CREATE TABLE product_detail (
 `id` INT NOT NULL AUTO_INCREMENT COMMENT '产品id',
 `product_name` varchar ( 128 ) NULL COMMENT '产品名称',
 `product_price` BIGINT ( 20 ) NOT NULL COMMENT '产品价格',
 `state` TINYINT ( 4 ) NULL DEFAULT 0 COMMENT '产品状态 0-有效 1-下架',
 `create_time` DATETIME DEFAULT now(),
 `update_time` DATETIME DEFAULT now(),
PRIMARY KEY ( id )) ENGINE = INNODB DEFAULT CHARACTER
SET = utf8mb4 COMMENT = '产品表';
-- 数据初始化
insert into product_detail (id, product_name,product_price,state)
values
(1001,"T恤", 101, 0), (1002, "短袖",30, 0), (1003, "短裤",44, 0), 
(1004, "卫衣",58, 0), (1005, "马甲",98, 0),(1006,"羽绒服", 101, 0), 
(1007, "冲锋衣",30, 0), (1008, "袜子",44, 0), (1009, "鞋子",58, 0),
(10010, "毛衣",98, 0)

4. 工程搭建

4.1. 构建父子工程

4.1.1. 创建父工程

首先，创建一个空的Ma ven项目，只保留pom.xml文件。

目录结构如下：

然后完善pom文件。用properties统一管理版本号，用dependencyManagement管理依赖声明，并将父工程的打包方式设为pom。

4.0.0
org.example
spring-cloud-demo
pom
1.0-SNAPSHOT

    org.springframework.boot
    spring-boot-starter-parent
    3.1.6
     


    17
    17
    17
    3.0.3
    8.0.33
    2022.0.3


    
        org.projectlombok
        lombok
        true
    


    
        
            org.springframework.cloud
            spring-cloud-dependencies
            ${spring-cloud.version}
            pom
            import
        
        
            org.mybatis.spring.boot
            mybatis-spring-boot-starter
            ${mybatis.version}
        
        
            com.mysql
            mysql-connector-j
            ${mysql.version}
        
        
            org.mybatis.spring.boot
            mybatis-spring-boot-starter-test
            ${mybatis.version}
            test
        
    

这里需要区分一下dependencies和dependencyManagement：

dependencies是直接引入依赖，子项目会继承。而dependencyManagement只是声明依赖，并不实际引入jar包。子项目需要用到时，显式声明即可，版本号可以从父工程继承；如果子项目指定了版本，则以子项目为准。另外，父工程的打包方式必须声明为pom。

4.1.2. 创建子项目——订单服务

操作步骤如下图所示：

声明依赖和构建插件：

    org.springframework.boot
    spring-boot-starter-web


    com.mysql
    mysql-connector-j


    org.mybatis.spring.boot
    mybatis-spring-boot-starter




    
        org.springframework.boot
        spring-boot-ma ven-plugin
    

4.1.3. 创建子项目——商品服务

创建模块的步骤同上。依赖和插件声明也基本一致：

    org.springframework.boot
    spring-boot-starter-web


    com.mysql
    mysql-connector-j


    org.mybatis.spring.boot
    mybatis-spring-boot-starter




    
        org.springframework.boot
        spring-boot-ma ven-plugin
    

4.2. 完善订单服务

4.2.1. 启动类与配置文件

启动类：

@SpringBootApplication
public class OrderServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderServiceApplication.class, args);
    }
}

配置文件：

server:
 port: 8080
spring:
 datasource:
 url: jdbc:mysql://127.0.0.1:3306/cloud_order?characterEncoding=utf8&useSSL=false
 username: root
 password: root
 driver-class-name: com.mysql.cj.jdbc.Driver
mybatis:
 configuration:
  log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
  map-underscore-to-camel-case: true

4.2.2. 业务代码

实体类：

@Data
public class OrderInfo {
 private Integer id;
 private Integer userId;
 private Integer productId;
 private Integer num;
 private Integer price;
 private Integer deleteFlag;
 private Date createTime;
 private Date updateTime;
}

Controller：

@RequestMapping("/order")
@RestController
public class OrderController {
    @Autowired
    private OrderService orderService;
    @RequestMapping("/{orderId}")
    public OrderInfo getOrderById(@PathVariable("orderId") Integer orderId){
        return orderService.selectOrderById(orderId);
    }
}

Service：

@Service
public class OrderService {
    @Autowired
    private OrderMapper orderMapper;
    public OrderInfo selectOrderById(Integer orderId) {
        OrderInfo orderInfo = orderMapper.selectOrderById(orderId);
        return orderInfo;
    }
}

Mapper：

@Mapper
public interface OrderMapper {
    @Select("select * from order_detail where id=#{orderId}")
    OrderInfo selectOrderById(Integer orderId);
}

商品服务的代码逻辑类似，这里不再重复展示。

4.3. 远程调用

4.3.1. 需求

当根据订单ID查询订单时，还需要根据订单中的商品ID获取商品的详细信息。

4.3.2. 实现

实现思路很直接：订单服务向商品服务发送一个HTTP请求，拿到返回结果后，与订单数据合并，再返回给调用方。

具体实现采用Spring提供的RestTemplate。

1. 定义RestTemplate：

@Configuration
public class BeanConfig {
    @Bean
    public RestTemplate restTemplate(){
        return new RestTemplate();
    }
}

2. 修改OrderService：

@Service
public class OrderService {
    @Autowired
    private OrderMapper orderMapper;
    @Autowired
    private RestTemplate restTemplate;
    public OrderInfo selectOrderById(Integer orderId) {
        OrderInfo orderInfo = orderMapper.selectOrderById(orderId);
        String url = "http://127.0.0.1:9090/product/"+
                orderInfo.getProductId();
        ProductInfo productInfo = restTemplate.getForObject(url,
                ProductInfo.class);
        orderInfo.setProductInfo(productInfo);
        return orderInfo;
    }
}

5. RestTemplate

RestTemplate从Spring 3.0就开始支持了，是一个同步的REST API客户端，封装了常见的HTTP请求模版。

先来说说REST是啥。

REST（Representational State Transfer），直译是“表现层资源状态转移”。它是HTTP协议主要设计者提出的一种软件架构风格，核心概念有三个：

1. 资源：网络上的所有事物都可以抽象为资源，每个资源有唯一的URI。
2. 表现层：资源的表现形式。文本可以用txt、HTML、XML或JSON等方式展现，甚至可以是二进制格式。
3. 状态转移：客户端与服务器通过URI交互，使用HTTP协议作为手段。过程中可能涉及数据状态的改变，比如增删改查。

简单来说，REST描述的是网络中客户端与服务器的一种交互形式。它本身并不“实用”，实用的是如何设计RESTful API——即符合REST风格的网络接口。

RESTful API的特征大致包括：

• 资源：可以是图片、音视频或JSON等网络实体。普通文本资源多以JSON为载体。
• 统一接口：对资源的操作（获取、创建、修改、删除）对应HTTP的GET、POST、PUT、DELETE。也就是说，从RESTful接口上看，你只能定位到资源，但具体操作需要通过HTTP方法来区分。比如同一个URL：
  GET /blog/{blogId} 查询博客
  DELETE /blog/{blogId} 删除博客

RestTemplate正是Spring封装HTTP调用、强制使用RESTful风格的工具。它自动处理连接的建立和关闭，使用者只需要提供资源地址和参数即可。

RESTful实践

RESTful风格的API规范固然好，但现实中，大多数互联网公司并没有严格按它来设计。原因在于，REST是一种风格，不是约束或规则，过于理想化的实现成本太高。

RESTful API的缺点：

1. 操作方式不够直观。GET、POST、PUT、DELETE这些方法无法直接看到，需要抓包才能确认。如果把动作写在URL里，反而更直观。
2. 部分浏览器对GET和POST之外的请求支持不友好，需要额外处理。
3. 过分强调资源。实际业务复杂，增删改查并不总能满足所有场景。强行使用RESTful会增加开发难度。

所以，实际开发中，如果业务需求与RESTful风格不匹配，不必强求。规范是为人服务的，不是反过来——尽信规范，不如无规范。

6. 项目存在的问题

把前面的工程跑起来，你可能会发现几个明显的问题：

• 远程调用时，URL里的IP和端口是写死的（比如http://127.0.0.1:9090/product/）。一旦IP变了，代码就得改。调用方能不能不依赖服务提供方的IP？
• 如果服务多机部署，如何分摊压力？
• URL容易写错，而且复用性不高。有没有更优雅的远程调用方式？
• 所有服务都能调用这个接口，是否存在安全风险？

除了这些，微服务架构中还有不少经典问题。接下来的系列文章，会逐步介绍Spring Cloud如何一一解决它们。

二、总结

以上内容主要完成了Spring Cloud系列后续组件所需的基础工程搭建，同时也引出了Spring Cloud可以解决的实际工程问题。有了这个基础，后续的组件演示就有了落脚点。