Spring Cloud Alibaba到底坑不坑？

以前我发过一篇《说说我为何看好Spring Cloud Alibaba》，而后这两天有网友给我转了这篇文章《坑爹项目spring-cloud-alibaba，咱们也来一个》，问个人见解是怎么样的，聊天时候简单说了一下。今天在家休息，抽空整理一下内容，逐点说一下个人见解，主要仍是以为这篇文章博眼球的成分高一些，由于这篇文章的解读与以前其余某些自媒体发布的《Eureka 2.0 开源工做宣告中止，继续使用风险自负》一文有殊途同归之“妙”，若是读者没有真正的理解Spring Cloud与Spring Cloud Alibaba，就颇有可能会对它们有什么误解，而后产生这样的想法：

• 感受颇有道理，这东西真垃圾
• 标题很燃，必须转发

下面具体来讲说该文章中，那些我认为不太正确的解读：

第一点：远程调用RPC

看看这篇文章的解读：

SpringCloud默认的是Feign和Ribbon，主要是提供了远程调用请求和解析，以及负载均衡的功能。客观点来讲，若是不用这两个组件，就会愈来愈四不像，干脆也别叫SpringCloud了，因此替换不得。
RPC会大量使用动态代理的功能，将你的字符串或者配置（由于网络传输方便）搞成动态的接口。

你也能够写一个RPC进行集成，有不少教程教你手撸一个。

爸爸版的集成了个dubbo，dubbo就是个RPC。因此你一用这玩意，其余的一些关键组件也得跟着全套的换，组件就不叫组件了!

做者认为Spring Cloud的负载均衡和远程调用必须使用Feign和Ribbon，这是Spring Cloud的默认实现。若是换成Dubbo，就是四不像了。

说说个人想法：

第一点：Dubbo在融入Spring Cloud的时候，真的就是四不像吗？若是真正看过Spring Cloud Alibaba以及理解Spring Cloud Common中的抽象的话，这个问题根本就不用去讨论。Spring Cloud Alibaba Dubbo在实现的时候是兼容Feign的编程模型的。有兴趣的读者能够看看小马哥在该项目中的案例：

Github地址：https://github.com/spring-cloud-incubator/spring-cloud-alibaba/tree/master/spring-cloud-alibaba-examples/spring-cloud-alibaba-dubbo-examples

第二点：Feign和Ribbon并非Spring Cloud的标准，它们也只是Netflix OSS中的组件。对于负载均衡，你们能够了解一下spring-cloud-loadbalancer，它如今是Spring Cloud Common的一部分，这才是真正的标准。对于Spring Cloud Alibaba在整合Dubbo的时候兼容Feign客户端，已是很是有用户意识了。

Github地址：https://github.com/spring-cloud-incubator/spring-cloud-loadbalancer

因此，做者到底有没有看过Spring Cloud Alibaba Dubbo的方案？

第二点：注册中心

看看这篇文章的解读：

服务注册中心是微服务的另一个必备组件，用来协调服务提供者和调用者的相互发现，SpringCloud默认的注册中心是Eureka。

爸爸版的用的是Nacos。Nacos的更新目前来看仍是比较活跃的，但真没有必要集成在一个Cloud中。Nacos最好的方式仍是独立发布，而后维护一个starter。开发者能够按照本身公司的环境进行有选择性的集成或替换。集成一个组件的成本是比较低的，远远低于删掉一堆自觉得是的功能。

SpringCloud还能够选择Zookeeper，或者Consul，甚至Etcd等，进行注册中心的搭建。目前，Eureka宣布再也不维护后，Consul应该是首要选择。

Consul自带Dashboard和ACL，可以看到大多数你所关心的信息。为了可以集成在咱们公司的体系中，你可能会开发一些后台管理功能，进行更多的控制。这部分开发简单，只须要作个界面，直接经过API读取Consul的数据就能够了。

说说个人想法：

第一点：注册中心的选择。对于Eureka再也不更新以后，到底选择使用哪一个并无彻底的最优解，存在即合理，选择适合本身团队（技术栈、使用成本）的，才是最须要考虑的点。

第二点：做者建议“Nacos最好的方式仍是独立发布，而后维护一个starter”。这确实是一个很好的建议，可是这点我就奇怪了，做者到底有没有看过Nacos？Nacos目前就是独立发布的，Spring Cloud Alibaba对Nacos的支持，只是Nacos在客户端应用中，针对Spring Cloud用户的一种应用方式而已。

