Kafka在微服务架构中的关键角色与优化实践-优快云博客

Kafka分享总览

背景介绍

架构演变

垂直应用架构

以经典的MVC垂直架构为例
在这里插入图片描述

mvc架构主要分为三层

视图层，交互界面
控制层，前端web请求分发
应用模型层，主要业务逻辑

对于应用规模较小时，还能支撑业务发展。随着系统逐渐增大，会出现很多弊端

开发维护成本变高，部署效率逐渐降低
团队协作效率差，功能重复开发，代码重复率高
系统可靠性差。访问量升高，对网络流量、负载、数据库连接压力变大。某个节点故障，导致分摊到其他节点的流量陡增，引起"雪崩效应"
维护定制困难
新功能上线周期长

RPC架构

RPC是一种进程间通信方式。允许像本地服务一样调用远程服务。因此可以将一个大的服务拆分成多个服务，服务之间通过RPC调用

RPC架构面临的挑战

服务越来越多，服务间URL的管理变得困难
随着业务发展，服务间依赖关系变得错综复杂
服务上线容易下线难
服务化后，服务治理问题

SOA服务化架构

SOA是一种粗粒度、松耦合的以服务为中心的架构，接口之间通过明确协议和接口进行通信

SOA面向服务的一般原则：

服务可复用
服务共享一个标准契约
服务松耦合
服务是底层逻辑的抽象
服务可编排
服务自治
服务无状态
服务可被自动发现

微服务架构

微服务架构是一种服务化架构风格，将功能分散到各个离散的服务中以实现对解决方案的解耦

微服务架构主要特征

原子服务，专注做一件事情
高密度部署
敏捷交付
微自治

相较于SOA的差异

服务拆分粒度：SOA解决异构应用服务化；微服务强调服务拆分尽可能小
服务依赖：传统SOA服务，存在大量的服务间依赖；微服务服务自治，功能单一，避免耦合
敏捷交付

Kafka在系统架构中的作用

系统解耦

随着系统架构向微服务发展，每个微服务功能变得单一，但微服务之间一定会存在某些联系，对于某些并不是强关联的业务，可以通过类似于Kafka这样的消息中间件进行系统解耦

异步调用提升性能

在一个业务中如果需要多个微服务参与其中，可以通过消息中间件异步调用，将响应时间缩短

削峰填谷

对于某些业务可能瞬时请求量特别大，比如秒杀系统。当大量请求进入系统，会对系统造成负担，甚至服务不可用。通过消息中间件，可以先让用户请求放入消息中间件，各处理服务根据自身处理能力，处理请求

Kafka系列分享目标

会使用Kafka进行消息发送、消费
知道Kafka设计原理
能管理Kafka集群
会监控Kafka集群，发现问题
能调优Kafka

Kafka系列分享概览

Kafka架构概览

在实际应用场景中我们总会遇到,如何去提升系统性能、如果降低系统间的耦合性、如何在高并发下也能让系统正常且高速的运转.消息中间件正是为应对这些需求而产生.Kakfa由美国领英研发的消息中间件平台,目的是为了收集业务系统和应用程序的性能监控指标数据及用户操作行为数据.其实更准确的说Kafka是一个分布式事件流平台,在Kafka的发展过程中渐渐加入了实时数据流处理功能.研究Kafka也正是为了更好的异步提升系统性能、降低系统间的耦合性、流量削峰
在这里插入图片描述

生产端

Kafka producer客户端负责向Kafka写入数据的应用程序。Kafka提供了多个语言版本的producer客户端。Kafka封装了一套二进制通信协议，对于producer而言，用户可以直接使用任意语言按照该协议的格式进行编程，实现消息的发送
在这里插入图片描述

消费端

消费者组定义：消费者使用一个消费者组名（即group.id）来标记自己，topic的每条消息都只会被发送到每个订阅它的消费者组的一个消费者实例上

Kafka同时支持基于队列和基于发布/订阅的两种消息引擎模型，事实上Kafka是通过consumer group实现对这两种模型的支持.所有consumer实例都属于相同group—实现基于队列的模型，每条消息只会被一个consumer实例处理;consumer实例都属于不同group—实现基于发布/订阅的模型，极端的情况是每个consumer实例都设置完全不同都group，这样kafka消息就会被广播到所有consumre实例
在这里插入图片描述

broker端

broker是Apache Kafka最重要的组件，本质上它是一个功能载体，承载了绝大多数的Kafka服务。一个broker通常是以服务器形式出现，broker的主要功能就是持久化消息以及将消息队列中的消息从发送端传输到消费端。Kafka broker负责持久化producer端发送消息，同时为consumer端提供消息。将从下面八个方面分享