欢迎关注公众号 《小姐姐味道》 ,一起进步!

# 架构师的初级技能,选组件!(2020更新版,非广告)

原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处。

2020年新版,对部分组件的描述进行了更新。19年文章参见 这里 (opens new window) 。如果你在做选型方面的工作,或者想了解一些现在正在流行的技术,那么这篇文章正好适合你。有什么疑问,可以加我好友 (微信号:xjjdog0),进群讨论。

本篇内容涵盖14个方面,涉及上百个框架和工具。会有你喜欢的,大概也会有你所讨厌的家伙。这是我平常工作中打交道最多的工具,大小公司都适用。如果你有更好的,欢迎留言补充。

一、消息队列
二、缓存
三、分库分表
四、数据同步
五、通讯
六、微服务
七、分布式工具
八、监控系统
九、调度
十、入口工具
十一、OLT(A)P
十二、CI/CD
十三、问题排查
十四、本地工具

# 一、消息队列

  • √ 推荐:(1) 吞吐量优先选择kafka
  • (2) 稳定性优先选择RocketMQ
  • (3) 物联网:VerneMQ

一个大型的分布式系统,通常都会异步化,走消息总线。 消息队列作为最主要的基础组件,在整个体系架构中,有着及其重要的作用。异步通常意味着编程模型的改变,时效性会降低。

kafka是目前最常用的消息队列,尤其是在大数据方面,有着极高的吞吐量。而rocketmqrabbitmq,都是电信级别的消息队列,在业务上用的比较多。相比较而言,ActiveMQ使用的最少,属于较老一代的消息框架。

pulsar是为了解决一些kafka上的问题而诞生的消息系统,比较年轻,工具链有限。有些激进的团队经过试用,反响不错,但实际使用并不多。

mqtt具体来说是一种协议,主要用在物联网方面,能够双向通信,属于消息队列范畴,推荐使用vernemq

相关文章:
「整体」分布式消息系统,设计要点。画龙画虎难画骨 (opens new window)
「Kafka」Kafka基础知识索引 (opens new window)
「Kafka」 360度测试:KAFKA会丢数据么?其高可用是否满足需求? (opens new window)
「Kafka」 使用多线程增加kafka消费能力 (opens new window)
「AMQ」ActiveMQ架构设计与最佳实践,需要一万字 (opens new window)
「MQ」开源一个kafka增强:okmq-1.0.0 (opens new window)

# 二、缓存

  • √ 推荐:(1) 堆内缓存使用默认的caffeine
  • (2) 分布式缓存采用redis的cluster集群模式,但要注意使用限制

数据缓存是减少数据库压力的有效途径,有单机java内缓存,和分布式缓存之分。

对于单机来说,guavaLoadingCacheehcache都是些熟面孔,不过SpringBoot选择了caffeine作为它的默认堆内缓存,这是因为caffeine的速度比较快的原因。

对于分布式缓存来说,优先选择的就是redis,别犹豫。由于redis是单线程的(6.0支持多线程,但默认不开启),并不适合高耗时操作。所以对于一些数据量比较大的缓存,比如图片、视频等,使用老牌的memcached效果会好的多。

JetCache是一个基于Java的缓存系统封装,提供统一的api和注解来简化缓存的使用。类似SpringCache,支持本地缓存和分布式缓存,也是简化开发的利器。

相关文章:
「Redis」这可能是最中肯的Redis规范了 (opens new window)
「Redis」与亲生的Redis Cluster,来一次亲密接触 (opens new window)
「Redis」redis的zset有多牛?请把耳朵递过来 (opens new window)
「Redis」好慌,Redis这么多集群方案,要用哪种? (opens new window)
「协议」架构秘笈:移花接木。使用mysql模拟redis (opens new window)
「Redis」Redis都要老了,你还在用什么古董客户端? (opens new window)
「堆内」新一代缓存Caffeine,速度确实比Guava的Cache快 (opens new window)

# 三、分库分表

  • √ 推荐:shardingsphere中的sharding-jdbc

fkfb 分库分表,几乎每一个上点规模的公司,都会有自己的方案。目前,推荐使用驱动层的sharding-jdbc(已经进入apache),或者代理层的mycat。如果你没有额外的运维团队,又不想花钱买其他机器,那么就选前者。

如果分库分表涉及的项目不多,spring的动态数据源是一个非常好的选择。它直接编码在代码里,直观但不易扩展。

如果只需要读写分离 ,那么mysql官方驱动里的replication协议,是更加轻量级的选择。

上面的分库分表组件,都是大浪淘沙,最终的优胜品。这些组件不同于其他组件选型,方案一旦确定,几乎无法回退,所以要慎之又慎。

分库分表是小case,准备分库分表的阶段,才是重点:也就是数据同步。

相关文章:
「分库分表」“分库分表” ?选型和流程要慎重,否则会失控 (opens new window)
「数据同步」希望一个数据同步,包治百病 (opens new window)
「分库分表」分库分表“实践”大全 (opens new window)
「HA」”MySQL官方驱动“主从分离的神秘面纱 (opens new window)
「Sharding」 现实中的路由规则,可能比你想象中复杂的多 (opens new window)
「Sharding」 非规范SQL的sharding-jdbc实践 (opens new window)

