公司中台项目总结（一）技术选型

公司中台项目总结（一）技术选型

---

最近，应公司老大要求，对公司已有的SaaS平台进行整体的架构调整。相当于废弃旧平台，将功能以及一些需求全部迁移到新的平台，而且新平台之前也没有一个基础的base版本，只能从0开始重构。这就比较麻烦，涉及到技术选型和框架选型。基本技术的话确定是Java+VUE+Negix+Springboot+SpringCloud+SpringCloud+OAuth+JWT+ Alibaba+Mybatis+MySQL+MQ+Redis+阿里云OSS文件存储服务 这个技术栈。其中主要针对MQ、OSS、SpringCloud中会进行一些框架选型，下面就一一展开详细对比相关框架之间的优缺点，一遍更好的选出合适项目的框架。

一、消息队列（MQ）的选择

消息中间件目前主要有四种：ActiveMQ、RabbitMQ、RocketMQ、Kafka。我们也将从这四种MQ中选出一种，作为SaaS平台的消息通信框架。

1、ActiveMQ消息中间件

ActiveMQ消息中间件采用的是消息推送方式进行消息消费的，适合用在消息量少，并且能够在短时键内消费的场景。所以ActiveMQ在海量数据高并发中使用较少，一般还是用在简单的通信和解耦程序。

优点：

• 使用简单方便，容易上手
• 可控性比较好，监控机制和界面比较好

缺点：

• 吞吐量(TPS)低 由于ActiveMQ需要建立索引，所以势必会导致吞吐量下降。这个缺点是没有办法客服，只要使用JMS规范的中间件，就会存在这个问题

• 无分片功能 如果用到分片机制，需要自己去实现。于到大量消息需要处理只能通过增加服务器来横向拆分。

• 在国内使用较少，其处理数据的能里缺少实战验证

2、RabbitMQ消息中间件

优点：

• 支持集群化、高可用部署

• 安装部署简单，上手简单，功能丰富，符合AMQP标准

• 高并发能力和消息处理能力经过了大量的实践考验

• 集群容易扩展，可以轻松的增减集群节点

• 强大的WEB管理页面

• 强大的社区支持

• 版本更新即时

• 支持消息持久化、支持消息确认机制、任务分发机制等

缺点：

• 如果消息达到10万级别，性能会下降。如果是处理数据量比较大，还是使用kafka

3、RocketMQ消息中间件

RocketMQ是阿里自研的一款低延迟、高可用、可伸缩、易于使用的消息中间件。它是基于发布订阅的队列模型，只有发布和订阅消息方式，消息类型只支持Message，消息可以持久化；中间件是使用Java进行开发的，而且是开源，所以可以方便阅读源码和对其进行修改和二次开发。

优点：

• 顺序性 它支持顺序性，可以做到局部有序，在单线程内使用该生产者发送的消息按照发送的顺序到达服务器并存储，并按照相同顺序被消费，但是前提是这些消息发往同一个服务器分区

• 实时性 采取长轮询+PULL消费消息，可以自己决定如何在响应性和吞吐量之间做平衡，配合合理的参数设置来获取更高的响应时间，实时性不低于PUSH方式

• 提供丰富的拉取模式

• 支持10亿级别的消息堆积，不会应为堆积导致性能下降

• 高效的订阅水平扩展机制

缺点：

• 消息重复消费问题，不能保证不重复，只能保证正常情况下不重复
• 不支持分布式事务
• 消息过滤功能扩展比较单一

4、Kafka消息中间件

Kafka是一个分布式发布-订阅消息系统，主要用在大数据中处理活跃的流式数据。

Kafka优点：

• 同时为发布和订阅提供高吞吐量 Kafka每秒可以产生约25万消息（50MB），每秒处理55万消息（110MB）
• 可进行持久化操作 将消息持久化到磁盘，因此可用于批量消息，例如ETL，以及实时应用程序。通过将数据持久化到硬盘以及replication防止数据丢失。
• 分布系统，易于向外扩展 所有的productor、broker和consumer都会有多个，均为分布式的。无需停机即可扩展机器。
• 消息被处理的状态式在consumer端维护，而不是由server端维护
• 支持online和offline的场景
• 对CPU和内存消耗较小
• 对网络开销相对较小
• 支持跨数据库中心的消息复制
• 支持镜像集群

Kafka缺点：

• 由于式批量发送，数据并非真正的实时
• 对于mqtt协议不支持
• 不支持物联网传感数据直接接入
• 仅支持统一分区消息有序，无法实现全局消息有序
• 依赖zookeeper进行元素据管理

5、总结选型

通过以上的比较发现：

ActiveMQ在国内使用经验比较少，在高迸发下缺少验证，用在项目中会存在一定的风险。所以不在考虑ActiveMQ；

Kafka在性能方面毋庸置疑，比较好，在国内也有公司在使用，社区活跃度高，更新及时。能够适合比较高的并发量，更适合于用在处理海量数据的项目中。因为目前要做的项目数据访问量并不高，而且Kafka也属于那种重量级的消息中间件，用在项目中会有种杀鸡用牛刀的感觉，浪费性能。最后综合考虑Kafka也不作为选择。

