系统中间件介绍

系统中间件是一类位于操作系统和应用程序之间的软件，它们提供了一种通信机制，使不同的应用程序或系统能够相互交互和协作。系统中间件可以按照不同的标准进行分类，以下是一些常见的系统中间件：

1. 事务式中间件：提供联机事务处理所需的通信、并发访问控制、事务控制、资源管理、安全管理、负载平衡、故障恢复等服务，如Oracle Tuxedo等。
2. 过程式中间件：又称远程过程调用中间件，通过同步通信或线程式异步调用实现客户和服务器之间的通信，如CORBA等。
3. 面向消息的中间件：利用消息机制实现不同应用间的数据交换，支持消息队列和消息传递两种通信模型，如RabbitMQ、ActiveMQ等。
   1. RabbitMQ五种消息模型
      1. simple消息模：一个生产者  一个队列  一个消费者
         1. 在此种消费模型下，若消费者对消息的处理速度较慢。那么当生产者不断向队列发送消息时，便会造成堵塞。
      2. work消息模型：一个生产者  一个队列  多个消费者
         1. 由此模型衍生的 -> 能者多劳：消费者性能高的可以多消费消息
      3. fanout消息模型 发布/订阅模式：一个生产者  一个交换机  多个队列  多个消费者
         1. 这种模型下，生产着会将消息发送至交换机。再由交换机以广播的形式发送给所有消费者，由消费者在自己相应的队列获取消息。
         2. 这种模型存在一个缺点，就是无法对消息进行过滤。于是引出direct消息模型 direct消息模型 
      4. 路由模式：一个生产者  一个交换机  多个队列  多个消费者(队列绑定交换机时需要指定RoutingKey)
         1. 缺点：RoutingKey是需要提前固定写好的。那么当大量的消息到来时，RoutingKey的指定会影响到性能
      5.  topic消息模型: 开发中常用此种模型：一个生产者  一个交换机  多个队列  多个消费者(队列绑定交换机时使用的RoutingKey可以使用通配符)
         1. 通配符：* 匹配 一级 任意多个字符，# 匹配 多级 任意多个字符
         2. 例如：routingKey为"user.#"，表示可以匹配"user.add"和"user.add.log"。
         3. routingKey为"user.*"，表示可以匹配"user.add"，对于"user.add.log"则无法匹配。
   2. ActiveMQ
      1. ActiveMQ提供了两种消息模式：点对点模式（Queue）、发布订阅模式（Topic），这两种模式基本上可以覆盖大部分的需求了。
      2. 点对点模式（Queue）
         1. 点对点模式使用队列作为中间媒介，这里的队列就是我们所理解的一个先进先出的一个结构，一个或者多个生产者将消息发送到队列，然后多个消费者从队列安装消息的先后顺序去消费，注意，队列中的消息只会被一个消费者接受所消费。
      3. 发布订阅模式（Topic）
         1. 发布订阅模式使用topic作为中间媒介，而topic可以认为就是一个广播站，当一个或者多个生产者将消息发布到topic广播站之后，topic广播站会往当前已经注册订阅的每一个消费者广播消息（这里的消费者我们称为订阅者），注意，这里每一个订阅者都会收到消息。
