微服务的基本理解和使用

目录​​​​​​​

一、微服务基础知识

1、系统架构的演变

（1）单体应用架构

（2）垂直应用架构

（3）分布式SOA架构

（4）微服务架构

（5）SOA与微服务的关系

2、分布式核心知识

（1）分布式中的远程调用

        RESTful接口

        RPC协议

        区别与联系

（2）分布式中的CAP原理

3、常见微服务框架

（1）SpringCloud

（2）ServiceComb

（3）ZeroC ICE

二、SpringCloud概述

1、微服务中的相关概念

（1）服务注册与发现

（2）负载均衡

（3）熔断

（4）链路追踪

（5）API网关

2、SpringCloud的介绍

3、SpringCloud的架构

（1）SpringCloud中的核心组件

三、案例搭建

1、RestTemplate介绍

2、RestTemplate方法介绍

---

一、微服务基础知识

1、系统架构的演变

        随着互联网的发展，网站应用的规模不断扩大，常规的应用架构已无法应对，分布式服务架构以及微服务架构势在必行，必需一个治理系统确保架构有条不紊的演进。

（1）单体应用架构

        Web应用程序发展的早期，大部分web工程（包含前端页面，web层代码，service层代码，dao层代码）是将所有的功能模块，打包到一起并放在一个web容器中运行。

        比如搭建一个电商系统：客户下订单，商品展示，用户管理。这种将所有功能都部署在一个web容器中运行的系统就叫做单体架构。

        优点：

• 所有的功能集成在一个项目工程中。
• 项目架构简单，前期开发成本低，周期短，小型项目的首选。
• 全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。
• 系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。
• 技术栈受限。

（2）垂直应用架构

        当访问量主键增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。

        优点：

• 项目架构简单，前期开发成本低，周期短，小型项目的首选。
• 通过垂直拆分，原来的单体项目不至于无限扩大。
• 不同的项目可采用不同的技术。

        缺点：

• 全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。
• 系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。

（3）分布式SOA架构

        什么是SOA?

        SOA 全称为 Service-Oriented Architecture，即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。⼀个服务通常以独立的形式存在于操作系统进程中。站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通⽤的业务服务，实现业务逻辑的快速复⽤。 通过上⾯的描述可以发现 SOA 有如下几个特点：分布式、可重⽤、扩展灵活、松耦合。

        SOA架构：当垂直应用越来越多，应⽤之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应⽤能更快速的响应多变的市场需求。

        优点：

• 抽取公共的功能为服务，提高开发效率。
• 对不同的服务进行集群化部署解决系统压力。
• 基于ESB/DUBBO减少系统耦合。

        缺点：

• 抽取服务的粒度较大。
• 服务提供方与调用方接口耦合度较高。

（4）微服务架构

        优点：

• 通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队的交付周期将缩短，运维成 本也将大幅度下降。
• 微服务遵循单一原则。微服务之间采用Restful等轻量协议传输。

        缺点： 

• 微服务过多，服务治理成本高，不利于系统维护。
• 分布式系统开发的技术成本高（容错、分布式事务等）。

（5）SOA与微服务的关系

        SOA（ Service Oriented Architecture ）"面向服务的架构"：它是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。 一个服务通常以独立的形式存在与操作系统进程中。各个服务之间通过网络调用。

        微服务架构：其实和SOA 架构类似，微服务是在SOA上做的升华，微服务架构强调的一个重点是"业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。 这些小应用之间通过服务完成交互和集成。

功能	SOA	微服务
组件大小	大块业务逻辑	单独任务或小块业务逻辑
耦合	通常松耦合	总是松耦合
公司架构	任何类型	小型、专注功能交叉团队
管理	着重中央管理	着重分散管理
目标	确保应用能够交互操作	执行新功能、快速拓展开发团队

        总结：单体应用架构--->垂直应用架构--->分布式架构--->SOA架构--->微服务架构，当然还有悄然兴起的Service Mesh(服务网格化)。

