踩坑”屎“写到了dubbo这里，详细很多人会好奇，我忽然想起来当年切换到spring cloud的决策过程还是满艰辛的，整个过程，我自己做了许多调研，可能很多调研的细节都已经忘掉了，今天就把当初做决策过程的一些零碎的记忆拼凑在一起，写个系列文章。
记得在17年的时候，dubbo还是很多公司的主流，即便到现在，我了解的公司里还是有很多公司依然在沿用dubbo，这里主要有几点：
1、dubbo虽然只是一个服务化的体系，但在cloud全家桶没有普及前，dubbo的周边还是相当多的。
2、当时做服务化的时候，虽然也有一些服务化技术产品，但实际上资料最多的社区最火的还是dubbo，我记得当时有当当改版的dubbox（新加了一些feature具体请谷歌吧~）、微博的Motan、facebook的thrift、grpc等服务化架构，其中motan虽然开源的时候声音较大，但实际上我没听到身边有多少人采用。thrift虽然很好用，支持多语言，但在中国并不火，因为中国还是java占统治地位的。gpc出现的比较晚，并且，grpc有一个缺点就是，api还是需要通过工具去生成，略重，这点和dubbo很像。而dubbo我记得停止更新了很久了，最后一个版本是2.5.4吧，比起当当的dubbox还是缺少了一些有用的特性。
3、社区的活跃、网上的资料，dubbo是绝对统治级别的，尤其是在杭州这个地方，dubbo简直就像是java一样，是每个后端程序员必须会的。
因此，dubbo在spring cloud没有全面崛起之前，在17年一样是很多公司的首选。当时的技术发展，其实还是有很多选型的空间的，这些中间件来自于各个不同的公司，不同的代码风格，甚至不同的jar包的版本号，这给公司的技术融合带来了很大的困难。比如，jdk7升级到jdk8的话，你会发现，很多中间件并不支持，这时候，你需要维护这些开源的中间件，把他们做一次升级，这中间的成本和风险，可想而知。
那我们就通过服务端的技术选型来了解下公司的一些公司的技术体系吧，等下我去画个草图
服务端架构体系图
上图是服务端的一些架构体系图，其实还可以画的更细一些，但为了能从更高一点的角度去讨论这两套生态，我还是把粒度放的稍微大一些。
其实我面试过的候选人，在P6实力左右的人，大都无法能完整的把这套生态画出来，可能他们懂，但思维体系缺少结构化、系统化；以后在面试后端leader或者资深的时候，也可以考虑让大家画一下后端的架构图。关于前端和客户端的架构体系，以后我会再画一下。
家里贼热，坚持不住了，后面我会按照这里面所有组件，我先来个抛砖引玉吧，我们最常用的缓存是redis，但实际上redis一样经历了很多的年的进化；从最开始的redis主从、通过keepalived实现的高可用集群、哨兵模式、一致性哈希缓存集群、redis中间件（Twemproxy、codis等）、到目前的redis3.x的cluster方案，每一种演变都有它的进化史；卧槽，怎么回事，这跟服务化生态好像没关系啊......跑题了~~~反正就是抛砖引玉hiahiahia~~~~
网友评论