文章目录

(一)架构的演变
(二)RPC和HTTP
(三)HTTP客户端
(四)初识springcloud
(五)搭建服务提供方
(六)搭建服务调用方
(七)小结
(八)初识eureka注册中心
(九)搭建eureka注册中心
(十)改造：微服务注册到eureka注册中心
(十一)改造：消费方解决地址硬编码问题
(十二)高可用的eureka
(十三)eureka详解（提供方）
(十四)eureka详解（消费方）
(十五)eureka详解（失效剔除和自我保护）
(十六)springcloud相关的面试题

(一)架构的演变

传统一台服务器的缺点：

• 单点故障
• 处理并发的能力差
• 代码耦合度高
• 不方便扩展

拆分前的优点：维护方便

---

拆分方式：

• 水平拆分：web层、service层、mapper层
• 垂直拆分：功能拆分（最早期的分布式）

拆分后的优点：

• 方便水平扩展
• 方便单独优化
• 解耦合
• 提高并发

拆分后的缺点：

• 增加维护成本
• 重复开发（每一台服务器都有重复的模块，如注册登录、用户管理等等）

---

暴力拆分会存在代码冗余的问题，我们可以把每个功能模块单独提取出来，即分布式，如下：

解决的问题：代码冗余、重复开发
带来的问题：调用关系错综复杂、维护困难

---

SOA提供了注册中心，可以完美解决以上问题，如下：

---

上面的SOA一个框框可以部署多个业务，但是微服务强调的是细，如下：

微服务的特点：

• 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责
• 微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱全”。
• 面向服务：面向服务是说每个服务都要对外暴露Rest风格服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可。
• 自治：自治是说服务间互相独立，互不干扰
  • 团队独立：每个服务都是一个独立的开发团队，人数不能过多。
  • 技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉
  • 前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动段开发不同接口
  • 数据库分离：每个服务都使用自己的数据源
  • 部署独立：服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护

(二)RPC和HTTP

无论是微服务还是SOA，都面临着服务间的远程调用。那么服务间的远程调用方式有哪些呢？

常见的远程调用方式有以下2种：

• RPC：Remote Produce Call远程过程调用，类似的还有RMI。自定义数据格式，基于原生TCP通信，速度快，效率高。早期的webservice，现在热门的dubbo，都是RPC的典型代表

• HTTP：http其实是一种网络传输协议，基于TCP，规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议，也可以用来进行远程服务调用。缺点是消息封装臃肿，优势是对服务的提供和调用方没有任何技术限定，自由灵活，更符合微服务理念。
  现在热门的Rest风格，就可以通过http协议来实现。

如果你们公司全部采用Java技术栈，那么使用Dubbo作为微服务架构是一个不错的选择。

相反，如果公司的技术栈多样化，而且你更青睐Spring家族，那么SpringCloud搭建微服务是不二之选。在我们的项目中，我们会选择SpringCloud套件，因此我们会使用Http方式来实现服务间调用。

(三)HTTP客户端

既然微服务选择了Http，那么我们就需要考虑自己来实现对请求和响应的处理。
不过开源世界已经有很多的http客户端工具，能够帮助我们做这些事情，例如：

• HttpClient
• OKHttp
• URLConnection

这些不同的客户端，API各不相同

Spring提供了一个RestTemplate模板工具类，对基于Http的客户端进行了封装，并且实现了对象与json的序列化和反序列化，非常方便。RestTemplate并没有限定Http的客户端类型，而是进行了抽象，目前常用的3种都有支持

导入资料包中的工程，如下：

(四)初识springcloud

微服务是一种架构方式，最终肯定需要技术架构去实施。

微服务的实现方式很多，但是最火的莫过于Spring Cloud了。为什么？

• 后台硬：作为Spring家族的一员，有整个Spring全家桶靠山，背景十分强大。
• 技术强：Spring作为Java领域的前辈，可以说是功力深厚。有强力的技术团队支撑，一般人还真比不了
• 群众基础好：可以说大多数程序员的成长都伴随着Spring框架，试问：现在有几家公司开发不用Spring？SpringCloud与Spring的各个框架无缝整合，对大家来说一切都是熟悉的配方，熟悉的味道。
• 使用方便：相信大家都体会到了SpringBoot给我们开发带来的便利，而SpringCloud完全支持SpringBoot的开发，用很少的配置就能完成微服务框架的搭建

Spring最擅长的就是集成，把世界上最好的框架拿过来，集成到自己的项目中。

