赞
踩
Kafka高级篇知识点
44个Kafka知识点(基础+进阶+高级)解析如下
由于篇幅有限,小编已将上面介绍的**《Kafka源码解析与实战》、Kafka面试专题解析、复习学习必备44个Kafka知识点(基础+进阶+高级)都整理成册,全部都是PDF文档**
2011 年 10 月,阿里巴巴宣布开源,版本为 2.0.7。
2012 年 3 月,发布 2.1.0 版本。
2013 年 3 月,发布 2.4.10 版本。
2014 年 10 月,发布 2.3.11 版本,之后版本停滞。
2017 年 9 月,阿里巴巴重启维护,重点升级所依赖 JDK 及组件版本,发布 2.5.4/5 版本。
2017 年 10 月,发布 2.5.6 版本。
2017 年 11 月,发布 2.5.7 版本,后期集成 Spring Boot。
2014 年 10 月,当当网 Fork 了 Dubbo 版本,命名为 Dubbox-2.8.0,并支持 HTTP REST 协议。
Dubbo 负责人说明(重启维护是接受的采访):
阿里内部使用 HSF,原因业务属性和规模有关。这里就不得不提到目前的一些文章在谈到微服务的时候总是拿 Spring Cloud 和 Dubbo 来对比,需要强调的是 Dubbo 未来的定位并不是要成为一个微服务的全面解决方案,而是专注在 RPC 领域,成为微服务生态体系中的一个重要组件。至于大家关注的微服务化衍生出的服务治理需求,我们会在 Dubbo 积极适配开源解决方案,甚至启动独立的开源项目予以支持。受众主要来自国内各友商以及个人开发者,希望将来能够将用户拓展到全球,代表国人在 RPC 领域与 gRPC(基于 HTTP 2.0)、Finagle 等竞争。
Spring Cloud 是什么?
=====================
Spring Cloud 基于 Spring Boot,为微服务体系开发中的架构问题,提供了一整套的解决方案——服务注册与发现,服务消费,服务保护与熔断,网关,分布式调用追踪,分布式配置管理等。
Spring Boot 是 Spring 的一套快速配置脚手架,使用默认大于配置的理念,用于快速开发单个微服务。
重点:
基于 Spring Boot
云服务、分布式框架集合(众多)
核心功能:
分布式/版本化配置
服务注册和发现
路由
服务和服务之间的调用
负载均衡
断路器
分布式消息传递
Spring Cloud 完整技术
=====================
Spring Cloud 组件架构
=====================
流程:
请求统一通过 API 网关(Zuul)来访问内部服务。
网关接收到请求后,从注册中心(Eureka)获取可用服务。
由 Ribbon 进行均衡负载后,分发到后端具体实例。
微服务之间通过 Feign 进行通信处理业务。
Hystrix 负责处理服务超时熔断。
Turbine 监控服务间的调用和熔断相关指标。
Spring Cloud工具框架
====================
Spring Cloud Config 配置中心,利用 Git 集中管理程序的配置。
Spring Cloud Netflix 集成众多Netflix的开源软件。
Spring Cloud Netflix Eureka 服务中心(类似于管家的概念,需要什么直接从这里取,就可以了),一个基于 REST 的服务,用于定位服务,以实现云端中间层服务发现和故障转移。
Spring Cloud Netflix Hystrix 熔断器,容错管理工具,旨在通过熔断机制控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。
Spring Cloud Netflix Zuul 网关,是在云平台上提供动态路由,监控,弹性,安全等边缘服务的框架。Web 网站后端所有请求的前门。
Spring Cloud Netflix Archaius 配置管理 API,包含一系列配置管理API,提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。
Spring Cloud Netflix Ribbon 负载均衡。
Spring Cloud Netflix Fegin REST客户端。
Spring Cloud Bus 消息总线,利用分布式消息将服务和服务实例连接在一起,用于在一个集群中传播状态的变化。
Spring Cloud for Cloud Foundry 利用 Pivotal Cloudfoundry 集成你的应用程序。
Spring Cloud Cloud Foundry Service Broker 为建立管理云托管服务的服务代理提供了一个起点。
Spring Cloud Cluster 集群工具,基于 Zookeeper, Redis, Hazelcast, Consul 实现的领导选举和平民状态模式的抽象和实现。
Spring Cloud Consul 基于 Hashicorp Consul 实现的服务发现和配置管理。
Spring Cloud Security 安全控制,在 Zuul 代理中为 OAuth2 REST 客户端和认证头转发提供负载均衡。
Spring Cloud Sleuth 分布式链路监控,SpringCloud 应用的分布式追踪系统,和 Zipkin,HTrace,ELK 兼容。
Spring Cloud Data Flow 一个云本地程序和操作模型,组成数据微服务在一个结构化的平台上。
Spring Cloud Stream 消息组件,基于 Redis,Rabbit,Kafka 实现的消息微服务,简单声明模型用以在 Spring Cloud 应用中收发消息。
Spring Cloud Stream App Starters 基于 Spring Boot 为外部系统提供 Spring 的集成。
Spring Cloud Task 短生命周期的微服务,为 Spring Booot 应用简单声明添加功能和非功能特性。
Spring Cloud Task App Starters。
Spring Cloud Zookeeper 服务发现和配置管理基于 Apache Zookeeper。
Spring Cloud for Amazon Web Services 快速和亚马逊网络服务集成。
Spring Cloud Connectors 便于PaaS应用在各种平台上连接到后端像数据库和消息经纪服务。
Spring Cloud Starters (项目已经终止并且在 Angel.SR2 后的版本和其他项目合并)
Spring Cloud CLI 命令行工具,插件用 Groovy 快速的创建 Spring Cloud 组件应用。
Dubbo 一些优点
==============
Dubbo 支持 RPC 调用,服务之间的调用性能会很好。
支持多种序列化协议,如 Hessian、HTTP、WebService。
Dobbo Admin后台管理功能强大,提供了路由规则、动态配置、访问控制、权重调节、均衡负载等功能。
在国内影响力比较大,中文社区文档较为全面。
阿里最近重启维护。
Dubbo 一些问题
==============
Registry 严重依赖第三方组件(zookeeper 或者 redis),当这些组件出现问题时,服务调用很快就会中断。
Dubbo 只支持 RPC 调用。使得服务提供方(抽象接口)与调用方在代码上产生了强依赖,服务提供者需要不断将包含抽象接口的 jar 包打包出来供消费者使用。一旦打包出现问题,就会导致服务调用出错,并且以后发布部署会成很大问题(太强的依赖关系)。
另外,以后要兼容 .NET Core 服务,Dubbo RPC 本身不支持跨语言(可以用跨语言 RPC 框架解决,比如 Thrift、gRPC(重复封装了),或者自己再包一层 REST 服务,提供跨平台的服务调用实现,但相对麻烦很多)
Dubbo 只是实现了服务治理,其他微服务框架并未包含,如果需要使用,需要结合第三方框架实现(比如分布式配置用淘宝的 Diamond、服务跟踪用京东的 Hydra,但使用相对麻烦些),开发成本较高,且风险较大。
社区更新不及时(虽然最近在疯狂更新),但也难免阿里以后又不更新了,就尴尬了。
主要是国内公司使用,但阿里内部使用 HSF,相对于 Spring Cloud,企业应用会差一些。
Spring Cloud 的一些优点
======================
有强大的 Spring 社区、Netflix 等公司支持,并且开源社区贡献非常活跃。
标准化的将微服务的成熟产品和框架结合一起,Spring Cloud 提供整套的微服务解决方案,开发成本较低,且风险较小。
基于 Spring Boot,具有简单配置、快速开发、轻松部署、方便测试的特点。
支持 REST 服务调用,相比于 RPC,更加轻量化和灵活(服务之间只依赖一纸契约,不存在代码级别的强依赖),有利于跨语言服务的实现,以及服务的发布部署。另外,结合 Swagger,也使得服务的文档一体化。
提供了 Docker 及 Kubernetes 微服务编排支持。
国内外企业应用非常多,经受了大公司的应用考验(比如 Netfilx 公司),以及强大的开源社区支持。
Spring Cloud 的一些问题
======================
支持 REST 服务调用,可能因为接口定义过轻,导致定义文档与实际实现不一致导致服务集成时的问题(可以使用统一文档和版本管理解决,比如 Swagger)。
另外,REST 服务调用性能会比 RPC 低一些(但也不是强绑定)
Spring Cloud 整合了大量组件,相关文档比较复杂,需要针对性的进行阅读。
服务调用方式的不同
=============
Spring Cloud 抛弃了 Dubbo 的 RPC 通信,采用的是基于 HTTP 的 REST 方式。严格来说,这两种方式各有优劣。虽然从一定程度上来说,后者牺牲了服务调用的性能,但也避免了上面提到的原生 RPC 带来的问题。而且 REST 相比 RPC 更为灵活,服务提供方和调用方的依赖只依靠一纸契约,不存在代码级别的强依赖,这在强调快速演化的微服务环境下,显得更加合适。
Dubbo 和 Spring Cloud 对比
===========================
Dubbo 专注 RPC 和服务治理,Spring Cloud 则是一个微服务架构生态。
ZooKeeper 和 Eureka 的区别
==========================
鉴于服务发现对服务化架构的重要性,Dubbo 实践通常以 ZooKeeper 为注册中心(Dubbo 原生支持的 Redis 方案需要服务器时间同步,且性能消耗过大)。针对分布式领域著名的 CAP 理论(C——数据一致性,A——服务可用性,P——服务对网络分区故障的容错性),Zookeeper 保证的是 CP ,但对于服务发现而言,可用性比数据一致性更加重要,AP 胜过 CP,而 Eureka 设计则遵循 AP 原则。Spring Cloud 支持 Consul(CA)和 Zookeeper,但不推荐使用。
网易考拉选型参考
============
当前开源上可选用的微服务框架主要有 Dubbo、Spring Cloud 等,鉴于 Dubbo 完备的功能和文档且在国内被众多大型互联网公司选用,考拉自然也选择了 Dubbo 作为服务化的基础框架。其实相比于 Dubbo,Spring Cloud 可以说是一个更完备的微服务解决方案,它从功能性上是 Dubbo 的一个超集,个人认为从选型上对于一些中小型企业 Spring Cloud 可能是一个更好的选择。提起 Spring Cloud,一些开发的第一印象是 HTTP + JSON 的 REST 通信,性能上难堪重用,其实这也是一种误读。微服务选型要评估以下几点:内部是否存在异构系统集成的问题;备选框架功能特性是否满足需求;HTTP 协议的通信对于应用的负载量会否真正成为瓶颈点(Spring Cloud 也并不是和 HTTP + JSON 强制绑定的,如有必要 Thrift、ProtoBuf 等高效的 RPC、序列化协议同样可以作为替代方案);社区活跃度、团队技术储备等。作为已经没有团队持续维护的开源项目,选择 Dubbo 框架内部就必须要组建一个维护团队,先不论你要准备要集成多少功能做多少改造,作为一个支撑所有工程正常运转的基础组件,问题的及时响应与解答、重大缺陷的及时修复能力就已足够重要。
Dubbo 和 Spring Cloud 比喻
===========================
使用 Dubbo 构建的微服务架构就像组装电脑,各环节我们的选择自由度很高,但是最终结果很有可能因为一条内存质量不行就点不亮了,总是让人不怎么放心,但是如果你是一名高手,那这些都不是问题;而 Spring Cloud 就像品牌机,在 Spring Source 的整合下,做了大量的兼容性测试,保证了机器拥有更高的稳定性,但是如果要在使用非原装组件外的东西,就需要对其基础有足够的了解。
.NET Core的兼容方案
==================
若使用 Spring Cloud,.NET Core 兼容 Spring Cloud 比较好实现,因为基于 REST 服务调用,可以自行实现其服务(Eureka 提供 REST API 进行服务注册),也已有成熟的开源框架如 Steeltoe。
官方介绍:
互联网大厂比较喜欢的人才特点:对技术有热情,强硬的技术基础实力;主动,善于团队协作,善于总结思考。无论是哪家公司,都很重视高并发高可用技术,重视基础,所以千万别小看任何知识。面试是一个双向选择的过程,不要抱着畏惧的心态去面试,不利于自己的发挥。同时看中的应该不止薪资,还要看你是不是真的喜欢这家公司,是不是能真的得到锻炼。其实我写了这么多,只是我自己的总结,并不一定适用于所有人,相信经过一些面试,大家都会有这些感触。
**另外本人还整理收藏了2021年多家公司面试知识点以及各种技术点整理 **
下面有部分截图希望能对大家有所帮助。
会有这些感触。
**另外本人还整理收藏了2021年多家公司面试知识点以及各种技术点整理 **
下面有部分截图希望能对大家有所帮助。
[外链图片转存中…(img-EUgqzLzE-1715081289129)]
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。