2、分布式核心知识

（1）分布式中的远程调用

        在微服务架构中，通常存在多个服务之间的远程调用的需求。远程调用通常包含两个部分：序列化和通信协议。常见的序列化协议包括json、xml、 hession、 protobuf、thrift、text、 bytes等，目前主流的远程调用技术有基于HTTP的RESTful接口以及基于TCP的RPC协议。

        RESTful接口

        REST，即Representational State Transfer的缩写，如果一个架构符合REST原则，就称它为RESTful架构。

        资源（Resources）

        所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、 ⼀张图片、一首歌曲、一种服务，总之就是⼀个具体的实在。你可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。REST的名称"表现层状态转化"中，省略了主语。 "表现层"其实指的是"资源"（ Resources）的 "表现层"。

        表现层（Representation）

        "资源"是⼀种信息实体，它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式，叫做它的"表 现层"（Representation）。比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现。 URI只代表资源的实体，不代表它的形式。严格地说，有些网址最后的".html"后缀名是不必要的，因为这个后缀名表示格式，属于"表现层"范畴，而URI应该只代表"资源"的位置。

        状态转化（State Transfer ）

        访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（ State Transfer ）。 客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET⽤来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。

        综合上面的解释，我们总结一下什么是RESTful架构：

• 每一个URI代表⼀种资源；
• 客户端和服务器之间，传递这种资源的某种表现层；
• 客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。

        RPC协议

        RPC（ Remote Procedure Call ）一种进程间通信方式。允许像调用本地服务以样调用远程服务。 RPC框架的主要目标就是让远程服务调用更简单、透明。 RPC框架负责屏蔽底层的传输方式（TCP或者 UDP）、序列化方式（XML/JSON/二进制）和通信细节。开发⼈员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。

        区别与联系

比较项	RESTful	RPC
通讯协议	HTTP	一般使用TCP
性能	略低	较高
灵活度	高	低
应用	微服务架构	SOA架构

• HTTP相对更规范，更标准，更通用，无论哪种语言都支持http协议。如果你是对外开放API，例如 开放平台，外部的编程语言多种多样，你无法拒绝对每种语言的支持，现在开源中间件，基本最先支持的几个协议都包含RESTful。
• RPC 框架作为架构微服务化的基础组件，它能大大降低架构微服务化的成本，提高调用方与服务提供方的研发效率，屏蔽跨进程调用函数（服务）的各类复杂细节。让调用方感觉就像调用本地函数一样调用远端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务。

（2）分布式中的CAP原理

        现如今，对于多数大型互联网应用，分布式系统（distributed system）正变得越来越重要。分布式系统的最大难点，就是各个节点的状态如何同步。 CAP 定理是这方面的基本定理，也是理解分布式系统的起点。 CAP理论由 Eric Brewer 在ACM研讨会上提出，而后CAP被奉为分布式领域的重要理论。分布式系统的 CAP理 论，首先把分布式系统中的三个特性进行了如下归纳：

• Consistency（一致性）：数据一致更新，所有数据的变化都是同步的。
• Availability（可用性） ：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。
• Partition tolerance（分区容忍性） ：某个节点的故障，并不影响整个系统的运行。

        通过学习CAP理论，我们得知任何分布式系统只可同时满足二点，没法三者兼顾，既然一个分布式系统无法同时满足一致性、可用性、分区容错性三个特点，所以我们就需要抛弃一样：

3、常见微服务框架

（1）SpringCloud

        Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。 Spring Cloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具。

（2）ServiceComb

        Apache ServiceComb是业界第一个Apache微服务顶级项目， 是一个开源微服务解决方案,致力于帮助企业、用户和开发者将企业应用轻松微服务化上云，并实现对微服务应用的高效运维管理。其提供一站式开源微服务解决方案，融合SDK框架级、0侵入ServiceMesh场景并支持多语言。