SpringCloud也是一样，它将现在非常流行的一些技术整合到一起，实现了诸如：配置管理，服务发现，智能路由，负载均衡，熔断器，控制总线，集群状态等等功能。其主要涉及的组件包括：

• Eureka：服务治理组件，包含服务注册中心，服务注册与发现机制的实现。（服务治理，服务注册/发现）
• Zuul：网关组件，提供智能路由，访问过滤功能
• Ribbon：客户端负载均衡的服务调用组件（客户端负载）
• Feign：服务调用，给予Ribbon和Hystrix的声明式服务调用组件 （声明式服务调用）
• Hystrix：容错管理组件，实现断路器模式，帮助服务依赖中出现的延迟和为故障提供强大的容错能力。(熔断、断路器，容错)

因为Spring Cloud不同其他独立项目，它拥有很多子项目的大项目。
所以它的版本是 版本名 + 版本号
如Angel.SR6：

• 版本名：是伦敦的地铁名
• 版本号：SR（Service Releases）是固定的，大概意思是稳定版本。后面会有一个递增的数字。

所以 Edgware.SR3就是Edgware的第3个Release版本。

(五)搭建服务提供方

在学习springcloud之前，先自己搭建一个类似于springcloud的项目群
以后创建springboot的项目，可以直接使用Spring Initializr，如下：
（建议把https改成htttp下载会快很多，有时候默认的https会下载很慢甚至下载失败）


教程用的是2.0.6版本，但是现在最低只能选到2.1.15，我们选它，创建后再修改，如下：



把版本号改成2.0.6.RELEASE，如下：

导入通用mapper，如下：

        <!-- 通用mapper --><dependency><groupId>tk.mybatis</groupId><artifactId>mapper-spring-boot-starter</artifactId><version>2.0.2</version></dependency>

修改mysql版本号，如下：

我们这次把application.properties改成application.yml，写法如下：

server:port: 8089
spring:datasource:url: jdbc:mysql://127.0.0.1:3306/ssm?useSSL=true&serverTimezone=UTCusername:  rootpassword:  123
mybatis:type-aliases-package: com.zzq.service.pojo

把User实体类拷贝过来，如下：

创建一个mapper并且在引导类加上注解，如下：

写一个service，如下：

最后写一个controller，如下：

测试结果如下：

(六)搭建服务调用方

首先修改配置文件，如下：

然后在引导类中注册RestTemplate，如下：

编写一个controller，如下：

首先启动provider，再启动consumer，如下：

效果如下：

(七)小结

简单回顾一下，刚才我们写了什么：

• itcast-service-provider：一个提供根据id查询用户的微服务。
• itcast-service-consumer：一个服务调用者，通过RestTemplate远程调用itcast-service-provider。

存在什么问题？

• 在consumer中，我们把url地址硬编码到了代码中，不方便后期维护
• consumer需要记忆provider的地址，如果出现变更，可能得不到通知，地址将失效
• consumer不清楚provider的状态，服务宕机也不知道
• provider只有1台服务，不具备高可用性
• 即便provider形成集群，consumer还需自己实现负载均衡

其实上面说的问题，概括一下就是分布式服务必然要面临的问题：

• 服务管理
  • 如何自动注册和发现
  • 如何实现状态监管
  • 如何实现动态路由
• 服务如何实现负载均衡
• 服务如何解决容灾问题
• 服务如何实现统一配置

以上的问题，我们都将在SpringCloud中得到答案。

(八)初识eureka注册中心

在刚才的案例中，itcast-service-provider对外提供服务，需要对外暴露自己的地址。
而consumer（调用者）需要记录服务提供者的地址，将来地址出现变更，还需要及时更新。
这在服务较少的时候并不觉得有什么，但是在现在日益复杂的互联网环境，一个项目肯定会拆分出十几，甚至数十个微服务。
此时如果还人为管理地址，不仅开发困难，将来测试、发布上线都会非常麻烦，这与DevOps的思想是背道而驰的。这就好比是 网约车出现以前，人们出门叫车只能叫出租车。
一些私家车想做出租却没有资格，被称为黑车。而很多人想要约车，但是无奈出租车太少，不方便。
私家车很多却不敢拦，而且满大街的车，谁知道哪个才是愿意载人的。一个想要，一个愿意给，就是缺少引子，缺乏管理啊。
此时滴滴这样的网约车平台出现了，所有想载客的私家车全部到滴滴注册，记录你的车型（服务类型），身份信息（联系方式）。
这样提供服务的私家车，在滴滴那里都能找到，一目了然。
此时要叫车的人，只需要打开APP，输入你的目的地，选择车型（服务类型），滴滴自动安排一个符合需求的车到你面前，为你服务，完美！Eureka就好比是滴滴，负责管理、记录服务提供者的信息。
服务调用者无需自己寻找服务，而是把自己的需求告诉Eureka，然后Eureka会把符合你需求的服务告诉你。
同时，服务提供方与Eureka之间通过`“心跳”`机制进行监控，当某个服务提供方出现问题，Eureka自然会把它从服务列表中剔除。
这就实现了服务的自动注册、发现、状态监控。