# 四、数据同步

  • √ 推荐:canal

sjtb 国内使用mysql的公司居多,但postgresql凭借其优异的性能,使用率逐渐攀升。

不管什么数据库,实时数据同步工具,都是把自己模拟成一个从库,进行数据拉取和解析。 具体来说,mysql是通过binlog进行同步;postgresql使用wal日志进行同步。

对mysql来说,canal是国内用的最多的方案;类似的databus也是比较好用的工具。

现在,canal、maxwell等工具,都支持将要同步的数据写入到mq中,进行后续处理,方便了很多。

对于ETL(抽取、清洗、转换)来说,基本上都是source、task、sink路线,与前面的功能对应。gobblin、datax、logstash、sqoop等,都是这样的工具。

它们的主要工作,就是怎么方便的定义配置文件,编写各种各样的数据源适配接口等。这些ETL工具,也可以作为数据同步(尤其是全量同步)的工具,通常是根据ID,或者最后更新时间 等,进行处理。

binlog是实时增量工具,ETL工具做辅助。通常一个数据同步功能,需要多个组件的参与,他们共同组成一个整体。

相关文章:
「云库」MySQL痿了,放不下这么多数据! (opens new window)
「数据同步」由 Canal 组件分析集成中间件架构的一般过程 (opens new window)
「云库」记一次操蛋的方案降级(云上冷热分离的坎坷之路) (opens new window)

# 五、通讯

  • √ 推荐:http+json,方便调试。高性能要求可选二进制协议

tongxun Java 中,netty已经成为当之无愧的网络开发框架,包括其上的socketio(不要再和我提mina了)。对于http协议,有common-httpclient,以及更加轻量级的工具okhttp来支持。

对于一个rpc来说,要约定一个通讯方式和序列化方式。json是最常用的序列化方式,但是传输和解析成本大,xml等文本协议与其类似,都有很多冗余的信息;avrokryo是二进制的序列化工具,没有这些缺点,但调试不便。

rpc是远程过程调用的意思 ,其中,thriftdubbogRPC默认都是二进制序列化方式的socket通讯框架;feignhessian都是onhttp的远程调用框架。

对了,gRPC的序列化工具是protobuf,一个压缩比很高的二进制序列化工具。

通常,服务的响应时间主要耗费在业务逻辑以及数据库上,通讯层耗时在其中的占比很小。可以根据自己公司的研发水平和业务规模来选择。

相关文章:
「网络开发」使用Netty,我们到底在开发些什么? (opens new window)
「WS」WebSocket协议 8 问 (opens new window)

# 六、微服务

  • √ 推荐:(1) 注册中心:consul
  • (2)网关:nginx+Gateway
  • (3)配置中心:Apollo
  • (4)调用链:Skywalking
  • (5)熔断: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 大力支持,基于 Spring5.0 的新特性 WebFlux 进行开发。底层网络通信框架采用的是 Netty,吞吐量高。

相关文档:
「整体」这次要是讲不明白Spring Cloud核心组件,那我就白编这故事了 (opens new window)
「整体」微服务不是全部,只是特定领域的子集 (opens new window)
「SCG」万字Spring Cloud Gateway2.0,面向未来的技术,了解一下? (opens new window)
「Trace」2w字长文,让你瞬间拥有「调用链」开发经验 (opens new window)
「熔断」轻拢慢捻,微服务熔断大总管 (opens new window)

# 七、分布式工具

fbsgj 大家都知道分布式系统zookeeper能用在很多场景,与其类似的还有基于raft协议的etcd和consul。

由于它们能够保证极高的一致性,所以用作协调工具是再好不过了。用途集中在:配置中心、分布式锁、命名服务、分布式协调、master选举等场所。

对于分布式事务方面,则有阿里的fescar工具进行支持。但如非特别的必要,还是使用柔性事务,追寻最终一致性,比较好。

# 八、监控系统

  • √ 推荐:prometheus + grafana + telegraf
  • 日志收集:大量ELKB,小量loki

监控系统组件种类繁多,目前,最流行的大概就是上面四类。

zabbix在主机数量不多的情况下,是非常好的选择。

prometheus来势凶猛,大有一统天下的架势。它也可以使用更加漂亮的grafana进行前端展示。

influxdata的influxdb和telegraf组件,都比较好用,主要是功能很全。

使用es存储的elkb工具链,也是一个较好的选择。我所知道的很多公司,都在用。

相关文档:

「整体」这么多监控组件,总有一款适合你 (opens new window)
「日志」elkb实践经验,再赠送一套复杂的配置文件 (opens new window)
「日志」日志收集的“DNA” (opens new window)
「日志」实践一把Loki,体验掌上起舞的轻盈 (opens new window)
「日志」你的野花,朕的kibana (opens new window)
「日志」一般人不敢动系列之—基于logback的日志“规范”和“脱敏” (opens new window)
「监控」 昔日教人类用火的prometheus,如今在努力报警 (opens new window)
「APM」 2w字长文,让你瞬间拥有「调用链」开发经验 (opens new window)
「APM」 这一轮,skywalking胜出 (opens new window)
「底层」 冷门instrument包,功能d炸天 (opens new window)
「底层」你的也是我的。3例ko多线程,局部变量透传 (opens new window)

