1.什么是微服务
微服务是一种架构模式或者说是一种架构风格
它提倡将单一应用程序划分成一组小的服务,每个服务运行在其独立的自己的进程中,服务之间互相协调、互相配合,为用户提供最终价值。 服务之间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。每个服务都围绕着具体业务进行构建,各服务可以由不同语言编写,数据存储在不同的数据库,并且能够被独立地部署到生产环境、类生产环境等。
微服务化的核心就是将传统的一站式应用,根据业务拆分成一个一个的服务,彻底地去耦合,每一个微服务提供单个业务功能的服务,一个服务做一件事,从技术角度看就是一种小而独立的处理过程,类似进程概念,能够自行单独启动或销毁,拥有自己独立的数据库。
2.什么是分布式
分布式不是开发方式,而是一种部署方式
就是说,在分布式服务中,一个服务可能负责几个功能,系统应用部署在超过一台服务器或虚拟机上,服务之间通过rpc来交互或者是webservice来交互的。生产环境下的微服务肯定是分布式部署的,但是分布式部署的应用不一定是微服务架构的,比如集群部署,它是把相同应用复制到不同服务器上,但是逻辑功能上还是单体应用。
3.什么是集群
集群既不是开发模式也不是部署模式,而是一种运行模式
多台主机提供相同的服务的一组序列就叫集群 简单地说,集群就是指一组(若干个)相互独立的计算机,利用高速通信网络组成的一个较大的计算机服务系统,每个集群节点(集群系统中的单个计算机通常称为节点)都是运行各自服务的独立服务器。在某种意义上,他们可以被看作是一台计算机。这些服务器之间可以彼此通信,协同向用户提供应用程序,系统资源和数据,并以单一系统的模式加以管理。集群计算机通常用来改进单个计算机的计算速度或可靠性。
集群的分类
集群的分类一般根据功能的不同分为高可用集群和负载均衡集群
负载均衡集群
目的是提升效率,一个人处理不过来就两个人,两个人处理不过来就三个人 工作时,一般通过一个或者多个调度器将客户端访问请求发到后端一组服务器上 这里会涉及到一个东西叫反向代理,方向代理和负载均衡是成双成对的,不可能单独出现的。
高可用集群
目的是保证关键性业务的可靠性,一主一备,平时主工作,备不工作,等到主挂了,备才会工作 高性能集群 一般都是政府用于科学研究、算法
4.什么是Spring-Cloud-Alibaba
在微服务提出时,就引入了几个问题:
- 服务间交互问题, 各模块之间一般以接口方式调用, 选择合适的通讯协议, 制定接口的输入输出规范
- 服务的发布订阅问题: 服务需要有个类似登记的地方, 即注册中心
- 服务监控问题: 需要一个贯穿业务埋点 数据收集 数据处理和展示的监控, 需要监控qps(调用量), avgtime(平均耗时), 以及p999(99.99%请求的耗时)
- 服务治理问题: 服务间依赖变的复杂, 减少依赖的影响, 增加服务熔断, 设定一个阈值, 一旦超过这个值直接返回
- 故障定位问题: 服务相互依赖, 在出现问题时, 如何快速定位那个服务的问题, 需要进行标记
拆分颗粒度问题: 不易过细, 难以治理, 一个人三个为准较为合理
spring-cloud-alibaba 是阿里巴巴开发的一个开源的分布式部署微服务架构的一站式解决方案,是多种微服务架构落地技术的集合体,俗称微服务全家桶。
5.Spring-Cloud-Netflix和Spring-Cloud-Alibaba以及Dubbo的区别
spring-cloud是基于微服务的常见四个问题提出的一站式解决方案
- 服务很多,客户端该怎么访问?
- 这么多服务,服务之间如何通信?
- 这么多服务, 如何治理?
- 服务挂了怎么办?
所以Spring-Cloud 本身是一套微服务规范,并不是一个拿来即可用的框架
为此netflix基于Spring-Cloud规范开发了Spring-Cloud-netflix(一站式解决方案)开箱即用,然而阿里巴巴推出了 Apache Dubbo zookeeper (半自动,需要整合别人的!) Dubbo (RPC) zookeeper (注册中心) , 后来netflix不再维护Spring-Cloud-netflix相关组件,继而阿里巴巴又推出了spring-cloud-alibaba (一站式解决方案)开箱即用,比netflix更加简单易用
spring-cloud-netflix
spring-cloud-netfix 提供了一站式的解决方案;
- 服务注册中心:Spring Cloud Netflix Eureka
- 服务调用方式: REST API
- 服务网关: Spring Cloud Netflix Zuul
- 断路器: Spring Cloud Netflix Hystrix
- 分布式配置: Spring Cloud Config
- 服务跟踪: Spring Cloud Sleuth
- 消息总线: Spring Cloud Bus
- 数据流: Spring Cloud Stream
- 批量任务: Spring Cloud Task
现在已经不维护了;
spring-cloud-alibaba
- 注册中心:Alibaba Nacos
- 负载均衡:Nacos服务端均衡
- 服务通信:Netfilix Feign
- API服务网关:Spring Cloud Gateway
- 配置中心:Nacos内置配置中心
- 集中式日志管理:阿里云日志服务 LOG
- 分布式链路追踪:Sleuth/Zipkin Server
- 系统保护:Alibaba Sentinel
- 消息队列:RocketMQ
- 分布式事务:Alibaba Seata
- 任务调度:Alibaba Cloud SchedulerX
- 分布式存储:Alibaba Cloud OSS
6.spring-cloud-alibaba 核心组件介绍
概览
Spring Cloud Alibaba是国产的微服务开发一站式解决方案,与原有 Spring Cloud 兼容的同时对微服务生态进行扩展,通过添加少量的配置注解,便可实现更符合国情的微服务架构。
其核心组件有:
- Nacos:主要的功能有注册中心和配置中心,可以代替 Eureka 和 Apollo 两个组件;
- Sentinel:可实现流量控制、熔断降级、系统负载保护等,比Hystrix功能更加丰富;
- Dubbo:高性能的RPC通信框架;
- Seata:提供高性能和简单易用的分布式事务服务;
- Spring Cloud Gateway:高性能异步非阻塞网关;
- RocketMQ:高性能、高可靠的消息中间件。
Nacos
- Nacos 是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。主要的功能有注册中心和配置中心。
- Nacos可以同时作为注册中心和配置中心,默认情况注册中心采用Distro协议(AP),配置中心采用Raft(CP);
- Nacos client可以通过ephemeral属性设置节点为临时节点或持久节点,临时节点对应了Distro协议,持久节点对应Raft协议;
注册中心Nacos
- Distro协议是为了注册中心而创造出的协议,与Eureka类似,是一种无中心化、无持久化的AP协议;
- 服务提供者通过Nacos 客户端向服务端 Naming Service 注册临时节点,然后通过心跳连接与服务端集群保持通信;
- 服务端节点都存储所有数据,但每个节点只负责其中一部分服务的事务操作,如果一个节点收到的请求不是自己负责,则将请求转发给对应的节点处理,写入后再异步同步给其它节点;
- 当服务端节点信息发生变更时,会基于udp协议向服务消费者push变更信息,同时客户端也会通过以10s为周期的定时任务去服务端检查变更;
配置中心Nacos
- 配置中心基于Raft协议实现事务写入的强一致性,事务请求由Leader节点处理,Follower节点只处理非事务请求;
- Leader选举的时机有两个:一是集群初始化时,二是Leader宕机时;
- 客户端以长轮询方式拉取服务端的配置变更,配置变更是基于MD5比较,如果没有发生变更,长轮询请求会被服务端加入队列(超时时间为29.5s),有变更时再将结果设置到请求的response中返回给客户端;
- 服务端配置信息默认基于MySQL进行持久化存储;
Sentinel
Sentinel 阿里的分布式服务架构的轻量级高可用流量控制组件, 以流量为切入点,从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。Sentinel 比Hystrix功能更加丰富,可基于控制台进行实时监控与实时规则修改。
Sentinel 分为两个部分:
- 核心库(Java 客户端)不依赖任何框架/库,能够运行于所有Java运行时环境,同时对Dubbo, Spring-Cloud 等框架也有较好的支持。
- 控制台(Dashboard)基于Spring-Boot开发,打包后可以直接运行,不需要额外的Tomcat等应用容器。
限流
流量控制有以下几个角度:
- 资源的调用关系,例如资源的调用链路,资源和资源之间的关系;
- 运行指标,例如 QPS、线程池、系统负载等;
- 控制的效果,例如直接限流、冷启动、排队等。
熔断降级
Sentinel 采用了与Hystrix 不一样的方法:
- 通过并发线程数进行限制(Hystrix 采用线程池隔离,需要预先创建线程池);
- 通过响应时间对资源进行降级。
控制台
Sentinel 控制台基于Spring Boot 开发,打包后可直接运行。它提供机器发现以及健康情况管理、监控(单机和集群),规则管理和推送的功能。
动态规则扩展
Sentinel 提供两种方式修改规则:
- 通过API直接修改(loadRules),这种方式只修改内存数据,一般线上环境不推荐;
- 通过DataSource适配不同数据源修改,例如集成Nacos、Apollo、Zookeeper等,这样一来控制台便可以将变更的规则推送到统一的规则中心做持久化存储。
Seata
Seata 是一款开源的分布式事务解决方案,致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式,为用户打造一站式的分布式解决方案。
AT模式
AT 模式基于支持本地 ACID 事务的关系型数据库,是一种无侵入弱一致的2pc模式:
- 一阶段 prepare 行为:在本地事务中,一并提交业务数据更新和相应回滚日志记录。
- 二阶段 commit 行为:马上成功结束,自动异步批量清理回滚日志。
- 二阶段 rollback 行为:通过回滚日志,自动生成补偿操作,完成数据回滚。
关于读写的隔离:
- 写隔离:AT模式会基于全局锁保证写隔离,事务操作必须获取到全局锁才能执行commit或rollback, 获取 不到会重试直到超时,超时后会回滚本地事务,以此避免脏写;
- 读隔离:AT模式默认的读隔离级别为读未提交,出于性能考虑,一般的SELECT语句都不会阻塞, 目前只对 SELECT FOR UPDATE语句进行全局锁控制。
TCC模式
TCC 模式不依赖于底层数据资源的事务支持:
- 一阶段 prepare 行为:调用自定义的 prepare 逻辑。
- 二阶段 commit 行为:调用自定义的 commit 逻辑。
- 二阶段 rollback 行为:调用自定义的 rollback 逻辑。
Saga模式
Saga模式是SEATA提供的长事务解决方案,在Saga模式中,业务流程中每个参与者都提交本地事务,当出现某一个参与者失败则补偿前面已经成功的参与者,一阶段正向服务和二阶段补偿服务都由业务开发实现。
适用场景:
业务流程长、业务流程多; 参与者包含其它公司或遗留系统服务,无法提供 TCC 模式要求的三个接口。 优点:
一阶段提交本地事务,无锁,高性能; 事件驱动架构,参与者可异步执行,高吞吐; 补偿服务易于实现。
缺点:
不保证隔离性(回滚时发现数据已被修改,导致无法回滚)。
XA模式
XA模式是分布式强一致性的解决方案,但性能低而使用较少,很多模式都是基于XA进行改进。
Spring Cloud Gateway
Spring Cloud Gateway 是 Spring 自己开发的新一代 API 网关产品。它基于 NIO 异步处理,摒弃了 Zuul 基于 Servlet 同步通信的设计,因此拥有更好的性能。
关键特性
基于 Spring Framework 5 + Project Reactor + Spring Boot 2.0 构建; 支持动态路由,能够匹配任何请求属性上的路由; 支持基于 HTTP 请求的路由匹配(Path、Method、Header、Host 等); 过滤器可以修改 HTTP 请求和 HTTP 响应(增加/修改 Header、增加/修改请求参数、改写请求 Path 等等); 核心概念 Gateway 网关三个关键名词:路由(Route)、断言(Predicate)、过滤器(Filter)。
Route:路由
是指一个完整的网关地址映射与处理过程。一个完整的路由包含两部分配置:断言(Predicate)与过滤器(Filter)。前端应用发来的请求要被转发到哪个微服务上,是由断言决定的,而转发过程中请求、响应数据被网关如何加工处理是由过滤器决定的。 Predicate:断言,指定了路由的规则条件; Filter:过滤器,可以在请求发出的前后执行一些业务处理,如鉴权、限流、埋点等。
负载均衡:Gateway
Gateway可以基于Ribbon来实现对请求URL的负载均衡,请求列表可以是配置的静态列表,也可以通过集成Nacos来实现动态列表的获取