【热点】Kafka与传统中间件(MQ,ETL,ESB)的比较
自从Linkin开源Kafka之后,它似乎成了可以叫嚣所有传统消息中间件产品的行业新宠。事实上他也确实成为了大规模消息、微服务解耦以及可靠轻量流处理的业界标准解决方案。 我们知道在传统企业的数据汇聚层,往往会涉及到四到五种产品或者是开源的框架并且支持高可用和横向扩展。 ![1](https://yqfile.alicdn.com/dd6c1a62c4b2f17f32f0db22e0732812017e1e18.jpeg) 上述架构首先会带来技术栈的多样化,包括有:
集成化平台(ETL/ESB)加上额外的“可选”组件;
消息系统(消息队列,点到点RPC调用);
内存缓存或数据网格;
数据库;
流数据引擎;
API网关
对于企业而言,技术的多样性从来不是好事,这意味着需要招募不同技术特长的人员,缺乏端到端的扩展性,要为每个场景设置中继(例如大型企业内部会有几百组MQ集群),每个组件需要分别维护和配置管理且版本依赖性强。 我们看到近些年很多中间件公司都出现了衰败的现象,像IBM,Oracle。主要是因为IT生态圈出现了重要转变,伴随着企业数字化转型的五大趋势,系统间事务处理进入了大规模、快速度和高效率的时代
在这样的大趋势下,传统的紧耦合、有限规模、组件复杂的传统技术栈开始出现严重的性能瓶颈。架构师们意识到需要转变交互思路,可能一个简单的、可扩展的、松耦合的基于事件的平台才能解决实时性大数据并发处理的难题。
广义上说事件可以是一期市场活动,一张发票,一笔交易或一次客户体验等等,基于事件的平台以事件为核心建立系统间的交互。在这个平台上,数据库和数据仓库的接口功能被弱化,甚至其本身不再是通过CRUD来编辑数据,而是作为事件的持久化存储(数据仓库)以及面向应用对事件进行优化展示(数据库)。
而流处理/实时处理平台是事件驱动交互的基石。它向企业提供了全局化的数据/事件链接(不同业务只需明确是数据生产者还是消费者即可)、即时数据访问、单一系统统管全域数据以及持续索引/查询能力。
Apache Kafka就是这样一个实时事件处理平台,可以将各类应用的事务流按照主题分类并分发给对应的订阅者/消费者。它的吞吐量也是受到广泛验证的,比如其创始公司领英的每日消息处理量超过4,500,000,000,000条,Netflix日均处理量在6PB以上。
而且,Kafka平台几乎不涉及其他技术栈,它的消息系统、持久化存储和缓存用的都是自身的内核,实时和批处理工作在客户端完成,数据集成靠自身的连接器,流处理有自身的流式引擎KSQL,请求/响应机制通过REST代理完成。 市场上的同类产品早先有ActiveMQ和RabbitMQ,在领英将Kafka开源后,市场几乎被垄断。直到阿里基于Kafka研制出了新的Apache顶级项目RocketMQ,并且经过双十一的高压打磨后,Kafka才真正有了市场竞争对手,
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
【实战】持续集成与持续交付
今天我们讨论CI/CD,即持续集成(Continuous Integration)与持续部署(Continuous Deployment),这对于软件交付工程师或程序员来说非常重要。 首先我们说CI-持续集成,这是为保证不同功能的开发人员所贡献的代码保持同步,简单的说就是通过自动测试、验证与反馈的方式实现程序员间的协同。比如说开发团队将自己的代码库都放在Github上,然后每个开发人员都Fork了一个副本在本地做开发测试,最终我们希望将每个开发人员的代码段集成到主线(Mainline)中,在这之前我们需要创建测试案例保证程序不仅可以单步运行,也可以按照主线的逻辑运行不至于影响其他模块。在持续集成的场景中,开发人员可以不断拉测试案例来验证程序运行正常,与主线兼容良好,不会在发布时有巨大改动。 再说持续部署,他将持续集成所编译的程序部署到环境中,既然是持续部署,就可以是某个特定项目的多个场景,比如说临时环境(Staging Environment)、测试环境(Testing Environment)、验收环境(Acceptance Environment)最后是生产环境(Productio...
- 下一篇
【热点】微信的消息收发机制
微信可能是国内最早一批做微服务架构体系的,毕竟微服务的理念与腾讯一直倡导的“大系统小做”有很多相通之处,当然微信的功能有很多,衣食住行都能找到入口。我们今天单说它的原生功能:即时通信。 这块内容本座想分两部分来讲,第一部分是点到点聊天,第二部分是群组聊天。这两种聊天模式有共同点,比如说已读信息不会在服务端保留,因此换新手机是找不到历史消息的。也有不同点,比如服务端的架构和数据流等等。 先说点到点聊天,手机端通过打开微信软件建立了到腾讯云的微信网关,当然考虑到就近访问与负载平衡,不同客户端可能连到不同的网关。当A用户通过网关B发送微信给在线用户B时,会话微服务会记录当前所有用户的连入信息,维护如下的用户-网关表: 用户 网关A BB CC C 如果对端用户不在线,则会记录上次连接的网关,如果从来没在线过则随机分配网关。这张表虽然有高达10亿的记录(微信用户数量),但好在只是一张二维表而且可做冷热分离,因此存储量并不大,然后各个网关上会有热数据的分布式缓存。 为什么要这样做呢,因为我们知道让一台网关服务器来维持每一个客户端的TCP连接是非常消耗内存的,鉴于微信用户的数量,一般硬件的性能是无...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS8安装Docker,最新的服务器搭配容器使用
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS8编译安装MySQL8.0.19
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Hadoop3单机部署,实现最简伪集群
- CentOS7,CentOS8安装Elasticsearch6.8.6