RocketMQ是国内阿里巴巴开发的，帮助文档以及学习资料都是中文版，这个对国人来说比较友好，社区活跃度也很高，而且RocketMQ现在作为天猫双十一的定海神针，经得住了50多万的TPS，性能可见多么强悍。但是话又说回来，RocketMQ也属于重量级消息中间件，现在要做的项目TPS也达不到50万，所以使用RocketMQ也不合适，最后不做为选择。

最后只有RabbitMQ了，RabbitMQ属于轻量级消息中间件，TPS在10万左右，而且也有比较丰富的功能，可以完全满足项目需求。社区也比较活跃，常见的问题在社区基本都可以找到。国内使用的公司也比较多，经过了实战检验。最后综合选择RabbitMQ。

二、SpringCloud中注册中心选型

注册中心我们主要从Zookeeper、Eureka、Nacos、consul这四个种选择。

注册中心是微服务架构中的最关键的基础组件之一，一个注册中心的架构一般有两部分组成，第一部分是服务的注册，第二部分是服务的发现。

1、Zookeeper

优点：

• 简单分布式协调过程 Zookeeper中所有节点之间的协调过程非常简单
• 同步 Zookeeper的工作高度同步，这意味着服务器进程之间存在互斥和合作。基本上此同步有助于Apache HBase进行配置管理
• 有序消息 Zookeeper跟踪一个数字，通过标识其顺序与每个更新的标记，通过所有消息在这里订阅
• 序列化 根据特定规则，Zookeeper会对数据进行编码
• 速度比较快
• 对扩展性 可以通过部署更多机器来加强性能
• 可靠性高
• 天然原子性

缺点：

• zookeeper不是为高可用设计的
• zookeeper的选举过程速度慢
• zookeeper的权限控制非常薄弱

2、Eureka

Eureka是Netflix开发的，基于REST服务的服务注册与发现组件。它主要包括两个组件：Eureka Server和Eureka Client

• Eureka Client：Java客户端，用于简化与Eureka Server的交互（通常就是服务中的客户端和服务端）
• Eureka Server：提供服务注册和发现的能力（通常就是微服务中的注册中心）

优点：

• 高可用 Eureka Server采用Peer to Peer对等通信，所以Eureka Server没有master/slave区分。节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的serviceUrl指向其他节点。每个节点都是可以被视为其他节点的副本。
• Eureka保证AP(可用性/分区容错性) 几个节点挂掉不会影响整个节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或是如果发现连接失败，则会自动切换到其他节点。
• Eureka自我保护机制 如果在15分钟内超过85%的接地点没有正常心跳，那么Eureka就认为客户端与注册中心出现了网络问题，此时：
  1. Eureka不再从注册列表中移除因为长时间没收到心跳而过期的服务
  2. Eureka任然可以接收到新服务的注册和查询请求，但不会被同步到其他节点上（保证当前节点依然可用）
  3. 当网络稳定时，当前实例新的注册信息会被同步到其他节点中
• 支持雪崩保护
• 容易上手

缺点：

• 不保证数据一致性 由于集群间的同步复制是通过HTTP的方式进行，基于网络的不可靠性，集群中的Eureka Server间的注册表信息难免存在不同步的时间节点，不满足CAP中的C（数据一致性）
• 版本升级停止
• 管理界面为英文界面，不符合国人
• 2.0版本后将闭源
• 不支持事件通知

3、Nacos

Nacos是阿里巴巴退出来的一个新的开源项目，这是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。Nacos支持几乎所有主流类型的“服务”的发现、配置、管理。

优点：

• 不依赖其他组件
• 属于外部应用，侵入性小
• 通知遵循CP原则（一致性+分离容忍）和AP原则（可用性+分离容忍）
• 支持HTTP/动态DNS/UDP协议
• 管理界面为中文，符合国人习惯
• 上手容易，中文文档较多，社区活跃

4、Consul

Consul 内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，不再需要依赖其他工具（比如 ZooKeeper 等），使用起来也较为简单。

Consul 遵循CAP原理中的CP原则，保证了强一致性和分区容错性，且使用的是Raft算法，比zookeeper使用的Paxos算法更加简单。虽然保证了强一致性，但是可用性就相应下降了，例如服务注册的时间会稍长一些，因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功 ；在leader挂掉了之后，重新选举出leader之前会导致Consul 服务不可用。

优点：

• 服务不依赖于其他组件
• 属于外部应用，对代码侵入性较小
• 支持SpringCloud K8S集成
• 采用HTTP/DNS访问协议

缺点:

• 虽然遵循CP原则（一致性+分离容忍）但是服务注册稍慢，由于一致性导致了在Leader挂掉时重新选举期间整个Consul不可用
• 不支持雪崩保护
• 英文界面，不符合国人习惯
• 上手比较复杂，耗时费力

综上所述，在能够实现注册中心的基本功能下，选择低侵入性的Nacos。一方面他是国产的，在开发文档方面比较符合国人习惯，入手更加快。其次Nacos在国内使用的比较多，好多大厂都在使用，其性能经过了实战验证，比较有保障。所以综合下来选择使用Nacos作为Saas平台的服务注册中心。最后整个项目的技术栈为Java+VUE+elementUI+Negix+Springboot+SpringCloud+SpringCloud+Nacos+OAuth+JWT+ Alibaba+Mybatis+MySQL+RedisMQ+Redis+阿里云OSS文件存储服务