微服务架构是一种架构模式或者说是一种架构风格,它提倡将单一应用程序划分为一组小的服务,每个服务运行在其独立的自己的进程中,服务之间相互协调、互相配合,为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API),每个服务都围绕着具体的业务进行构建,并且能够被独立的构建在生产环境、类生产环境等。另外,应避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建,可以有一个非常轻量级的集中式管理来协调这些服务,可以使用不同的语言来编写服务,也可以使用不同的数据存储。
通俗地来讲:
微服务就是一个独立的职责单一的服务应用程序。在 intellij idea 工具里面就是用maven开发的一个个独立的module,具体就是使用springboot 开发的一个小的模块,处理单一专业的业务逻辑,一个模块只做一个事情。
微服务强调的是服务大小,关注的是某一个点,具体解决某一个问题/落地对应的一个服务应用,可以看做是idea 里面一个 module。
微服务优点很多,但是我们通常说一个东西好肯定会跟另一个东西比较, 通常说微服务好会和单体项目进行比较。以下是微服务相对于单体项目的一些显著好处:
单体项目的缺点:
微服务项目的优点:
总的来说,微服务项目通过提供更高的可扩展性、灵活性和容错性,以及更容易管理的部署和维护过程,有助于克服单体应用程序的一些限制和缺点。但请注意,微服务架构也会引入一些新的复杂性,需要更多的管理和监控。
单体应用、SOA和微服务架构都是不同的架构风格,适用于不同的情况。
单体应用像一个整体,所有的功能都打包在一个应用中。这种架构风格容易部署和测试,但随着系统规模的扩大,它的灵活性和可维护性会降低。
SOA是一种面向服务的架构风格,将系统划分为多个独立的服务。这些服务可以通过网络调用,并且可以跨平台、跨语言进行交互。SOA的优点是提供了跨系统的服务复用和松散耦合的交互方式,但实现SOA需要投入大量的工作,包括服务的定义、接口的选择、协议的制定等。
微服务架构进一步将系统划分为多个小型、独立的服务,每个服务都是一个单独的应用程序,可以独立部署、运行和扩展。微服务架构具有更高的灵活性和可维护性,适用于复杂的大型系统,强调服务的自治和独立性。但是,实施微服务架构也需要投入大量的工作,包括服务的定义、通信机制的选择、服务的管理等。
分布式系统和微服务架构是两个相关但不同的概念,它们的注重点其实不太一样。
分布式系统:它是由多台计算机或多节点组成的系统,各节点之间通过网络进行通信和协作,共同完成一个或多个共享的任务也就是说分布式的各个节点其实目标是一致的,之所以要分布式只是为了有更好的能力,能更快、更高效地承接任务。比如常见的分布式文件系统、分布式数据库。
微服务:其实是一种服务的架构风格,它主要是为了把一个大而全的服务,拆分成多个可以独立、松耦合的服务单元,为了让这些服务单元可以独立部署、运行、管理比如电商服务拆分成微服务,可以分为商品服务、用户服务、订单服务、库存服务等等
Spring cloud 流应用程序启动器是基于 Spring Boot 的 Spring 集成应用程序,提供与外部系统的集成。Spring cloud Task,一个生命周期短暂的微服务框架,用于快速构建执行有限数据处理的应用程序。
Spring cloud 流应用程序启动器是基于 Spring Boot 的 Spring 集成应用程序,提供与外部系统的集成。Spring cloud Task,一个生命周期短暂的微服务框架,用于快速构建执行有限数据处理的应用程序。
目前最主流的微服务开源解决方案有三种:
Dubbo:
Spring Cloud Netflix:
Spring Cloud Alibaba:
这三种方案有什么区别:
| 特点 | Dubbo | Spring Cloud Netflix | Spring Cloud Alibaba |
|---|---|---|---|
| 开发语言 | Java | Java | Java |
| 服务治理 | 提供完整的服务治理功能 | 提供部分服务治理功能 | 提供完整的服务治理功能 |
| 服务注册与发现 | ZooKeeper/Nacos | Eureka/Consul | Nacos |
| 负载均衡 | 自带负载均衡策略 | Ribbon | RibbonDubbo负载均衡策略 |
| 服务调用 | RPC方式 | RestTemplate/Feign | Feign/RestTemplate/Dubbo |
| 熔断器 | Sentinel | Hystrix | Sentinel/Resilience4j |
| 配置中心 | Apollo | Spring Cloud Config | Nacos Config |
| API网关 | Higress/APISIX | Zuul/Gateway | Spring Cloud Gateway |
| 分布式事务 | Seata | 不支持分布式事务 | Seata |
| 限流和降级 | Sentinel | Hystrix | Sentinel |
| 分布式追踪和监控 | Skywalking | Spring Cloud Sleuth + Zipkin | SkyWalking或Sentinel Dashboard |
| 微服务网格 | Dubbo Mesh | 不支持微服务网格 | Service Mesh(Nacos+Dubbo Mesh) |
| 社区活跃度 | 相对较高 | 目前较低 | 相对较高 |
| 孵化和成熟度 | 孵化较早,成熟度较高 | 成熟度较高 | 孵化较新,但迅速发展 |
-在面试中,微服务一般主要讨论的是Spring Cloud Netflix,其次是Spring Cloud Alibaba,Dubbo更多的是作为一个RPC框架来问。
使用 Spring Boot 开发分布式微服务时,我们面临以下问题
微服务给系统开发带来了一些问题和挑战,如服务调用的复杂性、分布式事务的处理、服务的动态管理等。为了更好地解决这些问题和挑战,各种微服务治理的组件应运而生,充当微服务架构的基石和支撑。
微服务的各个组件和常见实现:
Spring是一个生态体系(也可以说是技术体系),是集大成者,它包含了Spring Framework、Spring Boot、Spring Cloud等。它是一个轻量级控制反转(IOC)和面向切面(AOP)的容器框架,为开发者提供了一个简易的开发方式。
Spring的核心特性思想之一IOC,它实现了容器对Bean对象的管理、降低组件耦合,使各层服务解耦。
Spring的另一个核心特性就是AOP,面向切面编程。面向切面编程需要将程序逻辑分解为称为所谓关注点的不同部分。跨越应用程序多个点的功能称为跨领域问题,这些跨领域问题在概念上与应用程序的业务逻辑分离。有许多常见的例子,如日志记录,声明式事务,安全性,缓存等。
如果说IOC依赖注入可以帮助我们将应用程序对象相互分离,那么AOP可以帮助我们将交叉问题与它们所影响的对象分离。二者目的都是使服务解耦,使开发简易。
当然,除了Spring 的两大核心功能,还有如下这些,如:
Spring与MVC可以更好地解释什么是SpringMVC,MVC为现代web项目开发的一种很常见的模式,简言之C(控制器)将V(视图、用户客户端)与M(模块,业务)分开构成了MVC ,业内常见的MVC模式的开发框架有Struts。
Spring MVC是Spring的一部分,主要用于开发WEB应用和网络接口,它是Spring的一个模块,通过DispatcherServlet, ModelAndView 和View Resolver,让应用开发变得很容易。
SpringBoot是一套整合了框架的框架。
它的初衷:解决Spring框架配置文件的繁琐、搭建服务的复杂性。
它的设计理念:约定优于配置(convention over configuration)。
基于此理念实现了自动配置,且降低项目搭建的复杂度。
搭建一个接口服务,通过SpringBoot几行代码即可实现。基于Spring Boot,不是说原来的配置没有了,而是Spring Boot有一套默认配置,我们可以把它看做比较通用的约定,而Spring Boot遵循的是约定优于配置原则,同时,如果你需要使用到Spring以往提供的各种复杂但功能强大的配置功能,Spring Boot一样支持。
在Spring Boot中,你会发现引入的所有包都是starter形式,如:
Spring Boot是基于 Spring 框架开发的用于开发 Web 应用程序的框架,它帮助开发人员快速搭建和配置一个独立的、可执行的、基于 Spring 的应用程序,从而减少了繁琐和重复的配置工作。
Spring Cloud事实上是一整套基于Spring Boot的微服务解决方案。它为开发者提供了很多工具,用于快速构建分布式系统的一些通用模式,例如:配置管理、注册中心、服务发现、限流、网关、链路追踪等。Spring Boot是build anything,而Spring Cloud是coordinate anything,Spring Cloud的每一个微服务解决方案都是基于Spring Boot构建的。
SpringBoot专注于快速方便得开发单个个体微服务。
SpringCloud是关注全局的微服务协调整理治理框架,它将SpringBoot开发的一个个单体微服务整合并管理起来,为各个微服务之间提供,配置管理、服务发现、。断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务
SpringBoot可以离开SpringCloud独立使用开发项目, 但是SpringCloud离不开SpringBoot ,属于依赖的关系.
SpringBoot专注于快速、方便得开发单个微服务个体,SpringCloud关注全局的服务治理框架。
Spring Cloud是一个为分布式微服务架构构建应用程序的开发工具箱,是Spring Boot的扩展,通过各种微服务组件的集成,极大地简化了微服务应用程序的构建和开发。在分布式系统中,各个微服务之间的通信是非常重要的,而HTTP作为通信协议具有普遍性和可扩展性,是Spring Cloud微服务架构中主流的通信方式。
尽管使用HTTP作为微服务之间的通信协议存在一定的网络开销,但是这种不可避免的网络开销远低于我们所能得到的好处。使用HTTP通信可以实现松耦合和异步通信,微服务之间可以彼此独立地进行开发和测试,单个微服务的故障不会影响整个系统的运行,也可以支持各种不同的技术栈之间的互操作性。
另外,使用HTTP作为通信协议还具有优秀的可扩展性。HTTP协议定义了不同的请求方法(例如 GET、POST、DELETE 等),不同请求方法的扩展格式也很灵活,可以用来传递各种类型的数据和格式,同时HTTP协议支持缓存,减少重复性的数据传输和带宽开销。
当然,为了提高微服务之间的通信效率,我们也可以通过一些优化手段来减少HTTP协议的网络开销。例如,使用数据压缩和缓存技术来压缩和缓存请求和响应,减少网络数据传输量和响应时间;使用负载均衡技术来合理地分配请求和响应,避免单个微服务出现性能瓶颈;使用高速缓存技术来缓存请求和响应,避免重复的请求和响应等等。
因此,Spring Cloud各个微服务之间使用HTTP交互是一个比较成熟的选择。虽然它可能存在一些网络开销,但是在实际应用中,这种开销是可以优化和控制的,甚至可以提高系统的可扩展性和可靠性。
注册中心是用来管理和维护分布式系统中各个服务的地址和元数据的组件。它主要用于实现服务发现和服务注册功能。
总结一下注册中心的作用:
在分布式系统中,服务的数量通常会有很多,而且规模还不是一般地大,与此同时,服务的部署和变化也会很频繁,因此,如果要依赖人工去维护这些服务的关系,实现服务的管理以及调用就会变得非常困难。
服务注册与发现的作用就是为了解决这个问题,它通过注册中心来维护服务生产者以及服务消费者之间的关系。当服务启动之后,其就会向注册中心注册自己的信息,比如服务名称、服务端口、服务的P地址等,当服务消费者需要调用某个服务的时候,它会向注册中心发起查询请求,获取对应服务的信息,然后向生产者服务发送请求。如果一些服务上线或者下线,注册中心都可以主动通知消费者,这就动态地实现了服务的上下线,在高峰期加机器,低峰期减机器,减少了管理的成本,十分方便。也可以方便实现服务的监控、管理等等。
SpringCloud可以与多种注册中心进行集成,常见的注册中心包括:
Eureka 是一个 Spring Cloud Netflix 的一款老牌注册中心,设计用于实现云端部署微服务架构中的服务注册与发现功能。
在技术领域,特别是分布式系统中,Eureka作为一个基于 RESTFul 的服务,主要职责包括:
在 Spring Cloud 中,Eureka 被集成作为服务注册与服务发现的核心组件,通过 @EnableEurekaServer 和 @EnableEurekaClient 注解可以轻松实现服务注册中心或服务客户端
Eureka 在2020年后 Netflix 宣布不再积极维护,但它仍然是许多现有系统中服务注册中心的实现方案,并目有社区进行维护,
服务发布时,指定对应的服务名,将服务注册到 注册中心(Eureka 、Zookeeper)。
注册中心加@EnableEurekaServer,服务用@EnableDiscoveryClient,然后用ribbon或feign进行服务直接的调用发现。
| 特性 | Eureka | ZooKeeper | Nacos |
|---|---|---|---|
| 开发公司 | Netflix | Apache 基金会 | 阿里巴巴 |
| CAP | AP(可用性和分区容忍性) | CP(一致性和分区容忍性) | 既支持AP,也支持CP |
| 功能 | 服务注册与发现 | 分布式协调、配置管理、分布式锁 | 服务注册与发现、配置管理、服务管理 |
| 定位 | 适用于构建基于 HTTP 的微服务架构 | 通用的分布式协调服务框架 | 适用于微服务和云原生应用 |
| 访问协议 | HTTP | TCP | HTTP/DNS |
| 自我保护 | 支持 | - | 支持 |
| 数据存储 | 内嵌数据库、多个实例形成集群 | ACID 特性的分布式文件系统 ZAB 协议 | 内嵌数据库、MySQL 等 |
| 健康检查 | Client Beat | Keep Alive | TCP/HTTP/MYSQL/Client Beat |
| 特点 | 简单易用、自我保护机制 | 高性能、强一致性 | 动态配置管理、流量管理、灰度发布等 |
可以看到Eureka和ZooKeeper的最大区别是一个支持AP,一个支持CP,Nacos既支持既支持AP,也支持CP。
关于CAP相关理论和概念可以看这篇文章:CAPl理论
Zookeeper保证了CP,Eureka保证了AP。
CAP理论详情请看CAP理论
A:高可用
C:一致性
P:分区容错性
因此,Eureka可以很好地应对因网络故障导致部分节点失去联系的情况,而不会像Zookeeper那样使整个微服务瘫痪
Nacos和Eureka整体结构类似,服务注册、服务拉取、心跳等待,但是也存在一些差异:

