服务注册与发现
- 简介
- 服务注册与发现是微服务架构体系中最关键的组件之一。如果尝试着用手动的方式来给每一个客户端来配置所有服务提供者的服务列表是一件非常困难的事情,而且也不利于服务的动态扩容处理。Nacos Discovery可以帮助服务自动注册到Nacos服务端并且能够动态感知和刷新某个服务实例的服务列表。初次之外,Nacos Discovery也将服务实例自身的一些元素信息,例如:host、port,健康检查URL,主要等内容注册到Nacos。Nacos的获取和启动方式可以参考官网Spring到Spring Boot,随着Spring的不断发展,越来越多的组件集成到框架中。Spring框架也从一个小巧的IOC容器变成了一套大而全的框架集合。开发人员为了实现组件的整个工作,往往需要在xml文件、java注解中完成各种bean的配置,从而使的Spring的使用越来越难,大大降低了开发的效率。
使用Spring Boot可以大大的简化Spring应用的开发工作,在Spring Boot中无论官方组件还是框架都会提供各种start来方便开发者来依赖和集成。由于采用了依赖约定大于配置的思想,开发者可以做很少的配置工作就可以完成框架集成的工作,往往开发者只需要很少的代码量就可以实现以前大量配置文件才能做到的功能。
同时Spring Boot还是一套面向生产环境设计的框架,配置外化,运行情况检查功能,可以很方便的在系统外部实现对系统的管理。同时SpringBoot还是一个运行时容器。通过内嵌Tomcat等使程序的运行不在依赖传统的应用服务器。这一点在云原生很有 意义
Spring 官方对Spring Boot的特色如下:
- 创建独立的Spring的应用程序
- 直接嵌入Tomcat
- 提供依赖项,简化构件配置
- 尽可能自动配置Spring和三方类库
- 提供可用于生产的功能,例如指标,运行状况检查和外部化配置
- 完全没有代码生成,也不需要xml配置
spring官网的给出的架构图如下:
Spring Cloud是一系列Microservice,微服务的实现,围绕这些微服务做各种的辅助信息的功能。例如:分布式跟踪、服务注册、配置服务等,都围绕微服务所依赖的支持特性功能,Spring Cloud是以微服务为核心分布式系统的一个构件标准。
图中深色的部分,其实就是Spring Cloud的标准,一共有三层,中间颜色最深的部分就是整个微服务最核心的部分,包括了rpc调用一级服务注册与发现。第二层,也就是围绕着最核心的这一圈,是一些辅助微服务更好的工作,包括了负载均衡、路由、网关、断路器,还有就是追踪等等这些内容。再外层的话,主要是写分布式云环境里面的通用能力
最外面的这一圈,是Spring Cloud Alibaba对Spring Cloud的实现。右上部分是对于Spring Cloud标准的实现。
目前,Spring Cloud Alibaba包含以下组件:
开源部分:
- Sentinel:把流量作为切入点,从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性
- Nacos:一个更易于构建云原生应用的动态服务发现,配置管理和服务管理平台
- RocketMQ :一款开源的分布式消息系统,基于高可用分布式集群技术,提供低延时的、高可靠的消息发布与订阅服务
- Dubbo:Apache Dubbo是一款高性能JAVA RPC框架
- Seata:阿里巴巴开源产品,一个易于使用的高性能微服务分布式事务解决方案
平台服务部分
- Alibaba Cloud OSS:阿里云对象存储服务(Object Storage Service,简称OSS),是阿里巴巴提供的海量、安全、低成本、高可靠的存储服务。在任何应用、任何时间、任何地点存储和访问任意类型的数据。
- Alibaba Cloud Schedule X:阿里中间件团队开发一款分布式任务调度产品,提供秒级、精准、高可靠、高可用的定时任务调度服务
- Alibaba Cloud SMS:覆盖全球的短信服务、友好、高效、智能的互联化通讯能力,帮助企业迅速搭建客户触达通道
分布式配置
- 简介:
- Nacos提供用于存储配置和其他元数据的Key、Value存储,为分布式系统中的外部化配置提供服务器端和客户端支持。使用Spring Cloud Alibaba Nacos Config,可以在Nacos Server集中管理Spring Cloud应用的外部属性配置
- Spring Cloud Ablibaba Nacos Config是Config Server和Client的替代方案,客户端和服务器上的概念与Spring Environment和PropertySource有着一致的抽象,在特殊的bootstrap阶段,配置被加载到Spring环境中。当应用程序通过部署管道从开发到测试再到生产时,可以管理这些环境之间的配置,并确保应用程序具有迁移时需要运行的所有的内容。Nocos的获取和启动方式可以参考官网https://nacos.io/zh-cn/docs/quick-start.html
- 学习目标
- 使用Nacos Config作为Spring Cloud分布式配置
- 使用Nacos Config实现Bean动态刷新
- 了解Nacos Config高级配置
- 详细内容
- 快速上手,使用Nacos Config作为外部化配置源
- 多文件扩展名支持:以YAML文件扩展名为例,讨论Nacos Config多文件扩展名支持
- 动态配置更新:演示@ RefreshScope特性,实现Bean动态刷新
- 运维特性:演示Nacos config高级外部化配置以及Endpoint
分布式服务调用
- 简介
- 在《Spring Cloud Alibaba 服务注册与发现》篇中层提到,Spring Cloud Alibaba Nacos Discovery 能无缝整合Spring Cloud OpenFeign。换言之,Spring Cloud Alibaba 延续了Spring Cloud分布式服务调用的特性。除此之外,Spring Cloud Alibaba引入了Dubbo Spring Cloud,扩展了分布式服务调用的能力,不仅能使Apache Dubbo和OpenFeign共存,还允许Spring Cloud标准调用底层通过Dubbo支持的通讯协议传输。无论开发人员是Dubbo用户还是Spring Cloud用户,都能轻松地驾驭,并以接近“零”成本的代价使应用向上迁移。Dubbo Spring Cloud致力于简化Cloud Native开发成本,提高研发效能以及提升应用性能等目的
- 学习目标
- 使用Dubbo Spring Cloud实现Spring Cloud分布式服务调用
- 使用Dubbo Spring Cloud替换Spring Cloud分布式服务调用底层协议
- 理解Dubbo Spring Cloud高级特性:服务订阅、元数据、Actuator
- 详细内容
- 快速上手:使用Apache Dubbo
- 适配整合:使用注解@ Dubbo Transported适配Spring Cloud OpenFeign 和@ LoanBalanced RestTemplate
- 运维特性:演示服务订阅、元信息(服务、REST)以及Actuator Endpoints
- 功能特性
- 由于Dubbo Spring Cloud 构建在原生Spring Cloud只上,其服务治理方面能力可认为是Spring Cloud Plus,不仅完全覆盖Spring Cloud 原生特性,而且提供更为稳定和成熟的实现,特性比对如下所示
- Dubbo使用Spring Cloud服务注册与发现
- Dubbo使用Spring Cloud Commons抽象实现Dubbo服务注册与发现,无需添加任何外部化配置,就能轻易地桥接到所有原生Spring Cloud注册中心包括
- Nacos
- Eureka
- Zookeeper
- Consul
- 注意:Dubbo Spring Cloud将在下个版本支持Spring Cloud注册中心与Dubbo注册 中心并存,提供双注册机制,实现无缝迁移
- Dubbo使用Spring Cloud Commons抽象实现Dubbo服务注册与发现,无需添加任何外部化配置,就能轻易地桥接到所有原生Spring Cloud注册中心包括
- Dubbo作为Spring Cloud服务调用
- 默认情况下,Spring Cloud Open Feign以及@ LoanBalanced Rest Template作为Spring Cloud的两种服务调用方式。Dubbo Spring Cloud为其提供了第三种选择。即Dubbo服务将作为Spring Cloud服务调用的同等身份出现,应用可通过Apache Dubbo注解@Service和@ Reference暴露和引用Dubbo服务,实现服务间多种协议的通讯。同时,也可以利用Dubbo泛化接口轻松实现服务网关。
- Dubbo服务的自我检查
- Dubbo Spring Cloud引入了全新的服务治理特性---服务自我检查(Service Introspection),其设计目标在于最大化减少注册中心的负载处理,去Dubbo注册元信息中心化。假设一个Spring Cloud应用引入Dubbo Spring Starter,并暴露出现N个Dubbo服务,Dubbo的Nacos注册中心为例,当前应用注册N 1个Nacos应用,除Spring Cloud应用本身之前,其余N个应用均来自与Dubbo服务,当N数字越大的时候,注册中心的负载越来越大。因此,Dubbo Spring Cloud应用对注册中心的负载相当于传统Dubbo的N分之一,在不增加基础设施投入的前提下,理论上,整个集群的规模越来越大,当然,未来的Dubbo也将提供服务自我检查的能力
- Dubbo迁移Spring Cloud服务调用
- 尽管Dubbo Spring Cloud完全地保留了原生Spring Cloud服务调用特性,不过Dubbo服务治理的能力是Spring Cloud Open Feign所不能比较的,如高性能、高可用以及负载均衡稳定性等。因此,建议开发人员将Spring Cloud Open Feign或者@ LoadBalanced RestTemplate迁移为Dubbo服务。考虑到迁移过程并非一蹴而就的 ,因此Dubbo Spring Cloud提供了解决方案,即Dubbo Transported注解。该注解能够帮助服务消费端的Spring Cloud Open Feign接口以及@ LoadBalanced TemplateBean底层走Dubbo调用,而服务提供方则只需在原有的@ RestController类上追加Dubbo @ Service注解即可,换句话说,在不调整Feign接口以及RestTemplateURL的前提下,实现无缝迁移。如果迁移时间充分的话,建议使用Dubbo服务重构系统中的原生Spring Cloud服务的定义。
快速上手Dubbo Spring Cloud
- 如何引入Dubbo Spring Cloud
- Dubbo Spring Cloud引入的方式通常有两种,由易到难分别为:Aliyun Java Initializr引入和Maven pom.xml依赖。官方推荐的使用Aliyun Java Initializr方式引入Dubbo Spring Cloud,以简化组件之间的依赖。
- 下面主要介绍通过pom.xml依赖的方式进行引入
通过Maven pom.xml依赖Dubbo Spring Cloud
该声明方式同样需要声明com.alibaba.cloud:Spring-cloud-alibaba-dependencies,内容与上面一致。
使用Dubbo Spring Cloud构件服务提供者
- 定义Dubbo服务接口
- Dubbo服务接口是服务提供方与消费方的远程通讯契约,通常由普通的Java接口(Interface)来声明,如EchoService接口
- 该方法仅有一个方法,接下来将Dubbo-sample-api部署到本地
- 部署artifact-dubbo-sample-api
- 利用Maven命令,将Dubbo-sample-api,部署到本地Maven仓库:% mvn clean install
本地部署成功后,该artifact能被Dubbo服务提供者应用Dubbo-provider-sample依赖
...
- 依赖artifact-dubbo-sample-api
- artifact dubbo-saple-api依赖信息添加到应用dubbo-provider-sample中的pom.xml
- 实现Dubbo服务
- 在应用Dubbo-provider-sample中的com.alibaba.cloud.dubboprovidersample包下创建实现类
其中,@ org.apache.dubbo.config.annotation.Service是Dubbo的服务注解,仅仅声明该Java服务实现为Dubbo服务。因此,下一步需要将其配置到Dubbo远程服务
配置Dubbo服务提供方
- Dubbo指定Java服务实现类的扫描包,Dubbo Spring Cloud集成了Dubbo Spring Boot的外部化配置特性,也可以通过标注@ DubboComponentScan来实现基准包扫描,同时,Dubbo远程服务需要暴露网络端口,并设定通讯协议,完整的bootstrap.yaml配置如下
以上,Yaml文件的内容,上半部分为dubbo的配置
--dubbo.scan.base-packages:指定dubbo服务实现类的扫描基准包
--dubbo.protrol:Dubbo服务暴露的协议配置,其中的属性name为协议的名字
port为协议的端口,(-1表示自增端口,从20880开始算)
下半部分则是Spring Cloud相关配置
--spring.application.name:Spring应用名称,用于Spring Cloud服务注册和发现
该值在Dubbo Spring Cloud加持下被看作是dubbo.application.name,因此,无需再次显示出来配置dubbo.application.name
--spring.cloud.nacos.discovery:Nacos服务注册与发现的配置,其中子属性server-addr指定Nacos服务器的主机和端口
完成上述的步骤之后,还需要编写一个Dubbo Spring Cloud的引导类
引导Dubbo Spring Cloud服务提供方的应用
- Dubbo Spring Cloud引导类与普通Spring Cloud应用并无差别,如下所示
在引导DubboProviderSampleApplication之前,需要提前启动Nacos服务器,当DubboProviderSampleApplication启动后,将应用dubbo-provider-sample将出现在Nacos控制台界面
当Dubbo服务提供方启动后,下一步实现Dubbo服务消费方的应用
使用Dubbo Spring Cloud实现Dubbo服务消费方的应用
- 由于Java服务仅为EchoService、服务提供方应用dubbo-provider-sample以及Nacos服务器均已开发启动完毕。由于应用创建的步骤类似,构件消费方应用dubbo-consumer-sample的操作不在重复
- 依赖artifact-dubbo-sample-api,与服务提供方的maven工程类,需要添加artifact dubbo-sample-api依赖,完整组件Maven依赖:
- 配置dubbo服务消费方,Dubbo服务消费方配置与服务提供方类似,当前应用Dubbo-consumer-sample属于纯服务消费方,因此,所需的boostrp.yaml文件配置更精简
对比应用dubbo-provider-sample,除应用名称spring.application.name存在差异外,dubbot-consumer-sample新增了属性dubbo.cloud.subscribed-services的设置,并且该值服务提供者应用,dubbo-provider-sample。用于服务消费方订阅服务提供方的应用名称列表,若需要订阅更多的应用,使用“,”分割。不推荐使用默认值“*”,它将订阅所有应用。
当应用使用属性dubbo.cloud.subscribed-services默认值时,日志中将会出现警告。
引导Dubbo Spring Cloud服务消费方应用
- 为了减少实现步骤,编辑引导类DubboConsumerSampleApplication将Dubbo服务消费以及引导功能合二为一:
Dubbo服务提供方应用dubbo-provider-sample的EchoService计算结果返回dubbo-consumer-sample中的REST资源echo,同事dubbo-provider-sample应用日志出现了内容;说明Dubbo服务消费端应用dubbo-consumer-sample端口向服务提供方应用dubbo-provider-sample建立连接
服务熔断和限流
为什么要流控降级
- 我们生产环境经常会出现一些不稳定的情况,如
- 秒杀的时候瞬间流量导致系统超出最大负载,load超过,导致的系统崩溃,用户无法下单
- “黑马”热电商品击穿缓存,DB被打垮,抢占了正常的流量
- 调用端被不稳定的服务拖垮,线程池被沾满,导致了整个调用链卡顿死机
这些不稳定的场景可能会导致严重的后果。可想而知,如果做到均匀平滑的用户访问,如果预发流量过大或服务不稳定带来的影响,这个时候就需要考虑高可用的防护,其中重要的手段是流量控制和熔断降级,可以保障微服务的稳定性的重要一环。
为什么要流量控制?
- 流量是非常随机的,不可预测的,前一秒可能还稳定,后一秒可能就出现了流量洪峰。我们系统的容量是有限的,如果突然而来的流量超过了系统的承受能力,就可能会导致请求不过来,堆积的请求处理缓慢,cpu和内存超高,导致系统的崩溃。因此,我们需要针对这种突发的流量来进行限制,在尽可能处理请求的同时来保障服务不被打垮,这个就是流量的控制