Kafka是一种分布式流处理平台，最初由Linkedln开发，现在是Apache基金会的一部分。它的核心功能主要包括消息队列、流处理和数据集成。Kafka以高吞吐 量、低延迟、可扩展和高容错性著称。kafka官网
Kafka的主要应用场景有:
1)消息队列:用作高吞吐量的消息系统，将消息从一个系统传递另一个系统。
2)日志收集:集中收集日志数据，然后通过Kafka传递到实时监控系统或存储系统。
3)流计算:处理实时数据流，将数据传递给实时计算系统，如Apache Storm或Apache Flink.
4)事件溯源:记录事件发生的历史，以便稍后进行数据回溯或重亲处理。
5)Metrics收集和监控:收集来自不同服务的监控指标，统一存储和处理。
6)数据集成:在不同的数据存储系统之间传递和同步数据。
对一个视频的转码可以理解为一个任务的执行，如果视频的数量比较多，如何去高效处理一批任务呢？
1、多线程，多线程是充分利用单机的资源。
2、分布式加多线程，充分利用多台计算机，每台计算机使用多线程处理。
方案2可扩展性更强，方案2是一种分布式任务调度的处理方案。
什么是分布式任务调度？
思考： 我们可以先思考一下下面业务场景的解决方案：
类似的场景还有很多，我们该如何实现？
文件系统是负责管理和存储文件的系统软件，操作系统通过文件系统提供的接口去存取文件，用户通过操作系统访问磁盘上的文件。
下图指示了文件系统所处的位置：
在已知的操作系统中，它们分别支持多种不同的文件系统。Windows 下支持 FAT、FAT32、NTFS，Linux 支持十多种的文件系统，例如：EXT2、EXT3、EXT4、NFS、NTFS等。
我们改造了余额支付功能，在支付成功后利用RabbitMQ通知交易服务，更新业务订单状态为已支付。但是如果这里MQ通知失败，支付服务中支付流水显示支付成功，而交易服务中的订单状态却显示未支付，数据出现了不一致。此时前端发送请求查询支付状态时，肯定是查询交易服务状态，会发现业务订单未支付，而用户自己知道已经支付成功，这就导致用户体验不一致。
因此，这里我们必须尽可能确保MQ消息的可靠性，即：消息应该至少被消费者处理1次
那么问题来了：
目前我们服务之间调用采用的都是基于OpenFeign的调用。这种调用中，调用者发起请求后需要等待服务提供者执行业务返回结果后，才能继续执行后面的业务。也就是说调用者在调用过程中处于阻塞状态，因此我们称这种调用方式为同步调用，也可以叫同步通讯。但在很多场景下，我们可能需要采用异步通讯的方式，为什么呢？
我们先来看看什么是同步通讯和异步通讯。如图：
由于订单、购物车、商品分别在三个不同的微服务，而每个微服务都有自己独立的数据库，因此下单过程中就会跨多个数据库完成业务。而每个微服务都会执行自己的本地事务：
整个业务中，各个本地事务是有关联的。因此每个微服务的本地事务，也可以称为分支事务。多个有关联的分支事务一起就组成了全局事务。我们必须保证整个全局事务同时成功或失败。
在微服务远程调用的过程中，还存在几个问题需要解决。
首先是业务健壮性问题：
例如在之前的查询购物车列表业务中，购物车服务需要查询最新的商品信息，与购物车数据做对比，提醒用户。大家设想一下，如果商品服务查询时发生故障，查询购物车列表在调用商品服 务时，是不是也会异常？从而导致购物车查询失败。但从业务角度来说，为了提升用户体验，即便是商品查询失败，购物车列表也应该正确展示出来，哪怕是不包含最新的商品信息。
还有级联失败问题：
到目前为止我们已经解决了微服务相关的几个问题：
不过，现在依然还有几个问题需要解决：
这些问题都可以通过统一的配置管理器服务解决。而Nacos不仅仅具备注册中心功能，也具备配置管理的功能：
什么是网关？
顾明思议，网关就是网络的关口。数据在网络间传输，从一个网络传输到另一网络时就需要经过网关来做数据的路由和转发以及数据安全的校验。
更通俗的来讲，网关就像是以前园区传达室的大爷。
在拆分黑马商城的时候，我们发现一个问题：就是购物车业务中需要查询商品信息，但商品信息查询的逻辑全部迁移到了item-service服务，导致我们无法查询。
最终结果就是查询到的购物车数据不完整，因此要想解决这个问题，我们就必须改造其中的代码，把原本本地方法调用，改造成跨微服务的远程调用（RPC，即Remote Produce Call）。
那么问题来了：我们该如何跨服务调用，准确的说，如何在cart-service中获取item-service服务中的提供的商品数据呢？