# 九、调度

  • √ 推荐:xxl-job

diaodu 大家可能都用过cron表达式。这个表达式,最初就是来自linux的crontab工具。

quartz是java中比较古老的调度方案,分布式调度采用数据库锁的方式,管理界面需要自行开发。

elastic-job-cloud应用比较广泛,但系统运维复杂,学习成本较高。相对来说,xxl-job就更加轻量级一些。中国人开发的系统,后台都比较漂亮。

# 十、入口工具

  • √ 推荐:lvs

rkgj

为了统一用户的访问路口,一般会使用一些入口工具进行支持。

其中,haproxy、lvs、keepalived等,使用非常广泛。

服务器一般采用稳定性较好的centos,并配备ansible工具进行支持,那叫一个爽。

# 十一、OLT(A)P

  • √ 推荐:ES

oltp 现在的企业,数据量都非常大,数据仓库是必须的。

搜索方面,solr和elasticsearch比较流行,它们都是基于lucene的。solr比较成熟,稳定性更好一些,但实时搜索方面不如es。

列式存储方面,基于Hadoop 的hbase,使用最是广泛;基于LSM的leveldb写入性能优越,但目前主要是作为嵌入式引擎使用多一些。

tidb是国产新贵,兼容mysql协议,公司通过培训向外输出dba,未来可期。

时序数据库方面,opentsdb用在超大型监控系统多一些。druid和kudu,在处理多维度数据实时聚合方面,更胜一筹。

cassandra在刚出现时火了一段时间,虽然有facebook弃用的新闻,但生态已经形成,常年霸占数据库引擎前15名。

# 十二、CI/CD

15995402632193

为了支持持续集成和虚拟化,除了耳熟能详的docker,我们还有其他工具。

jenkins是打包发布的首选,毕竟这么多年了,一直是老大哥。当然,写Idea的那家公司,还出了一个叫TeamCity的工具,操作界面非常流畅。

solor不得不说是一个神器,用了它之后,小伙伴们的代码一片飘红,我都快被吐沫星子给淹没了。

对于公司内部来说,一般使用gitlab搭建git服务器。其实,它里面的gitlab CI,也是非常好用的。

Harbor,在 docker registry基础上扩展了权限控制,审计,镜像同步,管理界面等治理 能力,推荐使用。

调度方面,k8sGoogle 开源,社区的强力推动,有大量的落地方案。Rancher对k8s进行了功能的拓展,实现了和k8s集群交互的一些便捷工具,包括执行命令行,管理多个 k8s集群,查看k8s集群节点的运行状态等,推荐集成。

相关文章:
「持续集成」发布系统有那么难么? (opens new window)
「流程」技术评审,你拿什么来吐槽? (opens new window)
「流程」研发里那只看不见的手,勒的很疼 (opens new window)
「规范」外来规范水土不服?手把手教你怎么扩展阿里规范idea插件 (opens new window)
「工具」有了MinIO,你还会用FastDFS么? (opens new window)

# 十三、问题排查

wtp java经常发生内存溢出问题。使用jmap导出堆栈后,我一般使用mat进行深入分析。

如果在线上实时分析,有arthas和perf两款工具。

当然,有大批量的linux工具进行支持。

相关文章:
《Linux上,最常用的一批命令解析(10年精选)》 (opens new window)
最常用的一套“Vim“技巧 (opens new window)
最常用的一套“Sed“技巧 (opens new window)
最常用的一套“AWK“技巧 (opens new window)

# 十四、本地工具

bdgj 本地使用的jar包和工具,那就多了去了。下面仅仅提一下最最常用的几个。

数据库连接池方面,国内使用druid最多。目前,有号称速度最快的hikari数据库连接池,以及老掉牙的dbcp和c3p0。

json方面,国内使用fastjson最多,三天两头冒出个漏洞;国外则使用jackson多一些。它们的api都类似,jackson特性多一些,但fastjson更加容易使用。

工具包方面,虽然有各种commons包,guava首选。

# End

今天是2020年9月08日。

这种文章,每一年我都会整理一次。有些新面孔,也有些被我个人t出局。架构选型,除了你本身对某项技术比较熟悉,用起来更放心。更多的是需要进行大量调研、对比,直到掌握。

技术日新月异,新瓶装旧酒,名词一箩筐,程序员很辛苦。唯有那背后的基础原理,大道至简的思想,经久不衰。

作者简介:小姐姐味道 (xjjdog),一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构,日百亿流量,与你探讨高并发世界,给你不一样的味道。我的个人微信xjjdog0,欢迎添加好友,​进一步交流。​


关注回复 技术 关键字 ,即可 获取 海量资源

鲁ICP备2020043359号-1