• Eureka：就是服务注册中心（可以是一个集群），对外暴露自己的地址
• 提供者：启动后向Eureka注册自己信息（地址，提供什么服务）
• 消费者：向Eureka订阅服务，Eureka会将对应服务的所有提供者地址列表发送给消费者，并且定期更新
• 心跳（续约）：提供者定期通过http方式向Eureka刷新自己的状态

(九)搭建eureka注册中心

注意：注册中心引入Eureka Server依赖，提供方和消费方应该引入Eureka Discovery Client依赖

如果下载springcloud依赖失败，可以增加一个镜像，如下：

	 <mirror><mirror>  <id>UK</id>  <mirrorOf>central</mirrorOf>    <name>UK Central</name>  <url>http://uk.maven.org/maven2</url>  </mirror> <id>alimaven</id><mirrorOf>central</mirrorOf>  <name>aliyun maven</name><url>http://maven.aliyun.com/nexus/content/groups/public/</url>      </mirror>

修改springboot版本号、springcloud版本号，以及加上springboot2.0.6版本需要配置的UTF-8，如下：

参照源码配置，如下：

server:port: 10086
spring:application:name: zzq-eurqka #将来作为微服务的名称，注入到eureka容器（eureka工程本身也是微服务）
eureka:client:service-url:defaultZone: http://localhost:${server.port}/eureka

最后在引导类加上注解，如下：

最后启动一下eureka服务端，效果如下：

官方有一个奇怪的规定，注册的时候要加/eureka，但是用浏览器访问的时候就不需要加

可以看到eureka本身也被注入了进去，作为微服务的一员

(十)改造：微服务注册到eureka注册中心

首先给provider配置maven坐标（到中央仓库复制，不用加版本号，下面会介绍版本管理）

跟eureka一样，做统一的版本管理，版本为：Finchley.SR2
跟springcloud相关的依赖都会自适应地调整版本，如下：

然后修改配置文件，如下：

最后在引导类启用客户端，如下：

效果如下：

用同样的方法，把consumer也注册上去，效果如下：

(十一)改造：消费方解决地址硬编码问题

代码如下：

效果如下：

(十二)高可用的eureka

现在这种情况，eureka注册中心一旦发生单点故障，所有服务都将不可用
我们可以部署多个注册中心（开发一个，部署多个），挂掉一个，可以转换到另一个

右击eureka实例，选择Copy Configuration，如下：

效果如下：

我们希望这两个注册中心相互连接，如下图所示：

首先修改第一个eureka的配置，并启动，如下：
（会报错，因为端口为10087的eureka还没启动，但是不影响，微服务会隔一段时间检测、自启动）

然后修改第二个eureka的配置，并启动，如下：
（修改的是同一份配置文件，因为第一个eureka已经部署上去了，所以不会受到影响）

最终效果如下：

说明：

1. 此时两个eureka组成一个集群，信息会互相同步的，我们可以访问其中任意一个
2. 如果有三个，或者更多微服务组成集群，只要围成一圈就可以了
3. 虽然这个时候provider和consumer都是连接到端口为10086的eureka，但是它们都会跟eureka集群（或者说eureka-server）会保持心跳（或者说续约），如果发现端口为10086的eureka挂掉了，会马上转接到10087

(十三)eureka详解

服务提供者要向EurekaServer注册服务，并且完成服务续约等工作。

服务提供者在启动时，会检测配置属性中的：eureka.client.register-with-eureka=true参数是否为true，事实上默认就是true，所以我们可以不用去配置，如下：

当检测到该值确实为true时，则会向EurekaServer发起一个Rest请求，并携带自己的元数据信息，Eureka Server会把这些信息保存到一个双层Map结构中
如：Map<serviceId,Map<服务实例的id，实力对象（instance）>>