Nacos与eureka的共同点
Nacos与Eureka的区别

Eureka的实现原理,大概可以从这几个方面来看:
其它的注册中心,如Nacos、Consul等等,在服务注册和发现上,实现原理都是大同小异。
Eureka Server保证高可用,主要通过这三个方面来实现:

什么是自我保护模式?
通常(微服务的自身的故障关闭)只会导致个别服务出现故障,一般不会出现大面积故障,而(网络故障)通常会导致 Eureka Server 在短时间内无法收到大批心跳。考虑到这个区别,Eureka 设置了一个阀值,当判断挂掉的服务的数量超过阀值时,Eureka Server 认为很大程度上出现了网络故障,将不再删除心跳过期的服务。
15 分钟之内是否低于 85%;Eureka Server 在运行期间,会统计心跳失败的比例在 15 分钟内是否低于 85%,这种算法叫做 Eureka Server 的自我保护模式。
为什么要自我保护?
Consul 是 HasiCorp 公司用 Golang 开发的一款开源的服务注册中心以及配置中心,提供了服务注册与发现、健康检查、KV 存储、多数据中心支持、DNS 和 HTTP API 接口等功能,而且提供了可视化控制台用于操作。
Consul 的优点有很多
这些微服务之间一般需要借助注册中心,然后通过服务发现机制定位彼此。
核心原理是:服务启动时将自己的地址和元数据注册到注册中心(Nacos、Consul),调用方通过注册中心动态获取可用服务实例列表,然后基于负载均衡策略(如轮询、随机)发起请求。

整个过程还得依赖心跳检测确保实例状态实时更新,例如老服务的下线,新服务的上线。
每个微服务启动后,会向注册中心(如Nacos、Consul)发送自己的信息(IP、端口、服务名等),告诉注册中心“我上线了”
注册中心会存储所有已注册服务的信息,并通过心跳检测(如每隔5秒发一次“我还活着”)监控服务状态,若某服务超过一定时间没心跳,注册中心会标记它为“下线”
当服务 A需要调用服务B时,会向注册中心查询服务 B的所有可用实例(IP+端口),然后从这些实例中选一个(如轮询、随机)发起请求。
本文来自在线网站:seven的菜鸟成长之路,作者:seven,转载请注明原文链接:www.seven97.top
登录查看全部
参与评论
手机查看
返回顶部