因此，做者到底有没有看过Spring Cloud Alibaba Nacos的方案？

第三点：熔断、限流

看看这篇文章的解读：

这部分已经被炒做成微服务体系的必备组件，但扪心自问，这个功能对于中小型的应用可能就是一个摆设。但咱们仍是要搞的，由于这是个卖点。

SpringCloud默认的组件是Hystrix，提供了多线程和信号量来控制的不一样方式。惋惜的是Hystrix也宣布再也不维护了，官方推荐的替换版本是resilience4j。

熔断限流功能实际上是很是简单的，同事花了一周时间就撸了个足够用的组件。这部分的主要设计在于可以简单的应用，最好是可以经过后台配置实时生效。

爸爸版的是Sentinel，虽然也带了个后台，可是并无和注册中心进行集成，搞了个不三不四。

我要用Sentinel，我本身集成就行了，用你个大头鬼。

说说个人想法：

第一点：我以为做者能碰到一个能撸出熔断、限流框架和配置管理的同事，仍是很是幸运的。可是并非全部的团队都有人能够作这些，因此我以为有这样的开源项目无论放在何时，都是对行业有益的。你不用没啥问题，可是并不表明对别人没用，并不表明这个项目不够优秀。

第二点：对于做者所说的，没有与注册中心集成，搞得不三不四。这里的不三不四，一直没能Get到做者的点。。。不知道是否是有点“为赋新词强说愁”的感受？我的在对比Hystrix和Sentinel的时候，仍是以为有很是多要比Hystrix作得更好的地方的。

固然真正应用到本身的架构体系中，一般都是须要作一些适配、自定义等工做的。可是，对于开源产品的扩展，历来都不是用来抨击开源项目的核心缘由。

第四点：集成本身的服务

这点是我通篇以为最好笑的，先来看看做者对于AWS和Azure对Spring Cloud整合的赞美：

话说这aws，搞了个本身的SpringCloud，集成了本身的众多的服务，相辅相成，卖的很好。因而Azure等，也搞了一套，只不过只能跑在本身的云上。若是你用了，哪一天若是想换主机环境了，就会知道这些爸爸们是多么的爱你。

可是到了Alibaba作这些，就成了：

重要的组件不集成，反而集成了一堆相似于OSS、ANS、SMS、MQ等非必须的功能，这就是偷奸耍滑了。

一样是集成本身的商业服务来作好对客户的支持，我以为是任何一个厂商加强自身产品实力必需要作的。到底好很差，用户说了算。

就拿我的而言，咱们也是阿里云的客户，对于OSS、RocketMQ这些必不可少的产品，若是提供Spring Cloud的Starter，让我更好的使用它们。从用户角度来讲，省去了不少本身封装的工做，有什么很差呢？

总结

如今技术圈有个怪现象，自从一些技术自媒体人开始分享本身如何经过分享技术来赚钱开始，催生出了愈来愈多的技术自媒体。

而后就出现了这样的奇葩现象：

• 没有作过面试官的人在分享如何应对面试
• 没有作过架构师的人在分享如何成为架构师
• 没有赚到钱的人在分享如何赚钱
• 不是中产的人在分享如何成为中产
• ...

不能否认，作技术自媒体是能够赚钱。可是单纯为了赚钱的技术自媒体，生搬硬套那些大V们分享的赚钱方法，为了追求流量，会使用夸大表述、扭曲事实、传播侵权内容、编故事博取同情等手段来得到关注和转发。这使得不少技术内容的分享就变得不那么纯粹了，甚至会对读者形成对技术内容的误解。

我没有能力去控制那些自媒体发布这些不实的内容，可是在我了解的范围内，仍是尽力输出一些个人理解。但愿能够给这些误读内容不一样的声音，可以引发读者的注意，从而但愿你们能够多一些本身的思考。

固然，个人观点也不必定都是对的，因此无论读者看到什么内容，必定要保持本身的思考。当你发现网上有内容发生冲突的时候，惟一能够解决的方式不是选择一方去相信，仍是要本身去深刻研究，去验证哪个观点才是正确的。

最后，声明一点：我不是Spring Cloud Alibaba的成员，也不是阿里系公司的员工。对于Spring Cloud Alibaba的支持，只是我做为一名奋斗在一线的程序员的简单思考。

若是您以为我说的不对，很是欢迎能够留言讨论。

欢迎关注我长期连载的《Spring Cloud基础教程》