关于微服务:如何进行微服务的技术选型

52次阅读

共计 3879 个字符,预计需要花费 10 分钟才能阅读完成。

本文首发自「慕课网」,想理解更多 IT 干货内容,程序员圈内热闻,欢送关注 ” 慕课网 ”!

作者:陈于吉吉 | 慕课网讲师


随着这几年微服务的火爆,在平时的工作或者技术交换中,咱们总能听到哪家公司说把本人的我的项目用微服务重构啦,是的,微服务的确能解决单体零碎变得臃肿难以维系的问题。当初如果你的企业正在思考采纳微服务对架构进行重构,那么企业必然须要抉择一个框架将微服务进行落地。

咱们都晓得,当初在微服务市场比拟风行的有 2 大框架,一个是 Ali 的 Dubbo,一个是 SpringCloud。两者孰优孰劣始终是一个比拟令人头疼的问题。接下来咱们一起探讨下如何进行微服务的技术选型。

1. 技术选型思考的因素
其实咱们能够先不去思考是采纳 Dubbo 还是 SpringCloud,而是回到技术选型自身,先看下技术选型可能存在的指标,而后依据这些指标来思考到底是抉择那个微服务框架。

能够看到,技术选型须要评估的指标还是十分多的,也是要个很须要教训的决策。要进行大量的调研和输出,依据现有的业务状况作出一个合乎本身状况的决策。

咱们在做技术选型的时候最禁忌的是长期抱佛脚,在网上随便搜寻几个比照文章利用这些碎片化信息来做出决策。肯定要确保咱们的选型是基于以后业务增长的判断,还要弄清楚业务事实背地的假如。

即便这样,也未必能选出一个最优的计划,然而通过这一系列的评判规范相对能够挑选出满足当下业务的技术栈。

2. Dubbo 还是 SprigCloud
2.1 Dubbo

Dubbo,阿里巴巴公司开源的一个高性能优良的服务框架,以后 Dubbo 撑持的阿里分布式应用内撑持万级别的利用数,运行在 20 多万的服务器实例上,每天调用量万亿级别,是国内最高的分布式应用集群。目前 Dubbo 曾经被阿里赠予 apache 基金会成为顶级我的项目。

Dubbo 其实也经验过一段崎岖,两头呈现一大段无人保护的阶段,可能是让路于阿里云免费我的项目 HSF。不过目前曾经在 apache 顶级我的项目下从新保护,目前最新版本是 3.0。

2.2 SpringCloud

SpringCloud 是 Spring Source 的产物,Spring 社区的弱小背书能够说是 Java 业务界无人能匹敌的组织,SpringBoot 和 SpringCloud 更是无缝的严密相连,SpringCloud 倒退得初期,Netfix 为其提供了弱小的技术输入,在一开始的阶段 Netfix 开关套件基本上是 SpringCloud 的外围。不过随着 Netfix 的局部组件不更新,SpringCloud 曾经在各个方面提供了代替甚至更强的计划。

如果只是拿两者的背景做比拟,前者在国内影响力更大,后者在国外和国内新兴企业中影响力更大。但因为背靠 Spring Source 弱小的靠山,在背景上,应该是 SpringCloud 稍逊一筹。不过不应该作为选型框架次要根据。

2.3 社区活跃度

有人在 2017 年,Dubbo 还未退出 apache 顶级我的项目时,有人在做了两个框架在 github 上的活跃度比照,能够看出 SpringCloud 是以小时为沉闷维度,而 Dubbo 基本上以年为维度。

但在明天,Dubbo 在退出 apache 顶级我的项目后,在 github 从新比照,能够看出差距正在放大

当然真正的沉闷不是这么简略就做出评判,不过粗略的察看还是能够得出结论,Dubbo 在社区特地是中国区,沉闷曾经在复原。当官网没有保护之后,还是有一些公司对 Dubbo 做了进一步的开发和保护,例如当当基于 Dubbo 研发的分布式框架 Dubbox。

2.4 两者的性能

Dubbo 和 SpringCloud
其实只是解决方案的框架,集中性能的差别次要体现在服务调用和传输协定上,Dubbo 应用的是 RPC 通信协定,提供了 Dubbo
的序列化,Dubbo 缺省协定采纳繁多长链接和 NIO 异步通信(放弃连贯、轮训解决),应用自定义的报文,适宜小数量大并发的服务调用场景,而 SpringCloud 缺省采纳的是 HTTP 协定的 REST API。
网上有人特意做了个模仿测试两者的性能,应用一个 Pojo 对象蕴含 10 个属性,申请 10 万次,Dubbo 和 SpringCloud 在不同线程数量下,每次申请耗时(ms)

以上图片和测试后果均采自网上

不出意外,采纳 HTTP 的 SpringCloud 的确比不过采纳 RPC 的 Dubbo。但由此产生了:Http + Json 的 Rest 通信,性能上难堪重用,其实也是一种误读。

评估性能更大的水平是判断 Http 协定的通信对于利用的负载是否会成为真正的瓶颈点。

在大部分的公司网络下,网络耗费并不能算上什么太大的问题。如果真的有题,SpringCloud 也并不是 Http + Json 强制绑定,也能够选用 Thrift,Protobuf 等高性能 RPC,序列化作为代替计划。

