SpringCloud基本认知
本文学习自《重新定义SpringCloud》
微服务架构概述
应用架构的发展
- 应用是可独立运行的程序代码，提供的相对应完善的业务功能。
- 目前软件架构有三种架构类型，分别是业务架构，应用架构，技术架构，他们之前的关系是：业务架构决定应用架构，技术架构支撑应用架构。
- 架构的发展历程是从单体架构、分布式架构、SOA架构再到微服务架构。
微服务架构
- 微服务的概念最早的起源于MartinFowler的一篇文章<>。总体来说，微服务是一种架构风格，对于个大型复杂的业务系统，他的业务功能可以拆分为多个相互独立的微服务，各个微服务之间是松耦合的，通过各种远程协议进行同步 / 异步通信，各个微服务都可以被独立的部署、扩 / 缩容以及升 / 降级。
微服务的解决方案
- 现如今微服务架构十分流行，而采用微服务架构构建系统也会带来更清晰的业务划分和扩展性。同时支持微服务的技术栈也是多种多样的，
基于SpringCloud的微服务解决方案
- SpringCloud的技术选型是中立的，因此可以随意搭配使用，基于SpringCloud的微服务落地解决方案可以分三种，如下图：
基于Dubbo实现的微服务解决方案
- 2012年阿里巴巴在GItHub上开源了基于Java的分布式服务治理框架Dubbo，但是Dubbo的未来定位并不是要成为一个微服务的全面解决方案，而是专注于RPC领域，成为微服务生态体系中的一个重要组件。至于微服务衍生出来的服务治理需求，DUbbo正在积极适配开源解决方案，并且已经启动独立的开源项目予以支持，比如宣布开源的Nacos，Nacos的定位是一个更易于解决帮助构建云原生应用的动态服务发现、配置和服务管理平台。因此基于Dubbo的微服务解决方案时候： Dubbo + Nacos + 其他。
SpringCloud与中间件
中间件概述
- 中间件与操作系统，数据库并列为传统基础软件的三驾马车。其中，中间件也是难度极高的软件工程。传统中间件观念，诞生在于上一个 “ 分布式 ” 计算的年代，也就是小规模局域网中的服务器 / 客户端计算模式，在操作系统之上，应用软件之下的 " 中间层 " 软件。
- 随着互联网的快速发展，以及云技术的出现，企业的IT架构正在发生深刻的变革。在整个过程中，软件向大规模互联网云服务演化，无论是操作系统还是数据库都发生了深刻的变化，中间件也在这个过程中不断演进和扩大自己边界。中间件向下屏蔽异构的硬件，软件，网络等计算机资源，向上提供应用的开发、运行、维护等生命周期的统一计算环境与管理，属于承上启下的中间连接层，对企业来说有这极其重要的价值。中间件本质上可以归属于技术架构，常见的中间件分别是服务治理中间件（例如Dubbo等RPC框架）、配置中心、全链路监控、分布式事务、分布式定时任务、消息中间件、API网关、分布式缓存、数据库中间件等。
什么是SpringCloud
- SpringCloud也是一个中间件，它目前是由Spring官网开发维护，基于SpringBoot开发，提供一套完整的微服务解决方案。其中包括服务的注册和发现、配置中心，全链路监控、API网关、熔断等选型中立的开源组件，可以随时扩展和替换组件。
SpringCloud项目模块
- SpringCloud是一个开源项目集合，包括很多子项目。具体的项目地址可以参考GitHub组织： https://github,com/spring-clooud 。因为SpringCloud的子项目居多，每个子项目都有自己的版本号，为了对SpringCloud整体进行版本编号，确定一个可用于生产上的版本标识。这些版本采用伦敦地铁站的名字，按照首字母进行排序，例如Dalston版，Edgware版
组件名称
所属项目
组件分类
Eureka
spring-cloud-netflix
注册中心
Zuul
spring-cloud-netflix
第一代网关
Sidecar
spring-cloud-netflix
多语言
Ribbon
spring-cloud-netflix
负载均衡
Hystrix
spring-cloud-netflix
熔断器
Turbine
spring-cloud-netflix
集群监控
Feign
spring-cloud-OpenFeign
声明式Http客户端
Consul
spring-cloud-Consul
注册中心
Gateway
spring-cloud-Gateway
第二代网关
Sleuth
spring-cloud-Sleuth
链路追踪
Config
spring-cloud-Config
配置中心
Bus
spring-cloud-Bus
总线
Pipeline
spring-cloud-Pipeline
部署管道
Dataflow
spring-cloud-Dataflow
数据处理
SpringCloud与服务治理中间件
服务治理中间件包含服务注册与发现、服务路由、负载均衡、自我保护、丰富的治理管理机制等功能，其中服务路由包含服务上下线、在线测试、机房就近选择、A / B 测试、灰度发布等。负载均衡支持根据目标状态和目标权重进行负载均衡。自我保护包括服务降级、优雅降级、流量控制。
SpringCloud作为一个服务治理中间件，它的服务治理体系做了高度的抽象，目前支持使用Eureka、Zookeeper、Consul作为注册中心，并且预留了扩展接口，而且选项是中立的，所有支持无缝替换，在SpringCloud中可以通过Hystrix进行熔断自我保护Fallback，通过Ribbon进行负载均衡。
Feature
Consul
Zookeeper
etcd
Eureka
服务健康检查
服务状态，内存，硬盘等
(弱) 长链接，keepalive
连接心跳
可配支持
多数据中心
支持
-
-
-
K / V 存储服务
支持
支持
支持
-
一致性
raft
Paxos
Raft
-
CAP原则
CA
CP
CP
AP
使用接口(多语言能力)
支持Http和DNS
客户端
Http / GRPC
Http(Sidecar)
Watch支持
全量/支持LongPolling
支持
支持LongPolling
支持LongPolling / 大部分增量
自身监控
metrics
-
metric
metric
安全
acl / Https
acl
https支持(弱)
-
SpringCloud集成
已支持
已支持
已支持
已支持
SpringCloud与配置中心中间件
在单体应用中，我们一般的做法是把属性配置和代码硬编码放在一起，这没有什么问题。但是在分布式系统中，由于存在多个服务实例，需要分别管理每一个具体服务工程管理，上线需要CheckList，并逐个检查每个上线的服务是否正确。在系统上线之后一旦修改了某个配置就需要重启服务。这样开发管理很是麻烦，因此我们需要把分布式系统中的配置信息抽取出来统一管理，这个管理的中间件称为配置中心。配置中心应该具备的功能，分别支持各种复杂的配置场景，与公司的运维体系和权限管理体系集成，各种配置兼容支持。
SpringCloudConfig是SpringCloud生态圈中的配置中心的中间件，他把应用原本放在本地文件中的配置抽取出来放在中心服务器，从而能提供更好的管理，发布能力。SpringCloudConfig基于应用、环境、版本三个维度管理，配置存储支持Git和其他扩展存储，且无缝支持Spring里的Environment和PropertySoure的接口，但是SpringcloudConfig的缺点是没有可视化管理平台，因此会使用其他的配置中心取代他的管理位置。
SpringCloud于网关中间件
网关中间件概述
- API Gateway(APIGW / API网关)，顾名思义，是出现在系统边界上的一个面向API的、串行集中式的强管控服务，这里的边界是企业IT系统的边界，可以理解为企业级应用防火墙，主要起到隔离外部访问和内部系统调用的作用。在微服务概念流行之前，API网关就已经诞生了，例如银行、证券等领域常见的前置系统，它的设计与出现主要是为了解决访问认证、报文转换、访问统计等问题。
随着微服务架构概念的提出，API网关成为了微服务架构的一个标准组件。作为一个网关中间件，至少具备如下四大功能：
统一接入功能
- 为各种无线应用提供统一的接入服务，提供一个高性能、高并发、高可靠的网关服务。不仅如此，还要支持负载均衡，容灾均衡和异地多活。
协议适配功能
- 网关对外的请求协议一般都是Http或Http2协议，而后端提供访问的服务协议要么是Rest要么是RPC协议。网关需要根据请求进来的协议适配，然后协议转发调用不同协议提供的服务。比如网关对外暴露是Http协议的请求，而网关后端服务可能是Dubbo提供的RPC服务，可能是SpringCloud提供的Rest服务。当一个Http请求经过网关时，通过一系列不同功能的Filter处理过后，此时就需要进行协议适配，判断应该协议转发时调用RPC服务还是Rest服务。
流量管控功能
- 网关作为所有请求流量的入口，当流量请求瞬间暴增时，需要进行流量管控，流量调拨。当后端服务出现异常，服务不可调用时。需要网关进行熔断和服务降级。在异地多活的场景中需要根据请求进行分片，路由到不同的机房。
安全防护功能
- 网关需要对所有的请求进行安全防护过滤，保护后端服务。通过与安全风控部门合作，对IP黑名单和URL黑名单封禁控制，做风控防刷，恶意攻击等。
SpringCloud第一代网关Zuul
- SpringCloud生态圈的第一代网关是在NetFlix公司开源的网关组件Zuul之上，他是基于SpringBoot注解，采用Starter的方式进行二次封装，可以做到开箱即用。目前Zuul融合了SpringCloud提供的服务治理体系，根据配置的路由规则或则默认的路由规则进行路由转发和负载均衡。他可以和SpringCloud生态系统内的其他组件集成使用。例如：集成Hystrix可以在网关层面实现降级功能，集成Ribbon可以使整个架构更具有弹性伸缩能力，集成Archeius可以进行配置管理。但是SpringCloudZuul如果需要做一些灰度、降级、标签路由、限流、WAF封禁，则需要自定义Filter做一些定制化实现。
SpringCloud第二代网关Gateway
- SpringCloudZuul处理请求的方式是对每一个请求来分配一个线程来处理。根据参考数据统计，目前Zuul最多能到达1000至2000Q，在高并发情况下，不推荐Zuul作为网关。因此出现了SpringCloud的第二代网关-SpringCloudGateway。
- SpringCloudGateway是Spring官方基于Spring5.0、SpringBoot2.0和ProjectReactor等技术开发的网关。旨在为微服务架构提供一种简单，有效，统一的API路由管理方式。SpringCloudGateway底层基于Netty实现(Netty的线程模型是多线程reactor模型，使用Boss线程和Worker线程接收并异步处理请求，具有很强大的高并发处理能力)，因此SpringCloudGateway出现的目的就是代替NetFlixZuul。其不仅提供统一的路由方式，并且基于Filter链的方式提供了网关基本的功能，例如安全、监控/埋点、限流等。
SpringCloud与全链路监控中间件
众所周知，中大型互联网公司的后台业务系统由众多分布式应用组成，一个浏览器或者移动客户端的请求到后端服务应用，会经过很多应用的系统，并且留下足迹和相关的日志信息，但这些分散在每个业务应用下主机下的日志信息不利于排查问题与定位问题发生的根本原因。因此就需要利用全链路监控中间件收集，汇总并分析日志信息。进行可视化展示和监控告警。推荐使用Pinpoint或者Skywalking(非入侵式)。全链路监控中间件应该提供的主要功能包括：
- 定位慢调用：包括慢Web服务(包括RestFul Web服务)、慢REST或RPC服务、慢SQL。
- 定位各种错误：包括4 X X、5 X X、ServiceError。
- 定位各种异常：包括ErrorException，FatalException。
- 展现依赖和拓扑：域拓扑、服务拓扑、trace拓扑。
- Trace调用链：将端到端的调用，以及附加在这次调用的上下文信息，异常日志信息，每一个调用点的耗时偶呈现给用户进行展示。
- 应用警告：根据运维设定的警告规则，扫描指标数据，如违反警告规则，则将警告信息上报到中央警告平台。
SpringCloud增强生态
SpringCloud分布式事务
微服务提倡将复杂的单体应用拆分为若干个功能简单、松耦合的服务（一般的拆分都是按照业务进行拆分），这样可以降低开发难度，增强扩展性、便于敏捷开发。但是对于一般的小型互联网公司而已，由于经验和技术实力的问题，更换使用微服务主要的困难有一下几点：
- 单体应用拆分为分布式系统后，进程间的通信机制和故障处理措施变得更加复杂。
- 系统微服务化后，一个看是简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题编变得非常突出。
- 微服务数量众多，其测试、部署、监控等都变得更加困难。
随着RPC框架的成熟，第一个问题已经逐渐得到了解决。例如HSF，Dubbo可以支持多种通信协议，SpringCloud可以非常友好的支持RestFul调用。
对于第三个问题，随着Docker，Devops技术的发展以及各公有云PAAS平台自动化运维工具的退出，微服务的测试、部署与运维都变得越来越容易。
SpringCloud与领域驱动
- SpringCloud组件众多，更像一套中间件体系，是实现微服务架构的基础实施。SpringCloud作为微服务架构的基础实施，能够快速帮助企业开发者搭建微服务架构。
- SpringCloud解决框架层面的问题，但是对于业务怎么开发，业务架构怎么治理，架构怎么防腐，怎么解决应用架构的复杂性问题，还需要方法论去指导实践，所以在微服务架构落地实施的过程中，SpringCloud与领域驱动相辅相成显得十分重要
SpringCloud与gRPC
- 通过SpringCloud构建微服务应用，大多数开发者使用官方提供的服务调用组件Feign来进行内部服务的调用，这种声明式的HTTP客户端调使用起来极为简单、优雅、方便、然而Feign的底层调用实现底走的还是HTTP，相对于Dubbo、gRPC等RPC框架走RPC协议来说，通过Http来进行服务之间的调用，性能相对底线。
SpringCloud与Dubbo生态融合
- 在微服务架构的实施和落地中，我们通常会进行技术选项，做一些对比。很多人都会拿阿里开源的Dubbo和SpringCloud进行对比，其本质对比的主要是REST和RPC。其实SpringCloud和Dubbo并不在同一个领域，没有什么可比性。以为SpringCloud是一个完整的微服务解决方案，提供分布式情况下的各种解决方案集合。而Dubbo是一款高性能的 Java RPC 框架。SpringCloud生态与Dubbo生态随着发展将会逐渐融合互补。
- SpringCloud的设计理念是Integrate Everything，即充分利用现有开源组件，在它们之上设计一套统一规范接口使它们能够接入SpringCloud体系并且能够无缝切换底层实现，最典型的例子就是DiscoveryClient，只要实现了DiscoveryClinet相关的接口。SpringCloud的底层注册中心就可以随便替换，Dubbo的注册中心也有SPI规范进行替换。
- 在2018年6月SpringCloud中国社区开源了一个名为Spring-Cloud-Dubbo项目，该项目的目标是将Dubbo融入SpringCloud生态体系中，使微服务之间的调用同时具备RestFul和Dubbo调用能力，做到对业务代码无入侵、无感知。若在使用过程引入Jar包则在微服务调用时使用Dubbo，去掉Jar包则使用默认的RestFul。
手机扫一扫
移动阅读更方便
你可能感兴趣的文章