微服务架构解决方案介绍

1、微服务架构

目前微服务是非常火的架构或者说概念，也是在构建大型互联网项目时采用的架构方式。

1.1 单体架构

在软件设计中，经常提及和使用经典的3层模型，即表示层、业务逻辑层和数据访问层。

·表示层：用于直接和用户交互，也称为交互层，通常是网页、UI 等。

·业务逻辑层：即业务逻辑处理层，例如用户输入的信息要经过业务逻辑层的处理后，才能展现给用户。

·数据访问层：用于操作数据库，用户在表示层会产生大量的数据，通过数据访问层对数据库进行读写操作。

虽然在软件设计中划分了经典的3层模型，但是对业务场景没有划分。一个典型的单体应用就是将所有的业务场景的表示层、业务逻辑层和数据访问层放在一个工程中，最终经过编译、打包，部署在一台服务器上。

单体架构图如下所示：

1.1.1 单体架构的优点

·部署简单由于是完整的结构体，可以直接部署在一个服务器上即可。

·技术单一 项目不需要复杂的技术栈，往往一套熟悉的技术栈就可以完成开发。

·用人成本低 单个程序员可以完成业务接口到数据库的整个流程。
 

1.1.2 单体架构的缺点

系统启动慢 , 一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动、重启时间周期过长

系统错误隔离性差、可用性差，任何一个模块的错误均可能造成整个系统的宕机

·可伸缩性差;系统的扩容只能只对这个应用进行扩容，不能做到对某个功能点进行扩容

·线上问题修复周期长;任何一个线上问题修复需要对整个应用系统进行全面升级
 

1.2 微服务架构

就目前来看微服务并没有一个 严格 的定义 每一个人对 微服务 的理解都是不一样的 . Martin Fowler在它的博客中是这样表述微服务的

博客地址 : https://martinfowler.com/articles/microservices.html

微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法每一个服务运行在自己的进程中服务间通信采用的轻量级通信机制通（常用HTTP 资源 API ). 这些服务围绕业务能力构建并且可通过全自动部署机制独立部署这些服务公用一个最小型的集中式的管理服务可用不同的语言开发，使用不同的数据存储技术。

微服务架构架构如如下图所示下图所示:

1.2.1 微服务微服务的的优点优点

·易于开发和维护:一个微服务只会关注一个特定的业务功能,所以它业务清晰、代码量少。开发和维护单个微服务相当简单。而整个应用是若干个微服务构建而成的，所以整个应用也被维持在一个可控状态。

·单个微服务启动较快 单个微服务代码量较少，所以启动会比较快。

·局部修改容易部署：单个应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。

·技术栈不受限：在微服务架构中，可以结合项目业务及团队的特点，合理选择技术栈。例如某些服务可以使用关系型数据库Mysql有些服务。可以使用非关系型数据库如redis;甚至可根据需求，部分微服务使用Java开发，部分微服务使用Node.js开发。

·按需收缩可根据需求，实现细粒度的扩展。例如，系统中的某个微服务遇到了瓶颈，可以结合这个微服务的业务特点，增加内存、升级CPU或者增加节点。

1.2.2 微服务的缺点

·运维要求较高： 更多的服务意味着更多的运维投入。在单体架构中，只需要保证一个应用的正常运行。而在微服务中，需要保证几十甚至几百个服务正常运行与协作，这给运维带来了很大的挑战。

·分布式固有的复杂性：使用微服务构建的是分布式 系统。对于一个分布式系统，系统容错、网络延迟等都会带来巨大的挑战。

·接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务 API ，可能所有使用该接口的微服务都需要调整。

2、Spring Cloud 简介

2.1 简介

Spring Cloud项目的官方网址： https://projects.spring.io/spring-cloud/

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

2.2 子项目介绍

2.3 Spring Cloud的版本介绍

当我们通过搜索引擎查找一些Spring Cloud 的文章或者示例的时候往往可以在依赖中看到很多不同版本的名字 , 比如 : Angel.SR6, Brixton.SR5等。 那么，为什么 Spring Cloud 没有像其他的 Spring 的项目使用类似1.x.x 版本命名规则呢?

由于Spring Cloud不像Spring社区其他项目那样相对独立，它是拥有诸多子项目的大型综合项目。可以说是对微服务架构解决方案的综合套件的组合，起包含的各个子项目也都是进行独立的更新和迭代，各自都维护自己的发布版本号。因此，每一个Spring Cloud的版本都会包含多个不同版本的子项目，为了管理每一个版本的子项目清单避免Spring Cloud的版本号与其子项目的版本号相混淆，没有采用版本号的方式，而是通过命名的方式。

我们也可以在spring的官网上查看到对应的最新稳定版本信息 : Spring Cloud