（3）ZeroC ICE

        ZeroC lceGrid是ZeroC公司的杰作，继承了CORBA的血统，是新一代的面向对象的分布式系统中间件作为一种微服务架构，它基于RPC框架发展而来，具有良好的性能与分布式能力。

二、SpringCloud概述

1、微服务中的相关概念

（1）服务注册与发现

        服务注册：服务实例将自身服务信息注册到注册中心。这部分服务信息包括服务所在主机IP和提供服务的Port，以及暴露服务自身状态以及访问协议等信息。

        服务发现：服务实例请求注册中心获取所依赖服务信息。服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。

（2）负载均衡

        负载均衡是高可用网络基础架构的关键组件，通常用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性。

（3）熔断

        熔断这一概念来源于电子工程中的断路器(Circuit Breaker)。在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。这种牺牲局部，保全整体的措施就叫做熔断。

（4）链路追踪

        随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要对一次请求涉及的多个服务链路进行日志记录，性能监控即链路追踪。

（5）API网关

        随着微服务的不断增多，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信可能出现：

• 客户端需要调用不同的url地址，增加难度。
• 再一定的场景下，存在跨域请求的问题。
• 每个微服务都需要进行单独的身份认证。

        针对这些问题，API网关顺势而生。

        API网关直面意思是将所有API调用统一接入到API网关层，由网关层统一接入和输出。一个网关的基本功能有:统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。有了网关之后，各个API服务提供团队可以专注于自己的的业务逻辑处理，而API网关更专注于安全、流量、路由等问题。

2、SpringCloud的介绍

        Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。 Spring Cloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具了复杂的配置和实现原理。

3、SpringCloud的架构

（1）SpringCloud中的核心组件

        Spring Cloud的本质是在 Spring Boot 的基础上，增加了一堆微服务相关的规范，并对应用上下文进行了功能增强。既然 Spring Cloud 是规范，那么就需要去实现，目前Spring Cloud 规范已有 Spring官方，Spring Cloud Netfix，Spring Cloud Alibaba等实现。通过组件化的方式，Spring Cloud将这些实现整合到一起构成全家桶式的微服务技术栈。

        Spring Cloud Netflix组件：

组件名称	作用
Eureka	服务注册中心
Ribbon	客户端负载均衡
Feign	声明式服务调用
Hystrix	客户端容错保护
Zuul	API服务网关

        Spring Cloud Alibaba组件：

组件名称	作用
Nacos	服务注册中心
Sentinel	客户端容错保护

        Spring Cloud原生及其他组件：

组件	作用
Consul	服务注册中心
Config	分布式配置中心
Gateway	API服务网关
Sleuth/Zipkin	分布式链路追踪

三、案例搭建

        使用微服务架构的分布式系统，微服务之间通过网络通信。我们通过服务提供者与服务消费者来描述微服务间的调用关系。

• 服务提供者:服务的被调用方，提供调用接口的一方
• 服务消费者:服务的调用方，依赖于其他服务的一方

        我们以电商系统中常见的用户下单为例，用户向订单微服务发起一个购买的请求。在进行保存订单之前需要调用商品微服务查询当前商品库存，单价等信息。在这种场景下，订单微服务就是一个服务消费者，商品微服务就是一个服务提供者。

        具体代码实现如下：

        首先是大体框架为：

        其中common用于存在实体类对象，order用于创建订单，product用于操作产品信息，user用于操作用户信息。

        主模块中的pom文件配置了：

<modelVersion>4.0.0</modelVersion>
<groupId>com.apesource</groupId>
<artifactId>springcloud_alibaba</artifactId>
<version>1.0-SNAPSHOT</version>

        这里定义了项目的基本信息，包括groupId（组织标识符）、artifactId（项目标识符）、和version（版本号）。这些信息唯一标识了该Maven项目。

