|
|
|
这几年来，微服务这个概念越来越火了，火到什么程度呢？
2019年有一个统计说，两千家企业里，45%在使用微服务，16%在实验开发和测试微服务架构，24%在学习微服务准备转型，只有剩下的15%的企业没有使用微服务。
微服务到底哪里好呢？微服务在2013年才被提出，短短几年就有这么快速的发展。
微服务架构能够实现由小型自主服务组成一个整体应用，各个组成部分之间是松耦合的，复杂性低，各个部分可以独立部署，修复bug或者引入新特性更容易，能够独立扩展，不同技术栈之间可以使用不同框架、不同版本库甚至不同的操作系统平台。
对于中大型架构系统来说，微服务更加便捷，微服务成为很多企业架构重构的方向，同时也对架构师提出更高的挑战。
现如今微服务架构十分流行，而采用微服务构建系统也会带来更清晰的业务划分和可扩展性。同时，支持微服务的技术栈也是多种多样的，本篇着重解析技术中的翘楚——Spring Cloud。
为什么微服务架构需要Spring Cloud？简单来说，服务化的核心就是将传统的一站式应用根据业务拆分成一个一个的服务，而微服务在这个基础上要更彻底地去耦合（不再共享DB、KV，去掉重量级ESB），并且强调DevOps和快速演化。这就要求我们必须采用与一站式时代、泛SOA时代不同的技术栈，而Spring Cloud就是其中的佼佼者。
DevOps是英文Development和Operations的合体，他要求开发、测试、运维进行一体化的合作，进行更小、更频繁、更自动化的应用发布，以及围绕应用架构来构建基础设施的架构。这就要求应用充分的内聚，也方便运维和管理。这个理念与微服务理念不谋而合。
接下来我们从服务化架构演进的角度来看看为什么Spring Cloud更适应微服务架构。
1.1 从使用nginx说起最初的服务化解决方案是给提供相同服务提供一个统一的域名，然后服务调用者向这个域名发送HTTP请求，由Nginx负责请求的分发和跳转。
这种架构存在很多问题：
Nginx作为中间层，在配置文件中耦合了服务调用的逻辑，这削弱了微服务的完整性，也使得Nginx在一定程度上变成了一个重量级的ESB。
服务的信息分散在各个系统，无法统一管理和维护。每一次的服务调用都是一次尝试，服务消费者并不知道有哪些实例在给他们提供服务。这不符合DevOps的理念。
无法直观的看到服务提供者和服务消费者当前的运行状况和通信频率。这也不符合DevOps的理念。
消费者的失败重发，负载均衡等都没有统一策略，这加大了开发每个服务的难度，不利于快速演化。
为了解决上面的问题，我们需要一个现成的中心组件对服务进行整合，将每个服务的信息汇总，包括服务的组件名称、地址、数量等。服务的调用方在请求某项服务时首先通过中心组件获取提供这项服务的实例的信息（IP、端口等），再通过默认或自定义的策略选择该服务的某一提供者直接进行访问。所以，我们引入了Dubbo。
1.2 基于Dubbo实现微服务Dubbo是阿里开源的一个SOA服务治理解决方案，文档丰富，在国内的使用度非常高。
使用Dubbo构建的微服务，已经可以比较好地解决上面提到的问题：
调用中间层变成了可选组件，消费者可以直接访问服务提供者。
服务信息被集中到Registry中，形成了服务治理的中心组件。
通过Monitor监控系统，可以直观地展示服务调用的统计信息。
Consumer可以进行负载均衡、服务降级的选择。
但是对于微服务架构而言，Dubbo也并不是十全十美的：
Registry严重依赖第三方组件（zookeeper或者redis），当这些组件出现问题时，服务调用很快就会中断。
DUBBO主要使用RPC调用。使得服务提供方与调用方在代码上产生了强依赖，服务提供者需要不断将包含公共代码的jar包打包出来供消费者使用。一旦打包出现问题，就会导致服务调用出错。
1.3 最佳选择——Spring Cloud作为新一代的服务框架，Spring Cloud提出的口号是开发“面向云环境的应用程序”，它为微服务架构提供了更加全面的技术支持。结合我们一开始提到的微服务的诉求，我们把Spring Cloud与DUBBO进行一番对比：
Spring Cloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。严格来说，这两种方式各有优劣。虽然从一定程度上来说，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更加合适。
Eureka相比于zookeeper，更加适合于服务发现的场景，这点会在下一篇会详细展开。
很明显，Spring Cloud的功能比DUBBO更加强大，涵盖面更广，而且作为Spring的拳头项目，它也能够与Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring项目完美融合，这些对于微服务而言是至关重要的。
前面提到，微服务背后一个重要的理念就是持续集成、快速交付，而在服务内部使用一个统一的技术框架，显然比把分散的技术组合到一起更有效率。更重要的是，相比于Dubbo，它是一个正在持续维护的、社区更加火热的开源项目，这就保证使用它构建的系统，可以持续地得到开源力量的支持。
Spring Cloud特点和核心组件NO.1
Spring Cloud 特点
[list,
[*,约定大于配置
[*,适用于各种环境
[*,隐藏了组件的复杂性，并提供声明式、无XML式的配置方式
[*,开箱即用，快速启动
[*,组件丰富，功能齐全
NO.2
Spring Cloud 核心
[/list,Spring Cloud Netflix：核心组件，包括以下几个组件：
[list,
[*,Eureka：服务治理组件，包含服务注册与发现
[*,Hystrix：容错管理组件，实现了熔断器
[*,Ribbon：客户端负载均衡的服务调用组件
[*,Feign：基于Ribbon和Hystrix的声明式服务调用组件
[*,Zuul：网关组件，提供智能路由、访问过滤等功能
[/list,Spring Cloud Config:
配置管理工具，实现应用配置的外部化存储，支持客户端配置信息刷新、加密/解密配置内容等。
Spring Cloud Bus:
Spring Cloud Security:
Spring Cloud Consul:
封装了Consul操作，Consul是一个服务发现与配置工具（与Eureka作用类似），与Docker容器可以无缝集成
《百战Java》第十二阶段
Spring Cloud 更新啦！
想系统的学习，看过来,你们想听的课程在这里！
章节1：Spring Cloud
01-微服务简介
02-应用架构变迁图
03-SpringCloud简介
04-Netfix简介
05-框架结构介绍
06-与Dubbo对比
07-版本号说明
08-Eureka简介
09-Eureka和Zokeeper对比
10-搭建Eureka注册中心及管理平台介绍
11-搭建高可用集群
12-使用脚本启动Eureka集群
13-集群原理
14-Eureka优雅停服
15-Ribbon简介及编写服务提供者
16-编写服务消费方代码
17-集中式与进程内负载均衡区别
18-Ribbon常用负载均衡简介
19-配置负载均衡策略
20-Ribbon点对点直连实现
21-OpenFeign简介
22-创建服务标准接口及服务提供者
23-标准服务接口接收参数说明
24-创建服务消费方并访问测试
25-参数处理简单总结
26-Gzip简介
27-Feign对Gzip压缩的支持
28-全局Gzip压缩
29-配置负载均衡及请求超时时间
30-雪崩效应简介
31-Hystrix简介
32-服务降级
33-服务熔断
34-请求缓存1
35-请求缓存2
36-Openfeign实现服务降级
37-Openfeign实现服务熔断
38-HystrixDashboard搭建
39-分布式配置中心介绍
40分布式配置中心结构图
41-基于Gitee管理配置文件
42-搭建配置中心服务端
43-浏览器测试读取Gitee配置文件
44-搭建配置中心客户端
45-配置热刷新环境
46-代码中使用远程配置内容
47-Gateway简介
48-搭建Gateway服务
49-搭建第一个被代理的服务service01
50-搭建第二个被代理的服务service02
51-实现路由功能之测试
52-手工绑定路由规则说明
53-手工绑定路由规则实现
54-Gateway内置过滤器介绍
55-内置过滤器AddRequestParameter的使用
56-内置过滤器AddRequestParameter扩展
57-内置过滤器AddRequestHeader的使用
58-自定义GatewayFilter的实现1
59-自定义GatewayFilter的实现2
60-自定义GatewayFilter的实现3
61-测试自定义GatewayFilter
62-自定义全局过滤器GlobalFilter
63-实现熔断功能1
64-实现熔断功能2
百战学习中心，更多精彩等你来!
|
|
发表于 2020-4-23 02:42:05