并且也可以看到最新Edgware.SR4稳定版对应的子项目的各个版本号。

关于Spring Cloud的历史版本信息我们可以在github上查看到 : https://github.com/spring-cloud/spring-cloud/release/releases

我们本次讲解的是最新的稳定版本Edgware.SR4 ,是基于Spring Boot 1.5.14.RELEASE版本实现的。

3、Spring Boot 实现微服务

在正式学习Spring Cloud 之前我们先使用Spring Boot实现一个微服务。

业务非常简单：

1、商品微服务：通过商品id 查询商品的服务；

2、订单微服务：通过订单id 查询订单数据，同时需要调用商品微服务查询出订单详情数据对应的商品数据。

说明：

1、对于商品微服务而言，商品微服务是服务的提供者，订单微服务是服务的消费者

2、对于订单微服务而言，订单微服务是服务的提供者，人是服务的消费者。

3.1 实现商品微服务

3.1.1 pom .xml文件的配置

3.1.2 创建实体Item

3.1.3 编写ItemService

3.1.4 编写ItemController

3.1.5 程序入口

3.1.6 创建配置文件

在src/main/resources目录下创建一个application.properties配置文件在该文件中可以配置如下内容

server.port=8081

指定服务启动占用的端口

3.1.7 启动项目进行访问

3.2 实现订单微服务

3.2.1 pom.xml文件的配置

3.2.2 创建实体Order

3.2.3 创建实体OrderDetail

3.2.4 复制Item实体

3.2.5 编写OrderService

该Service实现的根据订单Id查询订单的服务，为了方便测试，我们将构造数据实现，不采用查询数据库的方式。

3.2.6 实现ItemService

3.2.7 完善OrderService

3.2.8 编写OrderController

3.2.9 编写启动类

3.2.10 创建配置文件

在src/main/resources 目录下创建一个application.properties 配置文件在该文件中可以配置如下内容

server.port=8082

3.2.11 启动测试

3.3 发现问题与解决问题

3.3.1 问题描述

·在刚才的服务调用过程中我们的商品服务地址是直接写死在程序中存在硬编码问题

·如果商品微服务部署了多个，那么我们订单微服务如何去调用呢？

3.3.2 问题处理

关于硬编码的问题我们可以使用配置文件处理，我们可以将地址信息编写到配置文件中然后读取配置文件获取请求地址信息。

在配置文件中加入如下配置：

itcast.item.url=http://127.0.0.1:8081/item/

修改ItemService的实现通过@Value 注解获取该值

2. 如果商品微服务部署了多个那么我们订单微服务如何去调用呢?

关于这个问题有的开发人员可能会想 . 我们可以将多个商品微服务的地址配置到配置文件中，然后在进行读取配置文件的地址进行调用听起来好像可以，但是我们需要考虑以后问题就是后期维护的问题。

·如果商品微服务的我们又添加或者减少了一个部署，相应的我们需要去更改配置文件的内容;

·如果商品微服务的ip地址发送了改变，那么我们也需要相应的修改配置文件的地址。

所以我们自己这样实现比较麻烦。

我们可以使用服务注册于发现机制来完成。

4 Spring Cloud快速入门

服务注册于发现机制架构图如下：

由上图可以看出：

1、服务提供者将服务注册到注册中心

2、服务消费者通过注册中心查找服务

3、查找到服务后进行调用(这里就是无需硬编码 url 的解决方案)

4.1 注册中心 Eureka

Spring Cloud提供了多种注册中心的支持，如： Eureka 、 ZooKeeper 等。推荐使用Eureka 。

Spring Cloud Eureka是Spring Cloud Netflix 微服务套件中的一部分，它基于Netflix Eureka做了二次封装。主要负责完成微服务架构中的服务治理功能。

原理如下图所示

Eureka包含两个组件： Eureka Server 和 Eureka Client 。

Eureka Server 提供服务注册服务，各个节点启动后，会在 Eureka Server中进行注册，这样 EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。

Eureka Client是一个java 客户端，用于简化与 Eureka Server的交互在应用启动后，将会向Eureka Server发送心跳默认周期为 30 秒，如果 Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除默认 90 秒 。

Eureka Server之间通过复制的方式完成数据的同步，Eureka还提供了客户端缓存机制，即使所有的Eureka Server都挂掉，客户端依然可以利用缓存中的信息消费其他服务的 API 。综上，Eureka通过心跳检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性。

4.2 编写Eureka Server

4.2.1 pom.xml

启动类

4.2.3 配置文件

4.2.4 启动程序访问服务端

访问地址 : http://localhost:6868/

4.3 商品微服务注册到注册中心

接下来，我们需要将商品的微服务注册到Eureka服务中。

4.3.1 修改pom文件

引入Spring Cloud的管理依赖以及Eureka服务依赖。