• 第一层Map的Key就是服务id，一般是配置中的spring.application.name属性
• 第二层Map的key是服务的实例id，一般host+ serviceId + port，例如：locahost:service-provider:8081

在注册服务完成以后，服务提供者会维持一个心跳（定时向EurekaServer发起Rest请求），告诉EurekaServer：“我还活着”。这个我们称为服务的续约（renew）

有两个重要参数可以修改服务续约的行为：

eureka:instance:lease-expiration-duration-in-seconds: 90lease-renewal-interval-in-seconds: 30

• lease-renewal-interval-in-seconds：服务续约(renew)的间隔，默认为30秒
• lease-expiration-duration-in-seconds：服务失效时间，默认值90秒

也就是说，默认情况下每个30秒服务会向注册中心发送一次心跳，证明自己还活着。如果超过90秒没有发送心跳，EurekaServer就会认为该服务宕机，会从服务列表中移除，这两个值在生产环境不要修改，默认即可。

但是在开发时，这个值有点太长了，经常我们关掉一个服务，会发现Eureka依然认为服务在活着。所以我们在开发阶段可以适当调小，如下：

(十四)eureka详解（消费方）

当服务消费者启动时，会检测eureka.client.fetch-registry=true参数的值（当然默认值也是true），如果为true，则会拉取Eureka Server服务的列表只读备份，然后缓存在本地。并且每隔30秒会重新获取并更新数据。我们可以通过下面的参数来修改：

eureka:client:registry-fetch-interval-seconds: 5

生产环境中，我们不需要修改这个值。

但是为了开发环境下，能够快速得到服务的最新状态，我们可以将其设置小一点，如下：

(十五)eureka详解（失效剔除和自我保护）

服务下线

当服务进行正常关闭操作时，它会触发一个服务下线的REST请求给Eureka Server，告诉服务注册中心：“我要下线了”。服务中心接受到请求之后，将该服务置为下线状态。

失效剔除

有些时候，我们的服务提供方并不一定会正常下线，可能因为内存溢出、网络故障等原因导致服务无法正常工作。Eureka Server需要将这样的服务剔除出服务列表。因此它会开启一个定时任务，每隔60秒对所有失效的服务（超过90秒未响应）进行剔除。

可以通过修改eureka配置文件的eureka.server.eviction-interval-timer-in-ms参数对其进行修改，单位是毫秒，生产环境不要修改。
这个会对我们开发带来极大的不便，你对服务重启，隔了60秒Eureka才反应过来。开发阶段可以适当调整，比如：10秒

自我保护

我们关停一个服务，就会在Eureka面板看到一条警告：

这是触发了Eureka的自我保护机制。当一个服务未按时进行心跳续约时，Eureka会统计最近15分钟心跳失败的服务实例的比例是否超过了85%。在生产环境下，因为网络延迟等原因，心跳失败实例的比例很有可能超标，但是此时就把服务剔除列表并不妥当，因为服务可能没有宕机。Eureka就会把当前实例的注册信息保护起来，不予剔除。生产环境下这很有效，保证了大多数服务依然可用。

但是这给我们的开发带来了麻烦， 因此开发阶段我们都会在eureka的配置文件中关闭自我保护模式：

eureka:server:enable-self-preservation: false # 关闭自我保护模式（缺省为打开）eviction-interval-timer-in-ms: 1000 # 扫描失效服务的间隔时间（缺省为60*1000ms）

(十六)springcloud相关的面试题

• 架构的演变
  传统架构–>水平拆分–>垂直拆分（最早的分布式）–>soa(dubbo)–>微服务(springCloud)
• 远程调用技术：rpc http
  rpc协议：自定义数据格式，限定技术，传输速度快，效率高 tcp，dubbo
  http协议：统一的数据格式，不限定技术 rest接口 tcp协议 springCloud
• 什么是springCloud
  微服务架构的解决方案，是很多组件的集合
  eureka：注册中心，服务的注册与发现
  zull：网关协议，路由请求，过滤器（ribbon hystrix）
  ribbon：负载均衡组件
  hystrix：熔断组件
  feign：远程调用组件(ribbon hystrix)

注意：feign集成了ribbon和hystrix，所以我们通常不会直接用ribbon或hystrix，而是直接用feign

总结：springcloud的组件使用都是分成以下三步

1. 引入组件的启动器
2. 覆盖默认配置
3. 在引导类上添加注解，启用相关组件