2.5 架构完整性

上述的几点在这次选型中,最多是参考点之一,真正决定抉择的是架构的完整性,他决定了是否满足咱们的需要。
其实把 SpringCloud 和 Dubbo 进行在架构完整性比照有点不太偏心,Dubbo 只是实现了服务治理,而 SpringCloud 到目前为止在 github 上曾经有三十多个我的项目,曾经笼罩了微服务架构下的方方面面。在肯定得水平来说,Dubbo 是指 SpringCloud 的一个子集,但在抉择框架的问题上,计划残缺度却恰好是一个最须要咱们重点关注。

在下面章节中,说到了,微服务尽管带来了模块清晰划分,独立部署,技术多样式的益处,然而因为分布式,也带来了十分多的复杂度,这些复杂度,是须要进行治理和必要的组件进行撑持。

以上列举进去一些罕用的外围组件,从表格不难发现为何说 Dubbo 只是 SpringCloud 的一个子集,不过有一点必须申明,Dubbo 外面比照项中的”无“并不是代表不能实现,只是默认
Dubbo 框架本身没有提供,而咱们在市面上还是能够找到很多与之相匹配的开源组件。
例如:

  • 服务网关:能够采纳 Nginx+lua 作为根底网关,能够起到鉴权,路由等简略网关的规定;
  • 断路器:能够采纳 ali 的 Sentinel,Sentinel 比 Hystrix 性能还要弱小,并有控制台;
  • 分布式配置:能够采纳百度的 Disconf 或者携程的 Apollo 作为分布式配置管理,对比起,SpringCloud 的
  • Config,Config 是存储和配置在 git 上,应用默认配置不够直观,而 Disconf 和 Apollo
  • 都提供了优良的控制台,有灰度公布,权限隔离性能更加弱小;
  • 链路跟踪:能够应用 SkyWalking,目前 SkyWalking 也曾经纳入 apache 的顶级我的项目,这 2 年倒退迅速,相比 Zipkin,Cat 更加弱小,更不用说 Sleuth;
  • 音讯总线:能够应用 RabbitMq,采纳 AMQP 协定的 RabbitMq 也能够实现音讯代理将分布式系统节点串联,达到播送状态;
  • 批量工作:能够应用 xxl-job。

你能够认为 Dubbo 是组装电脑,SpringCloud 是品牌电脑。上面给出咱们组装完的 Dubbo 和 SpringCloud 的比照,其中抉择组装的组件大部分来自国产:

Dubbo 在各个环节咱们的抉择自由度很高,也能够说,只能内部去选装。但毕竟是内部的选装,例如咱们为一台组装电脑抉择了一条内存或一块硬盘存在问题导致整台电脑都奔溃。如果你是 DIY 的高手,这些都不是问题,但如果你是一名小白,或对各个组件不是太相熟,那可能品牌机会更适宜你。

SpringCloud 像品牌机,在 Spring Source 的整合下,做了大量的兼容性测试,保障了机器领有较高的稳定性,但 SpringCloud 的默认组件中也有一些不太好用的组件。

除了以上咱们讲的组件的区别,还有一些小的细节,例如笔者在早年应用 Dubbo 为了实现隐式传参,就对 Dubbo 的源码进行了改变,(因为早点 dubbo 进行了保护,所以进行了部分二次开发),在应用 SpringCloud,发现间接实现 RequestInterceptor 就能够实现,可能 SpingCloud 是后发,所以在一些细节上更加考虑周到,更适宜小白的应用。

2.6 学习,招聘老本
应该说,学习老本是 SpringCloud 相比拟 Dubbo 是更低的,各种组件根本都是开箱即用,并且依靠于 SpringSource 大树,兼容性和可靠性是有保障的,置信写 Java 代码的人无人不熟 Spring。在编码上,依靠 SpringBoot,各种组件配置即可应用,很大的升高的学习和入门老本。

3. 总结

对于 Dubbo 和 SpringCloud 的相干概念和比照,下面曾经叙述分明了,至于选型是 抉择 Dubbo 还是 SpringCloud,这里得依据本身的状况需要登程,这里不做举荐抉择。

笔者之前用的始终都是 Dubbo,但前面去了一家新公司新的团队,抉择了是 ali 版本的 SpringCloud,思考的起因是:新团队这方面相干教训还是比拟欠缺,SpringCloud 提供了残缺的组件反对,SpringCloud 不失为比拟稳当的抉择。

作为后起之秀,SpringCloud 应用简略不便,并且 SpringCloud 也有弱小的社区反对,文档方面也是十分欠缺,新团队没有必要在此投入过多的工夫去浏览扩散的文档和钻研各种开源组件,能够分出精力和工夫在业务上。

而且公司还存在其余技术栈的团队,存在接口互调的需要。Dubbo 默认应用的 RPC 并不能很好的实现跨语言,而 SpringCloud 默认 Http REST 自身就是反对跨语言实现。


欢送关注「慕课网」帐号,咱们会始终保持提供 IT 圈优质内容,分享干货常识,大家一起独特成长吧!

本文原创公布于慕课网,转载请注明出处,谢谢合作

正文完
 0