4.3.2 修改配置文件

4.3.3 修改启动类

import org.springframework.boot.SpringApplication;

import org.springframework.boot.autoconfigure.SpringBootApplication;

import org.springframework.cloud.client.discovery.EnableDiscoveryClient;

@EnableDiscoveryClient     // 声明这是 Eureka 的客户端

@SpringBootApplication     // 声明这是一个 Spring Boot 项目

public class ItemApplication {

    public static void main(String[] args) {

        SpringApplication.run(ItemApplication.class, args);

    }

}

4.3.4 启动商品微服务

至此我们就已经将商品微服务注册到Eureka注册中心了

4.4 订单系统从Eureka中发现服务

4.4.1 修改pom.xml

之前我们在订单系统中是将商品微服务的地址进行了硬编码，现在，由于已经将商品服务注册到Eureka中，所以，只需要从Eureka中发现服务即可。引入Spring Cloud 的管理依赖以及Eureka服务依赖。

4.4.2 修改配置文件

4.4.3 修改ItemService

4.4.4 修改启动

4.4.5 启动测试

响应的数据如下:

可以看到以及获取到数据，但是，我们发现响应的数据变成了xml结构。

4.4.6 解决响应变成xml的问题

由于我们引入了eureka server的依赖，导致破坏了之前SpringMVC默认的配置，从而导致了响应成了xml 。

解决方法：排除eureka server中的xml依赖，如下：

测试

4.5     Eureka详解

4.5.1    为Eureka添加用户认证

在前面的示例中，我们可以看到我们需要登录即可访问到Eureka服务，这样其实是不安全的。

接下来，我们为Eureka添加用户认证。

为itcast microservice eureka添加安全认证依赖

在application.properties配置文件中添加如下内容

开启http basic的登录方式

# security.basic.enable= true

# 配置用户账号信息

security.user.name= itcast

security.user.password= itcast123

重启 Eureka服务端测试

4.5.2 服务注册和发现设置账号

http://USER:[email protected]:6868/eureka/

配置如下:

eureka.client.serviceUrl.defaultZone=http://itcast:itcast123 @127.0.0.1:6868/

4.5.3 Eureka的自我保护模式

大家有的时候在访问Eureka服务端的时候会出现红色的提示信息这个就是Eureka的自我保护模式。

默认情况下,如何Eureka Server在一定时间内没有接收到某一个微服务实例的心跳,Eureka Server将会注销该实例(默认是90秒). 但是这种行为是不安全的, 因为有的时候监听不到客户端的心跳,有可能是因为网络故障导致的,而并非是服务本身出现了问题,服务本身是健康的.这么草率的将服务注销是不安全的。

Eureka通过“自我保护模式”来解决个问题当Eureka Server节点在短时间内丢失过多的客户端时可能发生了网络分区故障),那么，这个节点就会进入自我保护模式 一旦进入该模式,Eureka Server就会保护服务注册表红的信息不在删除服务注册表中的数据，也就，不会注销任何的微服务。当网络故障恢复后该Eureka Server节点会自动退出自我保护模式。

综上自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有的微服务（健康的微服务和不健康的微服务），也不盲目注销任何健康的微服务，使用自我保护模式,可以让Eureka集群更加的健壮稳定，默认。

Eureka自我保护模式是开启的，无需处理。如果，需要禁用自我保护模式，只需要在配置文件中添加配置即可：

# 禁用eureka的自我保护模式

eureka.server.enable self preservation=false

但是当我们禁用了自我保护模式以后，在此访问Eureka Server的时候又出现了一个新的错误。

意思是：现在我们禁用了自我保护模式会带来一些不安全的问题。

因此一般情况下我们都是开启自我保护模式的。

4.5.4 Eureka的高可用

前面的测试，我们会发现，Eureka服务是一个单点服务，在生产环境就会出现单点故障，为了确保Eureka服务的高可用，我需要搭建Eureka服务的集群。

搭建Eureka集群非常简单，只要启动多个Eureka服务并且让这些服务之间彼此进行注册即可实现。

修改itcast microservice eureka的application.properties配置文件

修改配置文件的内容 再启动一个Eureka Server

启动两个Eureka Server 看结果

可以看到，2个Eureka服务进行了彼此注册

4.5.5 将服务注册到 Eureka集群中

修改配置文件

eureka.client.serviceUrl.defaultZone= http://itcast:[email protected]:6868/eureka/,http://itcast:[email protected]:6869/eureka/

访问Eureka Server的6868服务显示结果如下

访问Eureka Server的6869 服务显示结果如下

发现在Eureka的两个Server中都注册对应的商品服务

注:我们可以尝试关闭一个Eureka Server进行测试看看我们的订单服务是否可以调用商品服务