企业门户网站建设方案书,苏州建设工程人才招聘网信息网站,安阳企业建网站,网络营销怎么做有效目录
概览
1.什么是微服务#xff1f;
2.微服务带来了哪些挑战#xff1f;
3.现在有哪些流行的微服务解决方案#xff1f;
这三种方案有什么区别吗#xff1f;
4.说下微服务有哪些组件#xff1f;
注册中心
5.注册中心是用来干什么的#xff1f;
6.SpringCloud可…目录
概览
1.什么是微服务
2.微服务带来了哪些挑战
3.现在有哪些流行的微服务解决方案
这三种方案有什么区别吗
4.说下微服务有哪些组件
注册中心
5.注册中心是用来干什么的
6.SpringCloud可以选择哪些注册中心
7.说下Eureka、ZooKeeper、Nacos的区别
8.Eureka实现原理了解吗
9.Eureka Server怎么保证高可用
配置中心
10.为什么微服务需要配置中心
11.SpringCloud可以选择哪些配置中心
12.Nacos配置中心的原理了解吗
13.Nacos配置中心长轮询机制
远程调用
14.能说下HTTP和RPC的区别吗
15.那Feign和Dubbo的区别呢
16.说一下Fegin?
17.为什么Feign第一次调用耗时很长
18.Feign怎么实现认证传递
19.Fegin怎么做负载均衡Ribbon?
20.说说有哪些负载均衡算法 概览
1.什么是微服务
微服务Microservices是一种软件架构风格将一个大型应用程序划分为一组小型、自治且松耦合的服务。每个微服务负责执行特定的业务功能并通过轻量级通信机制如HTTP相互协作。每个微服务可以独立开发、部署和扩展使得应用程序更加灵活、可伸缩和可维护。
在微服务的架构演进中一般可能会存在这样的演进方向单体式--服务化--微服务。
单体服务一般是所有项目最开始的样子 单体服务Monolithic Service是一种传统的软件架构方式将整个应用程序作为一个单一的、紧耦合的单元进行开发和部署。单体服务通常由多个模块组成这些模块共享同一个数据库和代码库。然而随着应用程序规模的增长单体服务可能变得庞大且难以维护且部署和扩展困难。
后来单体服务过大维护困难渐渐演变到了分布式的SOA SOAService-Oriented Architecture面向服务的架构是一种软件架构设计原则强调将应用程序拆分为相互独立的服务通过标准化的接口进行通信。SOA关注于服务的重用性和组合性但并没有具体规定服务的大小。 微服务是在SOA的基础上进一步发展而来是一种特定规模下的服务拆分和部署方式。微服务架构强调将应用程序拆分为小型、自治且松耦合的服务每个服务都专注于特定的业务功能。这种架构使得应用程序更加灵活、可伸缩和可维护。
需要注意的是微服务是一种特定的架构风格而SOA是一种设计原则。微服务可以看作是对SOA思想的一种具体实践方式但并不等同于SOA。 微服务与单体服务的区别在于规模和部署方式。微服务将应用程序拆分为更小的、自治的服务单元每个服务都有自己的数据库和代码库可以独立开发、测试、部署和扩展带来了更大的灵活性、可维护性、可扩展性和容错性。
2.微服务带来了哪些挑战
微服务架构不是万金油尽它有很多优点但是对于是否采用微服务架构是否将原来的单体服务进行拆分还是要考虑到服务拆分后可能带来的一些挑战和问题 系统复杂性增加一个服务拆成了多个服务整体系统的复杂性增加需要处理服务之间的通信、部署、监控和维护等方面的复杂性。 服务间通信开销微服务之间通过网络进行通信传递数据需要额外的网络开销和序列化开销可能导致性能瓶颈和增加系统延迟。 数据一致性和事务管理每个微服务都有自己的数据存储数据一致性和跨服务的事务管理变得更加复杂需要额外解决分布式事务和数据同步的问题。 部署和运维复杂性微服务架构涉及多个独立部署的服务对于部署、监控和容错机制的要求更高需要建立适当的部署管道和自动化工具以简化部署和运维过程。 团队沟通和协作成本每个微服务都由专门的团队负责可能增加团队之间的沟通和协作成本。需要有效的沟通渠道和协作机制确保服务之间的协调和一致性。 服务治理和版本管理随着微服务数量的增加服务的治理和版本管理变得更加复杂。需要考虑服务的注册发现、负载均衡、监控和故障处理等方面以确保整个系统的可靠性和稳定性。 分布式系统的复杂性微服务架构涉及构建和管理分布式系统而分布式系统本身具有一些固有的挑战如网络延迟、分布式一致性和容错性。
简单说采用微服务需要权衡这些问题和挑战根据实际的需求来选择对应的技术方案很多时候单体能搞定的也可以用单体不能为了微服务而微服务。
3.现在有哪些流行的微服务解决方案
目前最主流的微服务开源解决方案有三种 Dubbo Dubbo 是一个高性能、轻量级的 Java 微服务框架最初由阿里巴巴Alibaba开发并于2011年开源。它提供了服务注册与发现、负载均衡、容错、分布式调用等功能后来一度停止维护在近两年又重新开始迭代并推出了Dubbo3。 Dubbo 使用基于 RPCRemote Procedure Call的通信模型具有较高的性能和可扩展性。它支持多种传输协议如TCP、HTTP、Redis和序列化方式如JSON、Hessian、Protobuf可根据需求进行配置。 Dubbo更多地被认为是一个高性能的RPC远程过程调用框架一些服务治理功能依赖于第三方组件实现比如使用ZooKeeper、Apollo等等。 Spring Cloud Netflix Spring Cloud Netflix 是 Spring Cloud 的一个子项目结合了 Netflix 开源的多个组件但是Netflix自2018年停止维护和更新Netflix OSS项目包括Eureka、Hystrix等组件所以Spring Cloud Netflix也逐渐进入了维护模式。 该项目包含了许多流行的 Netflix 组件如Eureka服务注册与发现、Ribbon客户端负载均衡、Hystrix断路器、ZuulAPI 网关等。它们都是高度可扩展的、经过大规模实践验证的微服务组件。 Spring Cloud Alibaba 这三种方案有什么区别吗
三种方案的区别 Spring Cloud Alibaba 是 Spring Cloud 的另一个子项目与阿里巴巴的分布式应用开发框架相关。它提供了一整套与 Alibaba 生态系统集成的解决方案。 该项目包括 Nacos服务注册与发现、配置管理、Sentinel流量控制、熔断降级、RocketMQ消息队列等组件以及与 Alibaba Cloud阿里云的集成。它为构建基于 Spring Cloud 的微服务架构提供了丰富的选项。 据说SpringCloud Alibaba项目的发起人已经跑路去了腾讯并发起了SpringCloud Tecent项目社区发展存在隐忧。 在面试中微服务一般主要讨论的是Spring Cloud Netflix其次是Spring Cloud AlibabaDubbo更多的是作为一个RPC框架来问。 4.说下微服务有哪些组件
微服务给系统开发带来了一些问题和挑战如服务调用的复杂性、分布式事务的处理、服务的动态管理等。为了更好地解决这些问题和挑战各种微服务治理的组件应运而生充当微服务架构的基石和支撑。 微服务的各个组件和常见实现 注册中心用于服务的注册与发现管理微服务的地址信息。常见的实现包括 Spring Cloud NetflixEureka、Consul Spring Cloud AlibabaNacos 配置中心用于集中管理微服务的配置信息可以动态修改配置而不需要重启服务。常见的实现包括 Spring Cloud NetflixSpring Cloud Config Spring Cloud AlibabaNacos Config 远程调用用于在不同的微服务之间进行通信和协作。常见的实现保包括 RESTful API如RestTemplate、Feign RPC远程过程调用如Dubbo、gRPC API网关作为微服务架构的入口统一暴露服务并提供路由、负载均衡、安全认证等功能。常见的实现包括 Spring Cloud NetflixZuul、Gateway Spring Cloud AlibabaGateway、Apisix等 分布式事务保证跨多个微服务的一致性和原子性操作。常见的实现包括 Spring Cloud AlibabaSeata 熔断器用于防止微服务之间的故障扩散提高系统的容错能力。常见的实现包括 Spring Cloud NetflixHystrix Spring Cloud AlibabaSentinel、Resilience4j 限流和降级用于防止微服务过载对请求进行限制和降级处理。常见的实现包括 Spring Cloud NetflixHystrix Spring Cloud AlibabaSentinel 分布式追踪和监控用于跟踪和监控微服务的请求流程和性能指标。常见的实现包括 Spring Cloud NetflixSpring Cloud Sleuth Zipkin Spring Cloud AlibabaSkyWalking、Sentinel Dashboard 注册中心 5.注册中心是用来干什么的 注册中心是用来管理和维护分布式系统中各个服务的地址和元数据的组件。它主要用于实现服务发现和服务注册功能。
总结一下注册中心的作用 服务注册各个服务在启动时向注册中心注册自己的网络地址、服务实例信息和其他相关元数据。这样其他服务就可以通过注册中心获取到当前可用的服务列表。 服务发现客户端通过向注册中心查询特定服务的注册信息获得可用的服务实例列表。这样客户端就可以根据需要选择合适的服务进行调用实现了服务间的解耦。 负载均衡注册中心可以对同一服务的多个实例进行负载均衡将请求分发到不同的实例上提高整体的系统性能和可用性。 故障恢复注册中心能够监测和检测服务的状态当服务实例发生故障或下线时可以及时更新注册信息从而保证服务能够正常工作。 服务治理通过注册中心可以进行服务的配置管理、动态扩缩容、服务路由、灰度发布等操作实现对服务的动态管理和控制。 6.SpringCloud可以选择哪些注册中心
SpringCloud可以与多种注册中心进行集成常见的注册中心包括 EurekaEureka 是 Netflix 开源的服务发现框架具有高可用、弹性、可扩展等特点并与 Spring Cloud 集成良好。 ConsulConsul 是一种分布式服务发现和配置管理系统由 HashiCorp 开发。它提供了服务注册、服务发现、健康检查、键值存储等功能并支持多数据中心部署。 ZooKeeperZooKeeper 是 Apache 基金会开源的分布式协调服务可以用作服务注册中心。它具有高可用、一致性、可靠性等特点。 NacosNacos 是阿里巴巴开源的一个动态服务发现、配置管理和服务管理平台。它提供了服务注册和发现、配置管理、动态 DNS 服务等功能。 etcdetcd 是 CoreOS 开源的一种分布式键值存储系统可以被用作服务注册中心。它具有高可用、强一致性、分布式复制等特性。
7.说下Eureka、ZooKeeper、Nacos的区别 可以看到Eureka和ZooKeeper的最大区别是一个支持AP一个支持CPNacos既支持既支持AP也支持CP
8.Eureka实现原理了解吗 服务注册与发现: 当一个服务实例启动时它会向Eureka Server发送注册请求将自己的信息注册到注册中心。Eureka Server会将这些信息保存在内存中并提供REST接口供其他服务查询。服务消费者可以通过查询服务实例列表来获取可用的服务提供者实例从而实现服务的发现。 服务健康检查: Eureka通过心跳机制来检测服务实例的健康状态。服务实例会定期向Eureka Server发送心跳也就是续约以表明自己的存活状态。如果Eureka Server在一定时间内没有收到某个服务实例的心跳则会将其标记为不可用并从服务列表中移除下线实例。 服务负载均衡: Eureka客户端在调用其他服务时会从本地缓存中获取服务的注册信息。如果缓存中没有对应的信息则会向Eureka Server发送查询请求。Eureka Server会返回一个可用的服务实例列表给客户端客户端可以使用负载均衡算法选择其中一个进行调用。 其它的注册中心如Nacos、Consul等等在服务注册和发现上实现原理都是大同小异。 9.Eureka Server怎么保证高可用
Eureka Server保证高可用主要通过这三个方面来实现 多实例部署: 通过将多个Eureka Server实例部署在不同的节点上可以实现高可用性。当其中一个实例发生故障时其他实例仍然可以提供服务并保持注册信息的一致性。 服务注册信息的复制: 当一个服务实例向Eureka Server注册时每个Eureka Server实例都会复制其他实例的注册信息以保持数据的一致性。当某个Eureka Server实例发生故障时其他实例可以接管其工作保证整个系统的正常运行。 自我保护机制: Eureka还具有自我保护机制。当Eureka Server节点在一定时间内没有接收到心跳时它会进入自我保护模式。在自我保护模式下Eureka Server不再剔除注册表中的服务实例以保护现有的注册信息。这样可以防止由于网络抖动或其他原因导致的误剔除进一步提高系统的稳定性。 配置中心
10.为什么微服务需要配置中心
微服务架构中的每个服务通常都需要一些配置信息例如数据库连接地址、服务端口、日志级别等。这些配置可能因为不同环境、不同部署实例或者动态运行时需要进行调整和管理。
微服务的实例一般非常多如果每个实例都需要一个个地去做这些配置那么运维成本将会非常大这时候就需要一个集中化的配置中心去管理这些配置
11.SpringCloud可以选择哪些配置中心
和注册中心一样SpringCloud也支持对多种配置中心的集成。常见的配置中心选型包括 Spring Cloud Config官方推荐的配置中心支持将配置文件存储在Git、SVN等版本控制系统中并提供RESTful API进行访问和管理。 ZooKeeper一个开源的分布式协调服务可以用作配置中心。它具有高可用性、一致性和通知机制等特性。 Consul另一个开源的分布式服务发现和配置管理工具也可用作配置中心。支持多种配置文件格式提供健康检查、故障转移和动态变更等功能。 Etcd一个分布式键值存储系统可用作配置中心。它使用基于Raft算法的一致性机制提供分布式数据一致性保证。 Apollo携程开源的配置中心支持多种语言和框架。提供细粒度的配置权限管理、配置变更通知和灰度发布等高级特性还有可视化的配置管理界面。 Nacos阿里巴巴开源的服务发现、配置管理和服务管理平台也可以作为配置中心使用。支持服务注册与发现、动态配置管理、服务健康监测和动态DNS服务等功能。
12.Nacos配置中心的原理了解吗
配置中心说白了就是一句话配置信息的CRUD。 具体的实现大概可以分成这么几个部分 配置信息存储Nacos默认使用内嵌数据库Derby来存储配置信息还可以采用MySQL等关系型数据库。 注册配置信息服务启动时Nacos Client会向Nacos Server注册自己的配置信息这个注册过程就是把配置信息写入存储并生成版本号。 获取配置信息服务运行期间Nacos Client通过API从Nacos Server获取配置信息。Server根据键查找对应的配置信息并返回给Client。 监听配置变化Nacos Client可以通过注册监听器的方式实现对配置信息的监听。当配置信息发生变化时Nacos Server会通知已注册的监听器并触发相应的回调方法。 13.Nacos配置中心长轮询机制
一般来说客户端和服务端的交互分为两种推Push和拉PullNacos在Pull的基础上采用了长轮询来进行配置的动态刷新。
在长轮询模式下客户端定时向服务端发起请求检查配置信息是否发生变更。如果没有变更服务端会hold住这个请求即暂时不返回结果直到配置发生变化或达到一定的超时时间。
具体的实现过程如下 客户端发起Pull请求服务端检查配置是否有变更。如果没有变更则设置一个定时任务在一段时间后执行并将当前的客户端连接加入到等待队列中。 在等待期间如果配置发生变更服务端会立即返回结果给客户端完成一次推送操作。 如果在等待期间没有配置变更等待时间达到预设的超时时间后服务端会自动返回结果给客户端即使配置没有变更。 如果在等待期间通过Nacos Dashboard或API对配置进行了修改会触发一个事件机制服务端会遍历等待队列找到发生变更的配置项对应的客户端连接并将变更的数据通过连接返回完成一次推送操作。
通过长轮询的方式Nacos客户端能够实时感知配置的变化并及时获取最新的配置信息。同时这种方式也降低了服务端的压力避免了大量的长连接占用内存资源
远程调用
14.能说下HTTP和RPC的区别吗
严格来讲HTTP和RPC不是一个层面的东西 HTTPHypertext Transfer Protocol是一种应用层协议主要强调的是网络通信 RPCRemote Procedure Call远程过程调用是一种用于分布式系统之间通信的协议强调的是服务之间的远程调用。
一些RPC框架比如gRPC底层传输协议其实也是用的HTTP2包括Dubbo3也兼容了gRPC使用了HTTP2作为传输层的一层协议。
如果硬要说区别的话如下 HTTP RPC 在微服务体系里基于HTTP风格的远程调用通常使用框架如Feign来实现基于RPC的远程调用通常使用框架如Dubbo来实现。
15.那Feign和Dubbo的区别呢
这两个才是适合拿来比较的东西 需要注意的是Feign和Dubbo并不是互斥的关系。实际上Dubbo可以使用HTTP协议作为通信方式而Feign也可以集成RPC协议进行远程调用。选择使用哪种远程调用方式取决于具体的业务需求和技术栈的选择。 16.说一下Fegin?
Feign是一个声明式的Web服务客户端它简化了使用基于HTTP的远程服务的开发。
Feign是在RestTemplate 和 Ribbon的基础上进一步封装使用RestTemplate实现Http调用使用Ribbon实现负载均衡 Feign的主要特点和功能包括 声明式APIFeign允许开发者使用简单的注解来定义和描述对远程服务的访问。通过使用注解开发者可以轻松地指定URL、HTTP方法、请求参数、请求头等信息使得远程调用变得非常直观和易于理解。 FeignClient(name example, url https://api.example.com)
public interface ExampleService {GetMapping(/endpoint)String getEndpointData();
} 集成负载均衡Feign集成了Ribbon负载均衡器可以自动实现客户端的负载均衡。它可以根据服务名和可用实例进行动态路由并分发请求到不同的服务实例上提高系统的可用性和可伸缩性。 容错机制Feign支持集成Hystrix容错框架可以在调用远程服务时提供容错和断路器功能。当远程服务不可用或响应时间过长时Feign可以快速失败并返回预设的响应结果避免对整个系统造成级联故障。
17.为什么Feign第一次调用耗时很长
主要原因是由于Ribbon的懒加载机制当第一次调用发生时Feign会触发Ribbon的加载过程包括从服务注册中心获取服务列表、建立连接池等操作这个加载过程会增加首次调用的耗时。
ribbon:eager-load:enabled: trueclients: service-1
那怎么解决这个问题呢
可以在应用启动时预热Feign客户端自动触发一次无关紧要的调用来提前加载Ribbon和其他相关组件。这样就相当于提前进行了第一次调用。
18.Feign怎么实现认证传递
比较常见的一个做法是使用拦截器传递认证信息。可以通过实现RequestInterceptor接口来定义拦截器在拦截器里把认证信息添加到请求头中然后将其注册到Feign的配置中。
Configuration
public class FeignClientConfig {Beanpublic RequestInterceptor requestInterceptor() {return new RequestInterceptor() {Overridepublic void apply(RequestTemplate template) {// 添加认证信息到请求头中template.header(Authorization, Bearer getToken());}};}private String getToken() {// 获取认证信息的逻辑可以从SecurityContext或其他地方获取// 返回认证信息的字符串形式return your_token;}
} 19.Fegin怎么做负载均衡Ribbon?
在Feign中负载均衡是通过集成Ribbon来实现的。
Ribbon是Netflix开源的一个客户端负载均衡器可以与Feign无缝集成为Feign提供负载均衡的能力。
Ribbon通过从服务注册中心获取可用服务列表并通过负载均衡算法选择合适的服务实例进行请求转发实现客户端的负载均衡。 20.说说有哪些负载均衡算法
常见的负载均衡算法包含以下几种 轮询算法Round Robin轮询算法是最简单的负载均衡算法之一。它按照顺序将请求依次分配给每个后端服务器循环往复。当请求到达时负载均衡器按照事先定义的顺序选择下一个服务器。轮询算法适用于后端服务器具有相同的处理能力和性能的场景。 加权轮询算法Weighted Round Robin加权轮询算法在轮询算法的基础上增加了权重的概念。每个后端服务器都被赋予一个权重值权重值越高被选中的概率就越大。这样可以根据服务器的处理能力和性能调整请求的分配比例使得性能较高的服务器能够处理更多的请求。 随机算法Random随机算法将请求随机分配给后端服务器。每个后端服务器有相等的被选中概率没有考虑服务器的实际负载情况。这种算法简单快速适用于后端服务器性能相近且无需考虑请求处理能力的场景。 加权随机算法Weighted Random加权随机算法在随机算法的基础上引入了权重的概念。每个后端服务器被赋予一个权重值权重值越高被选中的概率就越大。这样可以根据服务器的处理能力和性能调整请求的分配比例。 最少连接算法Least Connection最少连接算法会根据后端服务器当前的连接数来决定请求的分配。负载均衡器会选择当前连接数最少的服务器进行请求分配以保证后端服务器的负载均衡。这种算法适用于后端服务器的处理能力不同或者请求的处理时间不同的场景。 哈希算法Hash哈希算法会根据请求的某个特定属性如客户端IP地址、请求URL等计算哈希值然后根据哈希值选择相应的后端服务器。
常见的负载均衡器比如Ribbion、Gateway等等基本都支持这些负载均衡算法。
