如果你在做选型方面的工作，或者想了解一些现在正在流行的技术，那么这篇文章正好适合你。
图片来自 Pexels
本篇内容涵盖 14 个方面，涉及上百个框架和工具。会有你喜欢的，大概也会有你所讨厌的家伙。
这是我平常工作中打交道最多的工具，大小公司都适用。如果你有更好的，欢迎留言补充：
- 消息队列
- 缓存
- 分库分表
- 数据同步
- 通讯
- 微服务
- 分布式工具
- 监控系统
- 调度
- 入口工具
- OLT(A)P
- CI/CD
- 问题排查
- 本地工具
消息队列
推荐：
- 吞吐量优先选择 Kafka。
- 稳定性优先选择 RocketMQ。
- 物联网：VerneMQ。
一个大型的分布式系统，通常都会异步化，走消息总线。 消息队列作为最主要的基础组件，在整个体系架构中，有着及其重要的作用。异步通常意味着编程模型的改变，时效性会降低。
Kafka 是目前最常用的消息队列，尤其是在大数据方面，有着极高的吞吐量。而 RocketMQ和 RabbitMQ，都是电信级别的消息队列，在业务上用的比较多。
相比较而言，ActiveMQ 使用的最少，属于较老一代的消息框架。Pulsar 是为了解决一些 Kafka 上的问题而诞生的消息系统，比较年轻，工具链有限。有些激进的团队经过试用，反响不错，但实际使用并不多。
MQTT 具体来说是一种协议，主要用在物联网方面，能够双向通信，属于消息队列范畴，推荐使用 VerneMQ。
缓存
推荐：
- 堆内缓存使用默认的 Caffeine。
- 分布式缓存采用 Redis 的 Cluster 集群模式，但要注意使用限制。
数据缓存是减少数据库压力的有效途径，有单机 Java 内缓存，和分布式缓存之分。
对于单机来说，Guava 的 LoadingCache 和 ehcache 都是些熟面孔，不过 SpringBoot 选择了 Caffeine 作为它的默认堆内缓存，这是因为 Caffeine 的速度比较快的原因。
对于分布式缓存来说，优先选择的就是 Redis，别犹豫。由于 Redis 是单线程的(6.0 支持多线程，但默认不开启)，并不适合高耗时操作。
所以对于一些数据量比较大的缓存，比如图片、视频等，使用老牌的 Memcached 效果会好的多。
JetCache 是一个基于 Java 的缓存系统封装，提供统一的 API 和注解来简化缓存的使用。类似 SpringCache，支持本地缓存和分布式缓存，也是简化开发的利器。
分库分表
推荐：ShardingSphere 中的 Sharding-JDBC。
分库分表，几乎每一个上点规模的公司，都会有自己的方案。目前，推荐使用驱动层的 Sharding-JDBC(已经进入 Apache)，或者代理层的 Mycat。如果你没有额外的运维团队，又不想花钱买其他机器，那么就选前者。
如果分库分表涉及的项目不多，Spring 的动态数据源是一个非常好的选择。它直接编码在代码里，直观但不易扩展。
如果只需要读写分离 ，那么 MySQL 官方驱动里的 Replication 协议，是更加轻量级的选择。
上面的分库分表组件，都是大浪淘沙，最终的优胜品。这些组件不同于其他组件选型，方案一旦确定，几乎无法回退，所以要慎之又慎。
分库分表是小 Case，准备分库分表的阶段，才是重点：也就是数据同步。
数据同步
推荐：Canal。
国内使用 MySQL 的公司居多，但 PostgreSQL 凭借其优异的性能，使用率逐渐攀升。
不管什么数据库，实时数据同步工具，都是把自己模拟成一个从库，进行数据拉取和解析。
具体来说，MySQL 是通过 Binlog 进行同步;PostgreSQL 使用 Wal 日志进行同步。
对 MySQL 来说，Canal 是国内用的最多的方案;类似的 Databus 也是比较好用的工具。
现在，Canal、Maxwell 等工具，都支持将要同步的数据写入到 MQ 中，进行后续处理，方便了很多。
对于 ETL(抽取、清洗、转换)来说，基本上都是 Source、Task、Sink 路线，与前面的功能对应。Gobblin、Datax、Logstash、Sqoop 等，都是这样的工具。
它们的主要工作，就是怎么方便的定义配置文件，编写各种各样的数据源适配接口等。
这些 ETL 工具，也可以作为数据同步(尤其是全量同步)的工具，通常是根据 ID，或者最后更新时间 等，进行处理。
Binlog 是实时增量工具，ETL 工具做辅助。通常一个数据同步功能，需要多个组件的参与，他们共同组成一个整体。
通讯
推荐：HTTP+Json，方便调试。高性能要求可选二进制协议。
Java 中，Netty 已经成为当之无愧的网络开发框架，包括其上的 socketio(不要再和我提 mina 了)。
对于 HTTP 协议，有 common-httpclient，以及更加轻量级的工具 Okhttp 来支持。
对于一个 RPC 来说，要约定一个通讯方式和序列化方式。Json 是最常用的序列化方式，但是传输和解析成本大，XML 等文本协议与其类似，都有很多冗余的信息;Avro 和 Kryo 是二进制的序列化工具，没有这些缺点，但调试不便。
RPC 是远程过程调用的意思 ，其中，Thrift、Dubbo、gRPC 默认都是二进制序列化方式的 Socket 通讯框架;Feign、Hessian 都是 Onhttp 的远程调用框架。
对了，gRPC 的序列化工具是 Protobuf，一个压缩比很高的二进制序列化工具。
通常，服务的响应时间主要耗费在业务逻辑以及数据库上，通讯层耗时在其中的占比很小。可以根据自己公司的研发水平和业务规模来选择。
微服务
推荐：
- 注册中心：Consul。
- 网关：Nginx+Gateway。
- 配置中心：Apollo。
- 调用链：Skywalking。
- 熔断：Resilience4j。
我们不止一次说到微服务，这一次我们从围绕它的一堆支持框架，来窥探一下这个体系。是的，这里依然是在说 Spring Cloud。
默认的注册中心 Eureka 不再维护，Consul 已经成为首选，它使用 Raft 协议开发开箱即用。Nacos、Zookeeper 等，都可以作为备选方案。其中 Nacos 带有后台，比较适合国人使用习惯。
熔断组件，官方的 Hystrix 也已经不维护了。推荐使用 Resilience4j，最近阿里的 Sentinel 也表现强劲。
对于调用链来说，由于 OpenTracing 的兴起，有了很多新的面孔。推荐使用 Jaeger 或者 Skywalking。Spring Cloud 集成的 Sleuth+Zipkin 功能稍弱，甚至不如传统侵入式的 Cat。
配置中心是管理多环境配置文件的利器，尤其在你不想重启服务器的情况下进行配置更新。
目前，开源中做的最好的要数 Apollo，并提供了对 Spring Boot 的支持。
Disconf 使用也较为广泛。相对来说，Spring Cloud Config 功能就局限了些，用的很少。
网关方面，使用最多的就是 Nginx，在 Nginx 之上，有基于 Lua 脚本的 Openrestry。由于 Openresty 的使用非常繁杂，所以有了 Kong 这种封装级别更高的网关。
对于 Spring Cloud 来说，Zuul 系列推荐使用 Zuul2，Zuul1 是多线程阻塞的，有硬伤。
Spring-Cloud-Gateway 是 Spring Cloud 亲生的，Spring Cloud 大力支持，基于 Spring 5.0 的新特性 WebFlux 进行开发。底层网络通信框架采用的是 Netty，吞吐量高。
分布式工具
大家都知道分布式系统 Zookeeper 能用在很多场景，与其类似的还有基于 Raft 协议的 etcd 和 Consul。
由于它们能够保证极高的一致性，所以用作协调工具是再好不过了。用途集中在：配置中心、分布式锁、命名服务、分布式协调、Master 选举等场所。
对于分布式事务方面，则有阿里的 Fescar 工具进行支持。但如非特别的必要，还是使用柔性事务，追寻最终一致性，比较好。
监控系统
推荐：
- Prometheus+Grafana+Telegraf。
- 日志收集：大量 ELKB，小量 Loki。
监控系统组件种类繁多，目前，最流行的大概就是上面四类。Zabbix 在主机数量不多的情况下，是非常好的选择。
Prometheus 来势凶猛，大有一统天下的架势。它也可以使用更加漂亮的 Grafana 进行前端展示。
Influxdata 的 Influxdb 和 Telegraf 组件，都比较好用，主要是功能很全。使用 ES 存储的 ELKB 工具链，也是一个较好的选择。我所知道的很多公司，都在用。
调度
推荐：XXL-Job。
大家可能都用过 Cron 表达式。这个表达式，最初就是来自 Linux 的 Crontab 工具。
Quartz 是 Java 中比较古老的调度方案，分布式调度采用数据库锁的方式，管理界面需要自行开发。
Elastic-Job-Cloud 应用比较广泛，但系统运维复杂，学习成本较高。相对来说，XXL-Job 就更加轻量级一些。中国人开发的系统，后台都比较漂亮。
入口工具
推荐：LVS。
为了统一用户的访问路口，一般会使用一些入口工具进行支持。其中，Haproxy、LVS、Keepalived 等，使用非常广泛。
服务器一般采用稳定性较好的 Centos，并配备 Ansible 工具进行支持，那叫一个爽。
OLT(A)P
推荐：ES。
现在的企业，数据量都非常大，数据仓库是必须的。搜索方面，Solr 和 Elasticsearch 比较流行，它们都是基于 Lucene 的。Solr 比较成熟，稳定性更好一些，但实时搜索方面不如 ES。
列式存储方面，基于 Hadoop 的 Hbase，使用最是广泛;基于 LSM 的 LevelDB 写入性能优越，但目前主要是作为嵌入式引擎使用多一些。
TiDB 是国产新贵，兼容 MySQL 协议，公司通过培训向外输出 DBA，未来可期。
时序数据库方面，OpentsDB 用在超大型监控系统多一些。Druid 和 Kudu，在处理多维度数据实时聚合方面，更胜一筹。
Cassandra在刚出现时火了一段时间，虽然有 Facebook 弃用的新闻，但生态已经形成，常年霸占数据库引擎前 15 名。
CI/CD
为了支持持续集成和虚拟化，除了耳熟能详的 Docker，我们还有其他工具。
Jenkins 是打包发布的首选，毕竟这么多年了，一直是老大哥。当然，写 Idea 的那家公司，还出了一个叫 TeamCity 的工具，操作界面非常流畅。
Solor 不得不说是一个神器，用了它之后，小伙伴们的代码一片飘红，我都快被吐沫星子给淹没了。
对于公司内部来说，一般使用 Gitlab 搭建 Git 服务器。其实，它里面的 Gitlab CI，也是非常好用的。
Harbor，在 Docker Registry 基础上扩展了权限控制，审计，镜像同步，管理界面等治理 能力，推荐使用。
调度方面，K8s，Google 开源，社区的强力推动，有大量的落地方案。
Rancher 对 K8s 进行了功能的拓展，实现了和 K8s 集群交互的一些便捷工具，包括执行命令行，管理多个 K8s 集群，查看 K8s 集群节点的运行状态等，推荐集成。
问题排查
Java 经常发生内存溢出问题。使用 Jmap 导出堆栈后，我一般使用 Mat 进行深入分析。
如果在线上实时分析，有 Arthas 和 Perf 两款工具。当然，有大批量的 Linux 工具进行支持。
本地工具
本地使用的 jar 包和工具，那就多了去了。下面仅仅提一下最最常用的几个。
数据库连接池方面，国内使用 Druid 最多。目前，有号称速度最快的 Hikari 数据库连接池，以及老掉牙的 dbcp 和 c3p0。
Json 方面，国内使用 Fastjson 最多，三天两头冒出个漏洞;国外则使用 Jackson 多一些。
它们的 API 都类似，Jackson 特性多一些，但 Fastjson 更加容易使用。工具包方面，虽然有各种 Commons 包，Guava 首选。
总结
架构选型，除了你本身对某项技术比较熟悉，用起来更放心。更多的是需要进行大量调研、对比，直到掌握。
技术日新月异，新瓶装旧酒，名词一箩筐，程序员很辛苦。唯有那背后的基础原理，大道至简的思想，经久不衰。
作者：小姐姐味道
简介：一个不允许程序员走弯路的公众号。聚焦基础架构和 Linux。十年架构，日百亿流量，与你探讨高并发世界，给你不一样的味道。
编辑：陶家龙
出处：转载自公众号小姐姐味道(ID：xjjdog)
