中间件技术非常的多，但大体分为：

  • 分布式消息中间件
  • 负载均衡中间件
  • 缓存中间件
  • 数据库中间件

下面我们简单来看一看

分布式消息中间件

  • ActiveMQ

    遵循JMS规范、AMQP协议的消息中间件，使用Java语言开发，老牌的分布式消息中间件

    但相对于业界其它的MQ而言，复杂程度较高

  • RabbitMQ

    目前很流行的消息中间件，它支持的协议、分发的模式、持久化等等是比较完善的。并且它和Spring师出同门，因此Spring对RabbitMQ的支持比较完善

  • Kafka

    高性能消息中间件的代言人，它是基于TCP/IP这种二进制的协议来开发的，所以它的性能非常高，因为它最接近底层

    不支持事务，但支持持久化和部分分发机制

  • RocketMQ

    阿里、滴滴联合开发的国产消息队列

    支持事务

使用场景

  • 消息中间件监控场景
  • 异步数据传输场景
  • 削峰填谷场景
  • 任务调度场景
  • 海量数据同步场景
  • 分布式事务场景
  • 大数据分析场景

协议

之前我们了解到，中间件的特点：要遵守协议（为了传输数据）、持久化（高可用）、扩展性（做集群）等等。这里我们来看看消息中间件要遵循哪些协议

  • AMQP
  • MQTT
  • Kafka协议
  • OpenMessage

我们不是有TCP/IP协议、UDP协议吗，为什么还要搞这么多协议出来

因为TCP/IP协议无法满足我们的需求，所以我们在TCP/IP协议基础之上重新构建了一些内容，就成了上述协议。注意，这些协议的底层仍然是TCP/IP协议

负载均衡中间件

  • Nginx（重点）
  • LVS负载均衡中间件
  • KeepAlive
  • CDN（重点）

缓存中间件

  • MemCache

    将缓存数据写在代码中，因此会占用JVM的内存，小型项目适用

  • Redis（重点）

    分布式架构下，缓存中间件的首选

数据库中间件

MySQL天然支持持久化，但它并不具备高可用（因为MySQL本身不支持集群），如果我们要实现MySQL的集群以及分库分表，需要使用如下的第三方中间件，实现MySQL的高可用

  • MyCat
  • ShardingJDBC

单体式架构 vs 分布式架构

对于早期的单体式应用来说，所有的业务模块、所有的源代码、静态资源文件都放在同一个工程中，其中一个模块做了很小的改动，就需要重新编译和部署整个项目。随着业务不断膨胀，它的问题暴露如下：

  • 耦合度高
  • 维护性差
  • 后续架构升级的难度大

基于以上的种种问题，我们引入了分布式架构

单体式应用中，一个请求由一个系统处理。而在分布式架构中，一个请求由服务端的多个服务协同处理完成

它的问题如下：

  • 学习成本高
  • 运维成本和服务器成本高
  • 系统的可用性虽然提升，但面临的错误也会成倍增加
  • 基于安全性的考虑，迫使我们选择RMI/MQ来进行服务器之间的通讯

好处：

  • 可以合理的分配服务器资源，减少了服务器资源的浪费
  • 各个模块可以独立的维护和部署，降低耦合度，不会造成整个平台因部署而造成的停服状态
  • 系统的架构和技术栈变得灵活（除了Java，我们还可以选择python和Golang）

谁更好？

没有最好的架构，只有最合适的架构