微服务中间件有哪些，常见的中间件有哪些

大家好，关于微服务中间件有哪些很多朋友都还不太明白，今天小编就来为大家分享关于常见的中间件有哪些的知识，希望对各位有所帮助！

常见的中间件有哪些

常见的中间件有：我们经常管中间件叫做中间件服务器，也会叫作应用服务器。正常情况下一次web的访问顺序是：web浏览器---web服务器（W3的那个，非广义）---web容器---应用服务器---数据库服务器。

本地开发经常使用的应用服务器就是tomcat，linux系统经常使用的是jetty或apachehpptd，大型的项目就用的JBOSS或webloigc。

小项目，或者是个人开发tomcat大项目或者商业项目采用：weblgoic/webshere其他的还有jboss、glasshfish等，一些示例项目或者小项目常采用jetty。

Tomcat：是Sun的JSWDK(JavaServerWebDevelopmentKit)中Servlet的运行环境(servlet容器)。Tomcat是ApacheJakarta软件组织的一个子项目，Tomcat是一个JSP/Servlet容器，它是在SUN公司的JSWDK（JavaServerWebDevelopmentKit）基础上发展起来的一个JSP和Servlet规范的标准实现，使用Tomcat可以体验JSP和Servlet的最新规范。经过多年的发展，Tomcat不仅是JSP和Servlet规范的标准实现，而且具备了很多商业JavaServlet容器的特性，并被一些企业用于商业用途。

JBoss：是一个运行EJB的J2EE应用服务器。它是开放源代码的项目，遵循最新的J2EE规范。从JBoss项目开始至今，它已经从一个EJB容器发展成为一个基于的J2EE的一个web操作系统（operatingsystemforweb），它体现了J2EE规范中最新的技术

WebLogic服务器：是企业级的应用服务器，支持EJB，集群以及ERP（企业资源计划）的连通性，开发公司：BEA。

常用的中间件有哪几种

中间件是指位于应用程序和操作系统之间的软件组件，其作用是协调应用程序和操作系统之间的数据传输和通信。中间件通常用于解决分布式系统中的通信和数据传输问题。常用的中间件种类有以下几种：

1.消息队列中间件：用于协调分布式系统中不同节点之间的消息传递，可以保证消息的可靠性和顺序性。

2.缓存中间件：用于缓存应用程序的数据，减少对数据库的访问，提高应用程序性能。

3. RPC中间件：用于在分布式系统中进行远程过程调用，可以让不同节点之间的应用程序像调用本地函数一样进行通信。

4.数据库中间件：用于管理多个数据库之间的数据访问和交互，可以提高数据库的可伸缩性和可用性。

5. Web服务器中间件：用于处理Web应用程序的请求和响应，可以提供负载均衡和高可用性等功能。

这些中间件都有各自的特点和适用场景，在实际应用中需要根据具体的需求进行选择和配置。使用中间件可以有效地简化应用程序的开发和运维工作，提高应用程序的性能和可靠性，是现代分布式系统开发中不可或缺的组成部分。

微服务想搞好,消息中间件不能少,Kafka基础入门介绍

现在微服务流行，很多公司起项目都是分布式微服务，但是你想过没有，不是把一个单体拆开了，用域名去相互调就叫微服务。好的微服务架构设计模式里要求每个服务的自治性，这样服务拆分成微服务后才能稳定。

怎么才能让每个服务尽量达到自治性呢？这就需要领域事件、事件溯源、CQRS、Saga这些设计模式，不好意思一下子说了很多概念，以后慢慢给大家解释。

这几个模式里边有个关键点—需要通过把领域事件发布给远程的其他服务，完成数据同步。这就需要消息中间件了，消息中间件这块我了解的也不深，公司里用RocketMQ，不过付费版和开源版差别很大。

听说Rocket MQ很多概念也来自Kafka，学会它其他的消息中间件基本也大差不差的都会了，今天分享一篇Kafka的基础入门文章给大家

Kafka是一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用与大数据实时处理领域。其主要设计目标如下：

Kafka本质上是一个 MQ（Message Queue），使用消息队列的好处？

下面给出 Kafka一些重要概念，让大家对 Kafka有个整体的认识和感知

Kafka分区

Kafka和Zookeeper的关系

在了解kafka集群之前,我们先来了解下kafka的工作流程, Kafka集群会将消息流存储在 Topic的中，每条记录会由一个Key、一个Value和一个时间戳组成。

Kafka的工作流程

Kafka中消息是以 Topic进行分类的，生产者生产消息，消费者消费消息，读取和消费的都是同一个 Topic。但是Topic是逻辑上的概念， Partition是物理上的概念，每个 Partition对应一个 log文件，该 log文件中存储的就是 Producer生产的数据。 Producer生产的数据会不断顺序追加到该 log文件末尾，并且每条数据都会记录有自己的 Offset。而消费者组中的每个消费者，也都会实时记录当前自己消费到了哪个 Offset，方便在崩溃恢复时，可以继续从上次的 Offset位置消费。

Kafka存储机制

此时 Producer端生产的消息会不断追加到 log文件末尾，这样文件就会越来越大,为了防止 log文件过大导致数据定位效率低下，那么Kafka采取了分片和索引机制。它将每个 Partition分为多个 Segment，每个 Segment对应4个文件：“.index”索引文件,“.log”数据文件,“.snapshot”快照文件,“.timeindex”时间索引文件。这些文件都位于同一文件夹下面，该文件夹的命名规则为：topic名称-分区号。例如, heartbeat心跳上报服务这个 topic有三个分区，则其对应的文件夹为 heartbeat-0，heartbeat-1，heartbeat-2这样。

index, log, snapshot, timeindex文件以当前 Segment的第一条消息的 Offset命名。其中“.index”文件存储大量的索引信息，“.log”文件存储大量的数据，索引文件中的元数据指向对应数据文件中 Message的物理偏移量。

下图为index文件和 log文件的结构示意图：

index文件和 log文件的结构示意图

kafka中的 Partition为了保证数据安全，每个 Partition可以设置多个副本。此时我们对分区0,1,2分别设置3个副本（注:设置两个副本是比较合适的）。而且每个副本都是有"角色"之分的，它们会选取一个副本作为 Leader副本，而其他的作为 Follower副本，我们的 Producer端在发送数据的时候，只能发送到Leader Partition里面，然后Follower Partition会去Leader那自行同步数据, Consumer消费数据的时候，也只能从 Leader副本那去消费数据的。

Kafka集群副本

Kafka集群副本

Kafka Controller，其实就是一个 Kafka集群中一台 Broker，它除了具有普通Broker的消息发送、消费、同步功能之外，还需承担一些额外的工作。Kafka使用公平竞选的方式来确定 Controller，最先在 ZooKeeper成功创建临时节点/controller的Broker会成为 Controller，一般而言，Kafka集群中第一台启动的 Broker会成为Controller，并将自身 Broker编号等信息写入ZooKeeper临时节点/controller。

Consumer在消费过程中可能会出现断电宕机等故障，在 Consumer恢复后，需要从故障前的 Offset位置继续消费。所以 Consumer需要实时记录自己消费到了哪个 Offset，以便故障恢复后继续消费。在 Kafka 0.9版本之前，Consumer默认将 Offset保存在 ZooKeeper中，但是从 0.9版本开始，Consumer默认将 Offset保存在 Kafka一个内置的 Topic中，该 Topic为 __consumer_offsets,以支持高并发的读写。

上面和大家一起深入探讨了 Kafka的简介,基础知识和集群架构，下一篇会从Kafka三高(高性能,高可用,高并发)方面来详细阐述其巧妙的设计思想。大家期待.....