Spring Cloud（一）初识微服务和Spring Cloud

微服务

微服务是分布式架构的一种，而分布式架构的作用就是把服务作拆分，而拆分的过程中会产生各种各样的问题需要取解决，Spring Cloud解决了服务拆分时的服务治理问题，对于其他分布式其他更复杂的问题并没有给出解决方案。因此，一个完整的微服务技术包含的不仅仅是Spring Cloud。

微服务技术栈

微服务的作用就是拆分，对于一个单体架构，所有的业务都写在一起，随着业务越来越复杂，代码也耦合的越来越多，要对其升级维护十分困难。微服务在做拆分的时候，会根据业务功能模块把一个单体的项目拆分成许多个独立的项目，每个项目完成一部分业务功能，将来独立开发和部署。我们称这些独立的项目为服务，一个大型的互联网项目包含成百甚至上千个服务，最终形成一个服务集群。

注册中心

一个业务往往由多个服务共同来完成，当业务越来越多，服务之间的调用关系就会越来越复杂，想要靠人来记录和维护是不太现实的，所以在微服务里有组件来解决这个问题——即注册中心。它可以记录每一个服务的IP、端口以及做什么操作的信息，当有一个服务需要去调用另外一个服务时，无需知道另一个服务的端口、IP，只需去注册中心拉取对应的服务信息。

配置中心

随着服务的越来越多，服务所对应的配置文件也越来越多。当我们需要对配置进行修改时，就得对配置文件逐一进行修改，这显然太麻烦了，微服务替我们想到了这一点，提供了配置中心这一组件，它可以去管理整个服务集群里成千上百的配置。如果需要对配置进行变更，只需要找到配置中心，它会去通知相关的微服务实现配置的热更新。

服务网关

服务网关一方面校验用户的身份，一方面可以将用户的请求路由到具体的服务，在路由的过程中也可以做负载均衡。

分布式缓存 + 数据库

服务接收到请求后去处理业务，需要访问数据库的时候去访问数据库，再将查询到的数据返回给用户。数据库虽然也是集群但难以抗住高并发的情况，因此需要引入分布式缓存，将热点数据放在缓存中，当用户请求时先查询缓存，若缓存未命中再查询数据库。

分布式搜索

业务中还存在一些复杂的搜索功能，简单查询可以使用缓存，但一些海量数据复杂的搜索和分析，缓存也无能为力。这时我们就需要用到分布式搜索，数据库只用来做一些写操作，和事务类型对数据安全要求较高的数据存储。

消息队列

分布式服务里一个业务往往会跨越多个维度，比如服务A去调用服务B，服务B又去调用服务C······整个业务的链路会很长，调用时长会等于每个服务的执行时长之和。这对性能是有一定的下降的，我们使用消息队列来进行异步通信，此时服务A执行时会通知服务B，服务A不用等待服务B执行完即可结束，业务链路变短了，响应时间也缩短了，吞吐能力也大大增加。所以异步通信能大大提高服务的并发，在秒杀等场景下有着重要的作用。

分布式日志服务 + 系统监控链路追踪

当项目中出现了问题，想排查错误是十分困难的。所以在微服务运行过程中，会引入两个组件：分布式日志服务和系统监控链路追踪，去解决服务的异常定位。

分布式日志服务可以去统计整个集群当中成千上百的服务的运行日志，统一的做一些存储，统计和分析，出现的问题的时候就比较好定位。

系统监控链路追踪可以去实时监控整个集群中每一个节点的运行状态和CPU负载，内存的占用等等情况，一旦出现了任何的问题，直接可以定位到具体的方法和栈信息，即可定位到异常所在了。

持续集成

微服务集群还需要做一些自动化的部署，我们可以利用Jenkins对微服务项目进行编译，基于docker再去做一些打包，形成镜像。再基于kubernetes或RANCHER做自动化的部署。

微服务架构的演变

单体架构

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

优点：

• 架构简单
• 部署成本低

缺点：

• 耦合度高

分布式架构

根据业务功能对系统进行拆分，每个业务模块作为独立项目开发，称为一个服务。

优点：

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

分布式架构需要考虑如下问题：

1. 服务拆分粒度如何？
2. 服务集群地址如何维护？
3. 服务之间如何实现远程调用？
4. 服务健康状态如何感知？

微服务

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

1. 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责，避免重复业务开发。
2. 面向服务：微服务对外暴露业务接口。
3. 自治：团队独立、技术独立、数据独立、部署独立。
4. 隔离性强：服务调用做好隔离、容错、降级、避免出现级联问题。

微服务技术对比

Spring Cloud

Spring Cloud是目前国内使用最广泛的微服务框架。官网地址：https://spring.io/projects/spring-cloud

Spring Cloud集成了各种微服务功能组件，并基于Spring Boot实现了这些组件的自动装配，从而提供了良好的开箱即用体验。

服务拆分

服务拆分注意事项：

1. 单一职责：不同微服务，不要重复开发相同的业务。
2. 数据独立：不要访问其他微服务的数据库。
3. 面向服务：将自己的业务暴露为接口，供其他微服务调用。

远程调用

需求：根据订单id查询订单的同时，把订单所属的用户信息一起返回。

步骤：

注册RestTemplate

@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }

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

服务远程调用RestTemplate

@Service
public class OrderService {
    @Autowired
    private OrderMapper orderMapper;

    @Autowired
    private RestTemplate restTemplate;

    public Order queryOrderById(Long orderId) {
        // 1.查询订单
        Order order = orderMapper.findById(orderId);
        // 2.得到user信息
        String url = "http://localhost:8081/user/" + order.getUserId();
        User user = restTemplate.getForObject(url, User.class);
        // 3.将user信息进行封装
        order.setUser(user);
        // 4.返回
        return order;
    }
}

提供者和消费者

服务提供者：一次业务中，被其它微服务调用的服务。（提供接口给其他微服务）

服务消费者：一次业务中，调用其它微服务的服务。（调用其他微服务提供的接口）

提供者和消费者角色是相对的，一个服务既可以是提供者也可以是消费者。