如何正确使用 Spring Cloud?【中】

3. Spring 集成了哪些经常使用组件?

从 2004 年发布 1.0 版本开始,Spring 目前已经演进至 5.x 版本了,为不一样时期的应用开发提供了强有力的支撑。如今咱们正面对微服务、DevOps、云计算这些新的挑战,Spring 家族的新生力量 Spring Cloud 又将给咱们提供哪些方面的支撑呢?归纳起来讲,我以为主要分为四类:html

  • 在单个微服务的构建上,它提供了一套应用开发框架,主体是基于 Spring Framework 这个生态的开源产品。
  • 在水平维度服务集成上,它以 Starter 的方式集成了大量经常使用组件和微服务全家桶,达到开箱即用,下降咱们开发微服务的难度,提高效率,避免重复投入。
  • 在垂直维度资源调度上,它能够跟 Cloud Foundry、Kubernetes、Docker 等平滑集成,让应用上云更加简单,让资源调度变得更加智能高效,让应用具有更大的弹性。
  • 在研发流程全线连通上,它能够跟 DevOps 相关系统作一些配合和优化,以便应用可以更加顺畅地经过各个研发环节,让持续集成、持续交付更加高效。

接下来,咱们将展开每一个点来看一看。首先,咱们来看一下它究竟集成了一些什么样的经常使用组件:数据库

  • 监控服务类,包括主机监控(Vector)、应用监控(Actuator)等;
  • 存储服务类,包括关系型数据库(MySQL)、文档型数据库(MangoDB)、内存型数据库(Redis)等;
  • 消息服务类,包括 ActiveMQ、RocketMQ、Kafka 等;
  • 安全服务类,包括 OAuth2.0、JWT 等。

4. Spring Cloud 微服务全家桶有哪些?

除了经常使用组件以外,Spring Cloud 还集成了微服务全家桶,开箱即用:安全

  • 服务注册发现类,包括:Eureka、Consul、Zookeeper、Etcd 等;

服务注册:每一个微服务组件都向注册中心登记本身提供的服务,包括服务的主机、端口号、版本号、通信协议等信息。注册中心按照服务类型分类组织服务清单,同时以心跳检测的方式监测清单中服务是否可用,若不可用须要从服务清单中剔除,以达到排除故障服务的效果。架构

服务发现:在服务治理框架下,服务间的调用再也不经过具体的实例地址来实现,而是经过服务名发起请求调用实现。服务调用方经过服务名从注册中心的服务清单中获取服务实例的列表清单,经过指定的负载均衡策略取出一个服务实例位置来进行服务调用。app

  • 服务调用框架类,包括:Ribbon、Feign 等;

客户端负载均衡,将负载均衡逻辑集成到消费方,消费方从注册中心获知服务有哪些实例可用,而后再按照某种策略从这些地址中选择一个服务实例进行访问。负载均衡

  • 服务容错组件类,包括:Hystrix 等;

服务熔断:某个目标服务不可用或大量访问超时,系统将断开该服务的调用,对后续的调用请求,系统再也不继续转发至此服务,直接返回失败应答,从而快速地释放资源;若是目标服务状况好转,则恢复调用。服务降级:在应急屏蔽或服务熔断状况下,直接返回本地缺省的应答。框架

  • 统一配置中心类,包括:Spring Cloud Config、Spring Cloud Bus 等;

在服务构建阶段,配合构建流水线,为服务软件包或镜像提供配置;在服务运维阶段,动态调整服务配置,知足运维的灵活性需求;在服务开发阶段,提供配置 API 将配置外置化,供其余系统调用。运维

  • 服务网关代理类,包括:Zuul、Spring Cloud Gateway 等;

主要提供服务路由功能,即接收消费方的全部请求,按照某种策略将请求转发至服务提供方。同时,在服务网关中完成一系列横切面的功能,例如:权限校验、请求计量、流量控制、服务质量、请求管理、响应管理、版本管理等。微服务

  • 调用链路监测类,包括:Spring Cloud Sleuth,封装了 Dapper、Zipkin 和 HTrace 等;

微服务架构下组件的数量众多,一个业务请求可能须要调用多个服务,调用的复杂性决定了错误和异常难以定位。咱们须要知道每一个请求到底有哪些服务参与,调用顺序是怎么样的,从而清楚每一个调用步骤,出现问题也能很快定位。学习

一般咱们会采用 Eureka 做为服务注册中心,实现服务注册与发现;经过 Ribbon 和 Feign 实现服务的消费以及客户端负载均衡;经过 Spring Cloud Config 实现应用不一样环境的外部化配置以及版本管理。为了让服务集群更为健壮,借助 Hystrix 的融断机制来避免微服务架构中个别服务出现异常时引发故障蔓延和雪崩。服务网关 Zuul 为微服务架构门户,将权限控制、计量计费等较重的非业务逻辑内容迁移到服务路由层面,使得服务集群主体可以具有更高的可复用性和可测试性。

本文主要价值是帮助你们梳理出 Spring Cloud 相关的知识框架,也就是咱们常说的全局视角或者上帝视角。有了这个框架以后,咱们能够根据本身的须要按图索骥找相关节点的资料来研究学习,不至于陷入细节找不到方向。固然,考虑到咱们每一个人的工做学习状况不一样,平时遇到的问题也不一样,本文内容没法覆盖全部人遇到的问题,欢迎你们留言提问,也欢迎关注「 IT老兵哥 」交流互动,谢谢!

本系列其余文章索引以下:

相关文章
相关标签/搜索