<packaging>pom</packaging>

        这个项目打包类型为pom，意味着它是一个聚合项目或父项目，用来管理多个子模块。

<modules>
    <module>shop_common</module>
    <module>shop_order</module>
    <module>shop_product</module>
    <module>shop_user</module>
</modules>

        定义了该父项目的四个子模块。

<properties>
    <java.version>1.8</java.version>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    <spring-cloud.version>Greenwich.RELEASE</spring-cloud.version>
    <spring-cloud-alibaba.version>2.1.1.RELEASE</spring-cloud-alibaba.version>
</properties>

        这里定义了一些属性，如Java版本、编码格式，以及Spring Cloud和Spring Cloud Alibaba的版本。这些属性可以在整个POM文件中复用，方便管理和升级。

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>${spring-cloud.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-alibaba-dependencies</artifactId>
            <version>${spring-cloud-alibaba.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

        在dependencyManagement部分定义了依赖管理。这里指定了Spring Cloud和Spring Cloud Alibaba的依赖项及其版本。这些依赖项不会自动应用到子项目中，子项目需要显式声明才能继承。

        首先是common模块，在domain包下创建了三个实体类用于创建存储订单、产品、用户，这里只展示订单的代码，其余代码均相同逻辑：

//订单
@TableName("shop_order")
@Data
public class Order {
    @TableId(value = "oid",type = IdType.AUTO)
    private Long oid;//订单id

    //用户
    @TableField("uid")
    private Integer uid;//用户id
    @TableField("username")
    private String username;//用户名

    //商品
    @TableField("pid")
    private Integer pid;//商品id
    @TableField("pname")
    private String pname;//商品名称
    @TableField("pprice")
    private Double pprice;//商品单价

    //数量
    @TableField("number")
    private Integer number;//购买数量
}

        通过@TableName映射shop_order数据库，其余的都是成员变量的创建和映射。

        控制器层：

// @RestController: 这个注解标记了 OrderController 作为一个 Spring MVC 控制器，它处理 Web 请求并返回 JSON 或 XML 格式的响应。
@RestController
public class OrderController {

    // 用于在服务之间发起 HTTP 请求的模板类。
    @Autowired
    private RestTemplate restTemplate;

    @Autowired
    private IOrderService orderService;

    //下单
    @RequestMapping("/order/prod/{pid}")
    public Order order(@PathVariable("pid") Integer pid) {

        //调用商品微服务,查询商品信息
        Product product =
                restTemplate.getForObject("http://localhost:8081/product/" + pid, Product.class);

        //下单(创建订单)
        Order order = new Order();
        order.setUid(1);
        order.setUsername("测试用户");
        order.setPid(pid);
        order.setPname(product.getPname());
        order.setPprice(product.getPprice());
        order.setNumber(1);
        orderService.createOrder(order);
        return order;
    }

}

        其中RestTemplate对象是用于在服务之间发起 HTTP 请求的模板类。它封装了 HTTP 请求和响应的处理逻辑，提供了一组便捷的方法来与外部 RESTful 服务进行交互。

        通过.getForObject方法，调用商品微服务，通过 HTTP GET 请求调用商品服务的接口获取商品信息。

        然后再创建order对象通过mybatis-puls提供的接口来调用创建订单的方法：

        service接口：

public interface IOrderService extends IService<Order> {

    //创建订单
    void createOrder(Order order);
}

       IService 是 MyBatis-Plus 提供的一个通用服务接口，提供了许多 CRUD（创建、读取、更新、删除）操作的默认实现方法。继承了 IService<Order> 后，IOrderService 接口就拥有了这些通用的 CRUD 功能，比如 save、remove、update、getById 等。

        service实现类：

@Service
public class OrderServiceImpl extends ServiceImpl<OrderMapper,Order> implements IOrderService {

    @Autowired(required = false)
    private OrderMapper orderMapper;

    @Override
    public void createOrder(Order order) {
        orderMapper.insert(order);
    }

}

        这个继承了ServiceImpl抽象类，是 MyBatis-Plus 提供的一个抽象类，实现了IService接口的大部分常用方法，又实现了IOrderService的接口，通过继承 ServiceImpl，OrderServiceImpl 类自动获得了所有 CRUD 方法的实现，无需手动编写这些基本操作的代码。

        OrderMappper数据访问层代码：

@Mapper
public interface OrderMapper extends BaseMapper<Order> {
}

        BaseMapper 是 MyBatis-Plus 提供的一个通用 Mapper 接口，已经实现了基本的 CRUD（创建、读取、更新、删除）操作。

        测试类主入口代码：

@SpringBootApplication
public class OrderApplication {

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

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

        因为控制器需要用到restTemplate，所以在测试类中定义了一个RestTemplate的bean。

        最后是yml文件：

server:
  port: 8091
spring:
  application:
    name: service-order
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/springwork?serverTimezone=GMT
    username: root
    password: 123456

        其中server:port代表配置Spring Boot 应用的服务器端口号。

        spring: application: name: service-order配置应用程序的名称为 service-order。这个名称在微服务架构中很重要，通常用于服务发现、注册中心（如 Nacos 或 Eureka）等场景。

        后面的是配置数据库和jdbc的连接。

        还有一个pom配置文件：

<parent>
        <artifactId>springcloud_alibaba</artifactId>
        <groupId>com.apesource</groupId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>
    <artifactId>shop_order</artifactId>

    <dependencies>
        <!--springboot-web-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <!--shop-common-->
        <dependency>
            <groupId>com.apesource</groupId>
            <artifactId>shop_common</artifactId>
            <version>1.0-SNAPSHOT</version>
        </dependency>
    </dependencies>

        这里多配置该项目的父 POM。springcloud_alibaba 是父项目的 artifactId，com.apesource 是其 groupId，版本为 1.0-SNAPSHOT。父 POM 定义了项目继承的一些全局配置，比如依赖版本、插件配置等。

        还配置了shop_common模块，里面有相关的实体类bean，可以在shop_common中使用。

        

        这里我就省略shop_product和shop_user的代码了，同时执行三个模块，通过shop_order中的restTemplate去调用地址实现获取商品信息和用户信息，最后进行下单操作。

        执行结果：

        获取后再查看数据库是否执行下单操作：

        也添加进来了，证明完成了服务的调用，但是这种写法存在硬编码的问题，比如应⽤场景有局限、无法动态调整、就需要通过注册中心动态的对服务注册和服务发现。

1、RestTemplate介绍

        刚才我们对RestTemplate在项目中进行了解释和应用，现在我们着重去解释一下这个类。

        Spring框架提供的RestTemplate类可用于在应用中调用rest服务，它简化了与http服务的通信方式，统-了RESTful的标准，封装了http链接，我们只需要传入url及返回值类型即可。相较于之前常用的HttpClient ，RestTemplate是一种更优雅的调用RESTfuI服务的方式。在Spring应用程序中访问第三方REST服务与使用Spring RestTemplate类有关。RestTemplate类的设计 原则与许多其他Spring 模板类(例如JdbcTemplate、JmsTemplate)相同，为执行复杂任务提供了一种具有默认行为的简化方法。
        RestTemplate默认依赖JDK提供http连接的能力(HttpURLConnection)，如果有需要的话也可以通过setRequestFactory方法替换为例如 Apache HttpComponents、Netty或OkHttp等其它HTTP library。考虑到RestTemplate类是为调用REST服务而设计的，因此它的主要方法与REST的基础紧密相连就不足为奇了，后者是HTTP协议的方法:HEAD、GET、POST、PUT、DELETE和OPTIONS。例如，RestTemplate类具有headForHeaders()、getForObject()、postForObject()、put()和delete()等方法。

2、RestTemplate方法介绍