4. 面向对象中间件：结合分布式计算技术和面向对象技术，提供对象管理、事务处理、分布式数据访问等服务，如CORBA等。
5. Web应用服务器中间件：提供Web服务器和应用服务器相结合的产物，如Apache Tomcat等。
6. 缓存中间件：提高应用程序性能，通过缓存常用数据和对象减少对后端系统的请求次数，如Redis、Memcached等。
7. 应用服务器中间件：用于处理应用程序的业务逻辑，如Apache Tomcat、JBoss等。
8. 消息中间件：用于在应用程序之间进行异步消息传递，如RabbitMQ、Apache Kafka、ActiveMQ等。（消息队列：kafka，）
   1. Kafka的特性
      1. 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒
      2. 可扩展性：kafka集群支持热扩展
      3. 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
      4. 容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）
      5. 高并发：支持数千个客户端同时读写
   2. Kafka场景应用
      1. 日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等
      2. 消息系统：解耦和生产者和消费者、缓存消息等。
      3. 用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
      4. 运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。
      5. 流式处理：比如spark streaming和storm事件源
   3. kafka一些重要设计思想
      1. Consumergroup：各个consumer可以组成一个组，每个消息只能被组中的一个consumer消费，如果一个消息可以被多个consumer消费的话，那么这些consumer必须在不同的组。
      2. 消息状态：在Kafka中，消息的状态被保存在consumer中，broker不会关心哪个消息被消费了被谁消费了，只记录一个offset值（指向partition中下一个要被消费的消息位置），这就意味着如果consumer处理不好的话，broker上的一个消息可能会被消费多次。
      3. 消息持久化：Kafka中会把消息持久化到本地文件系统中，并且保持极高的效率。（data文件夹）
      4. 消息有效期：Kafka会长久保留其中的消息，以便consumer可以多次消费，当然其中很多细节是可配置的。
      5. 批量发送：Kafka支持以消息集合为单位进行批量发送，以提高push效率。
      6. push-and-pull :Kafka中的Producer和consumer采用的是push-and-pull模式，即Producer只管向broker push消息，consumer只管从broker pull消息，两者对消息的生产和消费是异步的。
      7. Kafka集群中broker之间的关系：不是主从关系，各个broker在集群中地位一样，我们可以随意的增加或删除任何一个broker节点。
      8. 负载均衡方面： Kafka提供了一个 metadata API来管理broker之间的负载（对Kafka0.8.x而言，对于0.7.x主要靠zookeeper来实现负载均衡）。
      9. 同步异步：Producer采用异步push方式，极大提高Kafka系统的吞吐率（可以通过参数控制是采用同步还是异步方式）。
      10. 分区机制partition：Kafka的broker端支持消息分区，Producer可以决定把消息发到哪个分区，在一个分区中消息的顺序就是Producer发送消息的顺序，一个主题中可以有多个分区，具体分区的数量是可配置的。分区的意义很重大，后面的内容会逐渐体现。
      11. 离线数据装载：Kafka由于对可拓展的数据持久化的支持，它也非常适合向Hadoop或者数据仓库中进行数据装载。
      12. 插件支持：现在不少活跃的社区已经开发出不少插件来拓展Kafka的功能，如用来配合Storm、Hadoop、flume相关的插件。
   4. 消息队列通信的模式
      1. 点对点模式：点对点模式通常是基于拉取或者轮询的消息传送模型，这个模型的特点是发送到队列的消息被一个且只有一个消费者进行处理。生产者将消息放入消息队列后，由消费者主动的去拉取消息进行消费。点对点模型的的优点是消费者拉取消息的频率可以由自己控制。但是消息队列是否有消息需要消费，在消费者端无法感知，所以在消费者端需要额外的线程去监控。
      2. 发布订阅模式：发布订阅模式是一个基于消息送的消息传送模型，改模型可以有多种不同的订阅者。生产者将消息放入消息队列后，队列会将消息推送给订阅过该类消息的消费者（类似微信公众号）。由于是消费者被动接收推送，所以无需感知消息队列是否有待消费的消息！但是consumer1、consumer2、consumer3由于机器性能不一样，所以处理消息的能力也会不一样，但消息队列却无法感知消费者消费的速度！所以推送的速度成了发布订阅模模式的一个问题！假设三个消费者处理速度分别是8M/s、5M/s、2M/s，如果队列推送的速度为5M/s，则consumer3无法承受！如果队列推送的速度为2M/s，则consumer1、consumer2会出现资源的极大浪费！
   5. Kafka的架构原理
      1. 基础架构与名词解释
         1. Producer：Producer即生产者，消息的产生者，是消息的入口。
         2. Broker：Broker是kafka实例，每个服务器上有一个或多个kafka的实例，我们姑且认为每个broker对应一台服务器。每个kafka集群内的broker都有一个不重复的编号，如图中的broker-0、broker-1等……
         3. Topic：消息的主题，可以理解为消息的分类，kafka的数据就保存在topic。在每个broker上都可以创建多个topic。
         4. Partition：Topic的分区，每个topic可以有多个分区，分区的作用是做负载，提高kafka的吞吐量。同一个topic在不同的分区的数据是不重复的，partition的表现形式就是一个一个的文件夹！
         5. Replication:每一个分区都有多个副本，副本的作用是做备胎。当主分区（Leader）故障的时候会选择一个备胎（Follower）上位，成为Leader。在kafka中默认副本的最大数量是10个，且副本的数量不能大于Broker的数量，follower和leader绝对是在不同的机器，同一机器对同一个分区也只可能存放一个副本（包括自己）。
         6. Message：每一条发送的消息主体。
         7. Consumer：消费者，即消息的消费方，是消息的出口。
         8. Consumer Group：我们可以将多个消费组组成一个消费者组，在kafka的设计中同一个分区的数据只能被消费者组中的某一个消费者消费。同一个消费者组的消费者可以消费同一个topic的不同分区的数据，这也是为了提高kafka的吞吐量！
         9. Zookeeper：kafka集群依赖zookeeper来保存集群的的元信息，来保证系统的可用性。
      2. 保存数据
         1. Producer将数据写入kafka后，集群就需要对数据进行保存了！kafka将数据保存在磁盘，可能在我们的一般的认知里，写入磁盘是比较耗时的操作，不适合这种高并发的组件。Kafka初始会单独开辟一块磁盘空间，顺序写入数据（效率比随机写入高）。
         2. Partition 结构：前面说过了每个topic都可以分为一个或多个partition，如果你觉得topic比较抽象，那partition就是比较具体的东西了！Partition在服务器上的表现形式就是一个一个的文件夹，每个partition的文件夹下面会有多组segment文件，每组segment文件又包含.index文件、.log文件、.timeindex文件（早期版本中没有）三个文件， log文件就实际是存储message的地方，而index和timeindex文件为索引文件，用于检索消息。
         3. Message结构：上面说到log文件就实际是存储message的地方，我们在producer往kafka写入的也是一条一条的message，那存储在log中的message是什么样子的呢？消息主要包含消息体、消息大小、offset、压缩类型……等等！我们重点需要知道的是下面三个：
            1. offset：offset是一个占8byte的有序id号，它可以唯一确定每条消息在parition内的位置！
            2. 消息大小：消息大小占用4byte，用于描述消息的大小。
            3. 消息体：消息体存放的是实际的消息数据（被压缩过），占用的空间根据具体的消息而不一样。
      3. 存储策略：无论消息是否被消费，kafka都会保存所有的消息。那对于旧数据有什么删除策略呢？
         1. 基于时间，默认配置是168小时（7天）。
         2. 基于大小，默认配置是1073741824。
         3. 需要注意的是，kafka读取特定消息的时间复杂度是O(1)，所以这里删除过期的文件并不会提高kafka的性能！
      4. 消费数据
         1. 消息存储在log文件后，消费者就可以进行消费了。在讲消息队列通信的两种模式的时候讲到过点对点模式和发布订阅模式。Kafka采用的是发布订阅模式，消费者主动的去kafka集群拉取消息，与producer相同的是，消费者在拉取消息的时候也是找leader去拉取。
         2. 多个消费者可以组成一个消费者组（consumer group），每个消费者组都有一个组id！同一个消费组者的消费者可以消费同一topic下不同分区的数据，但是不会组内多个消费者消费同一分区的数据！！！
         3. 这套机制是建立在offset为有序的基础上，利用segment+有序offset+稀疏索引+二分查找+顺序查找等多种手段来高效的查找数据！至此，消费者就能拿到需要处理的数据进行处理了。那每个消费者又是怎么记录自己消费的位置呢？在早期的版本中，消费者将消费到的offset维护zookeeper中，consumer每间隔一段时间上报一次，这里容易导致重复消费，且性能不好！在新的版本中消费者消费到的offset已经直接维护在kafk集群的__consumer_offsets这个topic中！
9. 数据库中间件：管理和访问数据库，如MySQL Proxy、PostgreSQL PgBouncer等。
10. API网关中间件：管理和控制API的访问和调用，如Kong、Apigee等。
    1. 身份验证和授权：确保只有经过身份验证和授权的用户能够访问API。
    2. 访问控制：限制特定用户或角色对API的访问权限。
    3. 数据加密：通过加密API请求和响应中的数据，保护数据的机密性。
    4. 负载均衡：平衡API请求的负载，确保高性能和可扩展性。
    5. 缓存优化：缓存经常请求的API响应，减少对后端服务的依赖。
    6. API监控和分析：实时监控API的使用情况和性能指标，提供有关API的详细分析报告。
    7. 开发者门户：提供API文档、代码示例和测试工具等开发者所需的资源。