微服务架构核心概念
微服务架构
-
微服务是一种分布式系统架构,是一种思想,是一种设计原则。通过springboot来创建服务,而Spring Cloud是关注全局的服务治理框架。
-
springboot不是微服务
就目前而言对于微服务,业界没有一个统一的标准定义。但通常而言,微服务是一种架构模式或者说是一种架构风格,它提倡单一应用程序划分为一组小的服务,每个服务在其独立的自己的进程中,服务之间相互协调,互相配合,为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通(基于Http的Restful API)每个服务都围绕着具体的业务进行构建,并且能够被独立的部署到生产环境,在生产环境进行构建,可以有一个非常轻量级的集中式管理来协调这些服务,可以使用不同的语言来编写服务,也可以使用不同的数据存储。
优势
-
复杂度可控:即便再复杂的应用开发,我们把它拆分成多个小的微服务,就很简答的进行分组开发,大大的提高效率。
-
独立部署:由于微服务具备独立的运行进程,所以每个微服务也可以独立部署。
-
容错性能好:因为单个服务,所以即便出了故障,那么我们bug也会仅仅停留在某个服务中,不会影响其他服务的正常使用。
-
扩展性高:我们需要什么功能直接增加服务就好了。
缺点
-
增加运维成本:更多服务意味着更多的运维投入,在单体架构中,只需要保证一个应用的运行即可,在微服务架构中,需要保证几十甚至几百个服务器的正常运行和协作。
-
增加了资源使用:运行这些微服务架构的应用的初始投资会比较大,因为所有微服务应都需要拥有他们自己的运行容器,这也需要更多的CPU和内存。另外采用了中间件也会带啦一个比较大的基座投资。
-
团队沟通的过载:微服务架构降低了团队管理的难度,但是确不能降低团队沟通的需求。研发人员需要确保一个服务中的更新不会破坏其它功能。我们在单体应用中也会发现类似问题,但是微服务架构的应用这个问题会更加明显。
-
增加了网络通信开销:分布式系统的产生的网络开销比单机应用多很多,不能简单把内部调用简单改为分布式调用,吃亏很大。微服务架构下,独立运行的组件都需要通过网络进行互相通信。这中系统需要有更加可靠和快速的网络连接。
-
系统复杂性增强:使用微服务架构的是分布式系统。对于一个分布式系统,系统容错、网络延迟、消息序列化、不可靠的网络、异步机制、版本化、差异化都会带来巨大挑战。
应用场景:
-
淘宝+支付宝+微信+微博(目前苹果或者安卓系统手机上的应用,基本上都是微服务架构,其业务模式决定了架构不可能采用一种单体架构取解决所有问题。)
-
电商类、微博微信社交类、支付类、直播类、游戏类等业务都适合,一个架构的拆分,本质上反映的是一个业务的拆分。
Spring Cloud 是什么
-
基于SpringBoot提供了一套微服务(microservices)解决方案,包括服务注册与发现。
-
是分布式微服务架构下的一站式解决方案,是各个微服务架构落地技术的结合体,俗称为微服务全家桶。
-
spring cloud 为开发者提供了一套快速开发分布式系统的组件,Spring Cloud并不推荐重复造轮子,主张利用Spring Boot将其他公司较成熟的组件进行封装。
Spring Cloud 与 Spring Boot的关系和区别
-
SpringBoot专注于方便的开发单个个体微服务。
-
SpringCloud是关注于全局的微服务协调治理框架,它将SpringBoot开发的一个个单体微服务整合并管理起来,为各个微服务之间提供配置管理、服务发现、断路器、路由、微代理、事件总线、决策竞选、分布式会话等集成服务。
-
SpringBoot可以离开SpringCloud单独使用,而SpringCloud离不开SpringBoot。
Spring Cloud 核心概念
配置中心
微服务系统中,存在很多功能开关和各种参数的配置项,传统的配置文件、数据库等方式无法满足开发人员对配合管理的需求,此时,分布式配置中心应运而生。
特点:
-
统一管理
配置中心服务端负责配置的管理(新增、修改、删除、发布),集成了配置中心客户端的微服务程序可以统一从配置中心服务端拉取配置,从而实现整个微服务系统的统一配置管理。 -
区分环境
一个微服务应用中的某些配置项,在不同的环境(开发、测试、生产)通常是不同的,作为分布式配置中心需要具有隔离不同环境的功能,使得同一个微服务在不同环境能拉取到对应的配置。 -
实时刷新
当配置中心服务端中的配置发生了修改时,配置中心客户端需要能实时监听到配置的改变,使得微服务应用程序可以实时获取到最新配置,并且不用重新部署应用程序。 -
权限控制
在配置中心中,可以针对不同的角色或用户设置对应的权限,比如张三可以新建配置项,但不能发布配置;比如小明可以查看配置项,但不能修改配置 -
版本控制
在使用配置中心的过程中,难免会出现误操作,而这个时候就需要进行版本回退,所以作为配置中心,是一定要支持版本控制的。 -
灰度发布
在需要发布一项配置时,如果需要发布到多个实例(集群),那么此时可以指发布到部分实例,待测试通过后,再发布到全部实例,这就是配置的灰度发布。
常用配置中心组件
-
Spring Cloud Config
-
阿里Nacos
-
Nacos默认内置配置中心,配置信息采用存储保存在指定的数据库中
-
携程Apollo
-
谷歌consul
注册中心
注册中心相当于微服务架构中的地址通讯录,每个微服务会将服务及其地址注册到注册中心,服务消费者在调用某个微服务之前会先从注册中心查找服务地址,然后进行调用
特点
-
服务的自动注册
微服务应用在启动时,通过注册中心客户端组件,将服务相关信息自动注册给注册中心服务端。 -
服务的健康检查
当已经注册到注册中心的微服务实例宕机后,注册中心服务端能发现实例已经宕机,并把相关的信息从注册中心删除掉。 -
服务的自动发现
服务消费者需要能实时监听到注册中心中服务信息的变更,以能在真正调用服务时不会出现错误。
常见注册中心组件
-
Zookeeper
-
Eureka
-
Nacos
-
Consul
服务网关
服务网关是整个微服务架构中对外的统一入口,所有的客户端都通过统一的网关是用微服务,服务网关起到了隔离外部访问和内部系统的作用,服务网关是微服务架构中的一个标配组件。
特点
-
高并发
作为微服务架构中的对外入口,必须能支持高并发,能承担更高的并发量,并保证高性能 -
安全
服务网关通常具有权限认证,黑名单、白名单等保证网关安全的功能。 -
路由转发
服务网关接收到外部请求后,要求服务网关能根据请求和配置将请求转发到对应的后端微服务上去。 -
监控与限流
作为整个系统的流量入口,服务网关要能监控流量情况,遇到突发情况时能及时限流,保证整个系统的稳定。 -
灰度发布
当某个微服务有新版本更新上线时,可以利用服务网关进行流量的切换,实现该微服务的灰度发布。 -
服务重试
当服务网关调用某个微服务失败后,可以通过服务网关设置重试策略来重新尝试调用该服务。 -
服务别名
可以在服务网关中给某个或某些微服务设置别名,从而对外屏蔽内部微服务相关信息。
常见服务网关组件
-
Kong
-
Zuul
Gateway网关架构图
图1:
图2:
图3:
负载均衡
负载均衡是指将访问流量根据负载均衡算法分发到后端服务器的流量分发控制服务,通过负载均衡可以提高微服务的可用性以及性能。
常见负载均衡算法
-
简单轮询
将请求按顺序分发给后端服务器上,不关心服务器当前的状态,比如后端服务器的性能、当前的负载 -
加权轮询
根据服务器自身的性能给服务器设置不同的权重,将请求按顺序和权重分发给后端服务器,可以让性能高的机器处理更多的请求 -
简单随机
将请求随机分发给后端服务器上,请求越多,各个服务器接收到的请求越平均 -
加权随机
根据服务器自身的性能给服务器设置不同的权重,将请求按各个服务器的权重随机分发给后端服务器 -
一致性hash
根据请求的客户端ip、或请求参数通过哈希算法得到一个数值,利用该数值取模映射出对应的后端服务器,这样能保证同一个客户端或相同的参数的请求每次都使用同一台服务器 -
最小活跃数
统计每台服务器上当前正在处理的请求数,也就是请求的活跃数,将请求分发给活跃数最少的后台服务器
常见的负载均衡组件
-
nginx
-
lvs
-
ribbon
-
Nacos服务端均衡
- 与Ribbon在调用端负载均衡不同,Nacos是在服务发现的同时利用负载均衡返回服务节点数据
RPC调用
RPC就是远程过程调用,对于java程序而言,RPC就是远程方法调用,表示一个方法调用远程的另一个方法,微服务架构中一个服务调用另外一个服务就可以用RPC调用。
RPC原理
在RPC框架中主要有三个角色:提供者、消费者和注册中心。
如下图所示:
- 提供者: 暴露服务的服务提供方。
- 调用者: 调用远程服务的服务消费方。
- 注册中心: 服务注册与发现的注册中心。
原理图如上,假设目前有两台服务器A和B,一个应用部署在A服务器上,想要调用B服务器上应用提供的函数/方法,由于不在一个内存空间,不能直接调用,需要通过网络来表达调用的语义和传达调用的数据。
RPC整个调用过程,主要经历如下几个步骤:
- 建立通信:A机器想要调用B机器,首先得建立起通信连接。
- 服务寻址:A服务器上的应用怎么告诉底层的RPC框架,如何连接到B服务器(如主机或IP地址)以及特定的端口,方法的名称是什么。
- 网络传输:当A机器上的应用发起一个RPC调用时,调用方法和其入参等信息需要通过底层的网络协议如TCP传输到B机器。
- 服务调用:B机器进行本地调用(通过代理Proxy)之后得到了返回值,此时还需要再把返回值发送回A机器。
RPC调用与http调用的区别
-
http调用使用的是http协议,是网络7层中的应用层协议,http协议规定了数据传输的格式,Restful风格就可以通过http协议来实现;
-
RPC不是网络层面的协议,而是更上层的更灵活的通信协议,RPC调用可以自定义数据格式、数据传输方式,只要能保证调用的远程方法即可。
常用的RPC调用组件或框架
-
Dubbo
- Alibaba默认对自家的RPC框架Dubbo也给予支持,为服务见通讯提供了另一种选择;其功能主要包括:高性能NIO通讯及多协议集成,服务动态寻址与路由,软负载均衡与容错,依赖分析与降级等。
-
gRPC
- gRPC是一个高性能、开源和通用的 RPC 框架,基于ProtoBuf(Protocol Buffers) 序列化协议开发,且支持众多开发语言。面向服务端和移动端,基于 HTTP/2 设计,带来诸如双向流、流控、头部压缩、单 TCP 连接上的多复用请求等特。这些特性使得其在移动设备上表现更好,更省电和节省空间占用。
-
Thrift
- thrift是一个软件框架,用来进行可扩展且跨语言的服务的开发。它结合了功能强大的软件堆栈和代码生成引擎,以构建在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 这些编程语言间无缝结合的、高效的服务。
-
Feign
- feign 是一种声明式的 HTTP 客户端,用于简化对 RESTful API 的调用。它的主要使用场景是在微服务架构中,通过 HTTP 协议调用其他服务的 RESTful API。Feign 支持多种编解码器,如 Jackson、Gson、JAXB 等,可以将请求和响应转换成对象。Feign 还提供了负载均衡和服务发现功能,可以通过 Eureka、Consul 等服务注册中心来自动发现和负载均衡服务。
服务熔断
服务熔断是指,当服务A调用的某个服务B不可用时,上游服务A为了保证自己不受影响,从而不再调用服务B,直接返回一个结果,减轻服务A和服务B的压力,直到服务B恢复。
常见熔断器组件
-
Hystrix
-
Sentinel
-
Sentinel功能更为强大,实现系统保护相较Hystrix更加优雅,而且拥有更友好的管理UI
熔断器的三种状态
-
Closed:关闭状态
当调用失败次数达到阈值时则启动熔断器 -
Open:状态
此时不会真正的调用下游服务,而是直接返回,当过了 某段时间后,熔断器会进入到半打开状态 -
Half-Open:半打开状态
此时会有部分请求访问下游服务,如果这些请求都调用成功了,则认为下游服务恢复了,那么则关闭熔断器,否则熔断器回到打开状态
服务降级
当发现系统压力过载时,可以通过关闭某个服务,或限流某个服务来减轻系统压力,这就是服务降级。
服务降级和服务熔断的区别
-
都是为了防止系统崩溃
-
都让用户体验到某些功能暂时不可用
-
熔断是下游服务故障触发的,降级是为了降低系统负载
服务雪崩
服务A调用服务B,服务B调用服务C,此时大量请求突然调用服务A,假如服务A能扛住这些请求,但是服务C扛不住,导致服务C请求堆积,从而服务B请求堆积,从而服务A不可用,这就是服务雪崩,解决方式就是服务降级和服务熔断。
服务限流
服务限流是指在高并发请求下,为了保护系统,可以对访问服务的请求进行数量上的限制,从而防止系统不被大量请求压垮,在秒杀中,限流是非常重要的。
常用的限流算法
-
固定窗口计数器
-
滑动窗口计数器
-
令牌桶
-
漏桶
全局锁
全局锁就是我们常说的分布式锁,是分布式、微服务架构中的一种锁机制,通过全局锁可以很好的在分布式系统中互斥使用共享资源。
全局锁的实现原理
-
Zookeeper:利用Zookeeper的watch机制与临时节点特性
-
Redis:利用Redis的消费订阅机制与数据超时特性
常用的全局锁组件
-
Redisson
-
Curator
控制总线
控制总线也称为消息总线,是微服务系统中用来连接系统中所有服务节点的,微服务中的所有服务节点可以通过控制总线来进行通讯
应用场景
- 目前,Spring Cloud Bus 就是控制总线的具体实现,某个微服务可以通过Spring Cloud Bus来广播事件,而其他微服务可以接收到事件并进行相关处理。
消息队列
组件
-
RabbitMQ
-
ActiveMQ
-
Kafka
-
RocketMQ:Spring Cloud Alibaba在原有Spring Cloud支持的MQ前提下,对自己的消息队列产品RocketMQ进行集成
分布式事务
在一次请求中,所涉及的分散在多个微服务上的操作要保证同时成功或同时失败,这就是分布式事务。
实现分布式事务的方式
-
直接通过数据库
-
通过消息队列
-
两阶段提交
-
三阶段提交
分布式事务中的三个角色
-
事务协调器
-
事务管理者
-
资源管理者
常用的分布式事务框架
-
seata
- seata是Alibaba开源分布式事务中间件,内置AT、TCC与SAGA三种模式适用不同的分布式事务场景
-
Icn
-
bytetcc
分布式存储
组件
-
Alibaba Cloud OSS
- 阿里云对象存储服务,是阿里云提供的海量、安全、低成本、高可靠的云储存服务
-
FastDFS
服务安全
对于一个企业来说,微服务系统中的服务安全性越来越重要,服务的认证和授权是企业必须具备的,spring cloud security是Spring Cloud提供的微服务安全组件。
特性
-
可扩展、可配置的认证和授权
-
单点登录
-
防止会话固定、点击劫持、跨网站请求伪造攻击
-
与Servlet API集成
链路追踪
链路追踪为微服务系统提供了完整的调用链路还原、调用请求量统计、链路拓扑、应用依赖分析等功能,可以帮助开发者快速分析和诊断微服务架构下的性能瓶颈。
功能
-
分布式调用链查询和诊断
-
应用性能实时汇总
-
分布式拓扑动态发现
-
多语言开发程序接入
-
丰富的下游对接场景
常用的链路追踪技术
-
Sleuth
-
Zipkin
集群管理
对于微服务系统中的某个服务集群所提供的针对集权管理的功能,Spring Cloud Cluster的职责就是集群管理
功能
-
领导者选举
-
一致性存储
-
集群状态管理
-
一致性tokens
事件驱动
事件驱动就是消息驱动,在Spring Cloud中提供了Spring Cloud Stream来实现事件驱动,有了事件驱动,在微服务系统中可以方便的通过发送消息来进行通信。
目标绑定器
- 目标指的是kafka或rabbitmq
绑定桥梁
- 连接消息系统和应用程序
消息
- 应用程序和消息系统之间传递的数据
特点:
-
异步处理
-
流量削峰
-
服务解耦
任务调度
组件
- Alibaba Cloud SchedulerX
- 阿里中间件团队开发的一款分布式任务调度产品,提供秒级、精准、高可靠、高可用的定时调度服务
云连接器
云连接器可以用来更方便的连接部署在云上的各种服务,Spring Cloud中Spring Cloud Connectors就是云连接器的组件实现
目前支持多的云平台
-
Spring Cloud Cloud Foundry
-
Spring Cloud Heroku
函数计算
函数j计算也称为函数式编程,是实现Serverless的一种手段,企业如果能使用函数计算能大大节约成本,在Spring Cloud中提供了Spring Cloud Function来开发基于云平台的函数计算
特点:
-
支持响应式等编程风格
-
输入输出类型透明转化
-
流数据处理
-
同一个jvm中运行多版本函数
-
打包函数到指定云平台