SpringCloud 微服务全栈体系（一）

第一章认识微服务

随着互联网行业的发展，对服务的要求也越来越高，服务架构也从单体架构逐渐演变为现在流行的微服务架构。这些架构之间有怎样的差别呢？

一、单体架构

单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署。

单体架构的优缺点如下：
- 优点：
  - 架构简单
  - 部署成本低
- 缺点：
  - 耦合度高（维护困难、升级困难）

二、分布式架构

分布式架构：根据业务功能对系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务。

分布式架构的优缺点：
- 优点：
  - 降低服务耦合
  - 有利于服务升级和拓展
- 缺点：
  - 服务调用关系错综复杂
分布式架构虽然降低了服务耦合，但是服务拆分时也有很多问题需要思考：
- 服务拆分的粒度如何界定？
- 服务之间如何调用？
- 服务的调用关系如何管理？
人们需要制定一套行之有效的标准来约束分布式架构。

三、微服务

微服务的架构特征：
- 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责
- 自治：团队独立、技术独立、数据独立，独立部署和交付
- 面向服务：服务提供统一标准的接口，与语言和技术无关
- 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题

微服务的上述特性其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合。
因此，可以认为微服务 是一种经过良好架构设计的分布式架构方案 。
但方案该怎么落地？选用什么样的技术栈？全球的互联网公司都在积极尝试自己的微服务落地方案。
其中在 Java 领域最引人注目的就是 SpringCloud 提供的方案了。

四、SpringCloud

SpringCloud 是目前国内外使用最广泛的微服务框架。
官网地址：https://spring.io/projects/spring-cloud。
SpringCloud 集成了各种微服务功能组件，并基于 SpringBoot 实现了这些组件的自动装配，从而提供了良好的开箱即用体验。
其中常见的组件包括：

另外，SpringCloud 底层是依赖于 SpringBoot 的，并且有版本的兼容关系，如下：

版本：Hoxton.SR10，对应的 SpringBoot 版本是 2.3.x 版本。

五、总结

单体架构：简单方便，高度耦合，扩展性差，适合小型项目。例如：学生管理系统
分布式架构：松耦合，扩展性好，但架构复杂，难度大。适合大型互联网项目，例如：京东、淘宝
微服务：一种良好的分布式架构方案

① 优点：拆分粒度更小、服务更独立、耦合度更低

② 缺点：架构非常复杂，运维、监控、部署难度提高
SpringCloud 是微服务架构的一站式解决方案，集成了各种优秀微服务功能组件

第二章服务拆分和远程调用

任何分布式架构都离不开服务的拆分，微服务也是一样。

一、服务拆分原则

微服务拆分时的几个原则：
- 不同微服务，不要重复开发相同业务
- 微服务数据独立，不要访问其它微服务的数据库
- 微服务可以将自己的业务暴露为接口，供其它微服务调用

二、服务拆分示例

以微服务 cloud-demo 为例，其结构如下：

cloud-demo：父工程，管理依赖
- order-service：订单微服务，负责订单相关业务
- user-service：用户微服务，负责用户相关业务
要求：
- 订单微服务和用户微服务都必须有各自的数据库，相互独立
- 订单服务和用户服务都对外暴露 Restful 的接口
- 订单服务如果需要查询用户信息，只能调用用户服务的 Restful 接口，不能查询用户数据库

1. 导入 Sql 语句

将cloud-order.sql和cloud-user.sql导入到 mysql 中：
（见专栏 -> 全栈资料包 -> 资源包/02_cloud）

cloud-user 表中初始数据如下：
cloud-order 表中初始数据如下：
cloud-order 表中持有 cloud-user 表中的 id 字段。

2. 导入 demo 工程

用 IDEA 导入 Demo：
（见专栏 -> 全栈资料包 -> 资源包/02_cloud ）
项目结构如下：

导入后，会在 IDEA 右下角出现弹窗：

点击弹窗，然后按下图选择：

会出现这样的菜单：

配置下项目使用的 JDK：

三、实现远程调用案例

在 order-service 服务中，有一个根据 id 查询订单的接口：

根据 id 查询订单，返回值是 Order 对象，如图：

其中的 user 为 null
在 user-service 中有一个根据 id 查询用户的接口：

查询的结果如图：

1. 案例需求

修改 order-service 中的根据 id 查询订单业务，要求在查询订单的同时，根据订单中包含的 userId 查询出用户信息，一起返回。

因此，我们需要在 order-service 中向 user-service 发起一个 http 的请求，调用 http://localhost:8081/user/{userId}这个接口。
大概的步骤是这样的：
- 注册一个 RestTemplate 的实例到 Spring 容器
- 修改 order-service 服务中的 OrderService 类中的 queryOrderById 方法，根据 Order 对象中的 userId 查询 User
- 将查询的 User 填充到 Order 对象，一起返回

2. 注册 RestTemplate

首先，我们在 order-service 服务中的 OrderApplication 启动类中，注册 RestTemplate 实例：

java 复制代码

package com.alex.order;

import org.mybatis.spring.annotation.MapperScan;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.web.client.RestTemplate;

@MapperScan("com.alex.order.mapper")
@SpringBootApplication
public class OrderApplication {

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

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

3. 实现远程调用

修改 order-service 服务中的 com.alex.order.service 包下的 OrderService 类中的 queryOrderById 方法：

四、提供者与消费者

在服务调用关系中，会有两个不同的角色：
- 服务提供者：一次业务中，被其它微服务调用的服务。（提供接口给其它微服务）
- 服务消费者：一次业务中，调用其它微服务的服务。（调用其它微服务提供的接口）

但是，服务提供者与服务消费者的角色并不是绝对的，而是相对于业务而言。
如果服务 A 调用了服务 B，而服务 B 又调用了服务 C，服务 B 的角色是什么？
- 对于 A 调用 B 的业务而言：A 是服务消费者，B 是服务提供者
- 对于 B 调用 C 的业务而言：B 是服务消费者，C 是服务提供者
因此，服务 B 既可以是服务提供者，也可以是服务消费者。

SpringCloud 微服务全栈体系（一）

第一章 认识微服务

一、单体架构

二、分布式架构

三、微服务

四、SpringCloud

五、总结

第二章 服务拆分和远程调用

一、服务拆分原则

二、服务拆分示例

1. 导入 Sql 语句

2. 导入 demo 工程

三、实现远程调用案例

1. 案例需求

2. 注册 RestTemplate

3. 实现远程调用

四、提供者与消费者

第一章认识微服务

第二章服务拆分和远程调用