从 2004 年发布 1.0 版本开始,Spring 目前已经演进至 5.x 版本了,为不同时期的应用开发提供了强有力的支撑。现在我们正面对微服务、DevOps、云计算这些新的挑战,Spring 家族的新生力量 Spring Cloud 又将给我们提供哪些方面的支撑呢?概括起来说,我觉得主要分为四类:
接下来,我们将展开每个点来看一看。首先,我们来看一下它究竟集成了一些什么样的常用组件:
除了常用组件之外,Spring Cloud 还集成了微服务全家桶,开箱即用:
服务注册:每个微服务组件都向注册中心登记自己提供的服务,包括服务的主机、端口号、版本号、通讯协议等信息。注册中心按照服务类型分类组织服务清单,同时以心跳检测的方式监测清单中服务是否可用,若不可用需要从服务清单中剔除,以达到排除故障服务的效果。
服务发现:在服务治理框架下,服务间的调用不再通过具体的实例地址来实现,而是通过服务名发起请求调用实现。服务调用方通过服务名从注册中心的服务清单中获取服务实例的列表清单,通过指定的负载均衡策略取出一个服务实例位置来进行服务调用。
客户端负载均衡,将负载均衡逻辑集成到消费方,消费方从注册中心获知服务有哪些实例可用,然后再按照某种策略从这些地址中选择一个服务实例进行访问。
服务熔断:某个目标服务不可用或大量访问超时,系统将断开该服务的调用,对后续的调用请求,系统不再继续转发至此服务,直接返回失败应答,从而快速地释放资源;如果目标服务情况好转,则恢复调用。服务降级:在应急屏蔽或服务熔断情况下,直接返回本地缺省的应答。
在服务构建阶段,配合构建流水线,为服务软件包或镜像提供配置;在服务运维阶段,动态调整服务配置,满足运维的灵活性需求;在服务开发阶段,提供配置 API 将配置外置化,供其他系统调用。
主要提供服务路由功能,即接收消费方的所有请求,按照某种策略将请求转发至服务提供方。同时,在服务网关中完成一系列横切面的功能,例如:权限校验、请求计量、流量控制、服务质量、请求管理、响应管理、版本管理等。
微服务架构下组件的数量众多,一个业务请求可能需要调用多个服务,调用的复杂性决定了错误和异常难以定位。我们需要知道每个请求到底有哪些服务参与,调用顺序是怎么样的,从而清楚每个调用步骤,出现问题也能很快定位。
通常我们会采用 Eureka 作为服务注册中心,实现服务注册与发现;通过 Ribbon 和 Feign 实现服务的消费以及客户端负载均衡;通过 Spring Cloud Config 实现应用不同环境的外部化配置以及版本管理。为了让服务集群更为健壮,借助 Hystrix 的融断机制来避免微服务架构中个别服务出现异常时引起故障蔓延和雪崩。服务网关 Zuul 为微服务架构门户,将权限控制、计量计费等较重的非业务逻辑内容迁移到服务路由层面,使得服务集群主体能够具备更高的可复用性和可测试性。
本文主要价值是帮助大家梳理出 Spring Cloud 相关的知识框架,也就是我们常说的全局视角或者上帝视角。有了这个框架之后,我们可以根据自己的需要按图索骥找相关节点的资料来研究学习,不至于陷入细节找不到方向。当然,考虑到我们每个人的工作学习情况不同,平时遇到的问题也不同,本文内容无法覆盖所有人遇到的问题,欢迎大家留言提问,也欢迎关注「 IT老兵哥 」交流互动,谢谢!
本系列其他文章索引如下: