微服务介绍

什么微服务？

        微服务是一种经过良好架构设计的分布式架构方案，微服务架构特征：

• 单一职责：微服务拆分力度更小，每一个服务都对应唯一的业务能力，做到单一职责，避免重复业务开发。
• 面向服务：微服务需要对外暴露业务接口，实现跨服务调用。
• 隔离性强：服务调用做好隔离、容错、降级、避免出现级联问题

        微服务架构的设计主要是为了实现高内聚、低耦合。

单体架构：

简介：

        单体架构指的是将业务的所有功能集中在一个项目中开发，打成一个包部署。该架构适用于简易项目，例如：学生管理系统

优点：

• 架构相对简单
• 部署成本低

缺点：

• 耦合度高

分布式架构：

简介：

        分布式架构指的是根据业务功能对系统进行拆分，每个业务模块作为独立项目开发，称为一个服务。该架构适用于大型项目开发，例如京东、淘宝等

        例如商城项目，其中有订单模块、用户功能、商品功能、支付功能四大模块，通过分布式架构就可以按照业务拆分为四个独立的项目，每个独立的功能都作为一个项目来创建 

优点：

• 降低服务耦合
• 有利于服务升级拓展

缺点：

• 架构复杂，运维、监控、部署难度提高

微服务技术学习路线

微服务技术对比

        微服务这种方案需要技术框架来落地，全球的互联网公司都在积极尝试自己的微服务落地技术，在国内最知名的就是SpringCloud和阿里巴巴的Dubbo         

 认识 SpringCloud

         SpringCloud 是目前国内使用最广泛的微服务框架，其中集成了各种微服务功能组件（服务欧注册发现、服务远程调用、服务链路监控、统一配置管理、统一网关路由、流控、降级、保护），并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用的体验：

        SpringCloud 中文网；https://www.springcloud.cc/

SpringCloud与SpringBoot的版本兼容性关系如下：

SpringCloud版本	SpringBoot版本
2020.0.x aka llford	2.4.x
Hoxton	2.2.x，2.3.x（Starting with SR5）
Greenwich	2.1.x
Finchley	2.0.x
Edgware	1.5.x
Dalston	1.5.x

注意：版本不一致，将会导致代码报错，甚至无法启动。

服务的拆分及远程调用

服务拆分注意事项

        服务拆分，也就是一个单体架构，按照功能模块进行拆分，变成多个服务。例如：XX商城管理系统中有订单模式、用户功能、商品功能、支付功能四大模块，将这四个模块拆分位四个服务，如下图所示：

拆分前的单体架构：

拆分后的分布式结构：

        例如：现在有一个需求是查询订单，同时将订单中关联的用户信息、商品信息都获取到，传统的单体架构模式，是在订单Controller中定义一个函数去查订单，然后在订单数据获取用户id，然后再通过用户id查询用户表获取对应的用户信息。得到商品id以后，根据商品id查询商品表对应的数据，而这些功能全部都写在了订单模块中，这种做法是完全违背了微服务的原则。 

        微服务拆分的目的，就是维持单一原则，一个服务只做与自己相关的事。

        订单模块就只做订单业务，而不操作用户和商品。

在进行拆分时，需要注意以下几点

• 不用微服务，不要重复开发相同业务。
• 微服务数据独立，不要访问其它微服务的数据库。
• 微服务可以将自己的业务暴露为接口，供其它微服务远程调用。

        如果在微服务模式下， 想在操作订单时，查询到用户和商品相关的数据，这个时候就需要微服务提前将自己的业务暴露为接口，供其它微服务调用。

服务拆分Demo

项目名称为：cloud-demo

项目结构：

该示例项目所需的sql如下：

cloud-order.sql 中的数据如下： 

cloud-user.sql 中的数据如下： 

修改yml配置文件中的数据库秘密以后，分别启动OrderApplication和UserApplication两个微服务， 如下截图：

订单访问地址：http://localhost:8080/order/101

用户访问地址：http://localhost:8081/user/1

该示例项目就完全遵循微服务拆分的原则，遵循单一职责，每个服务做不同的事，并且数据库也做了分离，每个服务都有一个独立的数据库。

        目前， 该示例只是做了数据库独立和服务拆分，并没有实现微服务之间远程调用的功能，如果想实现根据订单id查询订单数据的同时，把订单所属的用户信息查询出来并返回出去，就需要完成微服务之间远程调用的功能，如下截图：

只能是在订单模块中向用户模块发起远程调用，然后将查询到的数据进行组合，返给客户端。

微服务远程调用-查询订单具体实现步骤：

1、注册RestTemplate

        在order-service的OrderApplication中注册RestTemplate 

    /**
     * 微服务之间远程调用
     * 创建RestTemplate并注入Spring容器
     * @return
     */
    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }

2、然后在OrderService中通过 RestTemplate 发送http请求，获取用户数据，组拼数据以后返回

package cn.itcast.order.service;

import cn.itcast.order.mapper.OrderMapper;
import cn.itcast.order.pojo.Order;
import cn.itcast.order.pojo.User;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.ResponseEntity;
import org.springframework.stereotype.Service;
import org.springframework.web.client.RestTemplate;

@Service
public class OrderService {

    @Autowired
    private OrderMapper orderMapper;

    @Autowired
    private RestTemplate restTemplate;

    public Order queryOrderById(Long orderId) {
        // 1.查询订单
        Order order = orderMapper.findById(orderId);

        // ================== 通过RestTemplate 发起http请求，查询用户数据
        String url = "http://localhost:8081/user/"+order.getUserId();
        /*
        getForObject 表示发送get请求，并且将返回数据封装成对象
         发送http请求，实现远程调用
         */
        User user = restTemplate.getForObject(url, User.class);

        order.setUser(user);

        // 4.返回
        return order;
    }
}

3、然后重启order-service中的OrderApplication服务，浏览器访问：http://localhost:8080/order/101         测试是否可以实现微服务之间的远程调用

示例Demo源码：https://download.csdn.net/download/qq_35366269/86937423

为什么要用微服务？

        通过微服务可以满足更高的并发需求。随着用户的增长，普通的服务已经无法满足需求， 这个时候就可以通过微服务解决这个问题。

        在实际开发过程中，需求会不断的变更，业务更新迭代快，通过微服务可以快速进行迭代开发。传统的单点式架构服务因为将所有的功能都集中，导致耦合性太强，一旦需要对其进行升级改造，就需要考虑到对其它服务的影响，所以传统单点式架构服务升级迭代的效率比较低。而微服务因为做了拆分，耦合度较低，在升级改造时就无需考虑对其它服务的影响，从而提高效率，更适合敏捷开发的需求。 

怎么使用微服务？