一个简单的技术选型心得

水文一篇，欢迎拍砖吐槽评论。



前几天曾和一技术人聊天，被问到“你怎么说服现在公司技术栈从http接口调用转型Dubbo系技术栈”问题，因为感觉前面的聊天有些戏谑的成分，所以当时也没有认真的回答这个问题，只是凭感觉回答，大意是如果原来技术栈有自己一套RPC/路由/负载/容错/网关等机制，不一定非要转Dubbo。

路上笔者思考了下，这类问题有没有一个通用的答案呢？

笔者第一反应是自己的回答过于草率，不够深度。

比如首先可问清楚这个基于http技术栈是自研的还是指SpringCloud，说服的对象是面向决策者还是员工。

1）

对于非SpringCloud的情况很容易，有足够的理由说服决策者，一句“dubbo是硬通货”足够了，相信对大多数技术追求不强烈的企业来说，一套通用的工具、员工可自身技能积累、不用过多培训即可上岗的技术栈是每个公司领导者欢迎的。

但对于技术追求型团队来说，http未尝不可，比如曾经历某公司就是自研RPC，基于netty+http+json/thrift，当时也尚有自研监控/trace/代码生成等一套，非常方便业务研发。与其说这是一种技术积累和沉淀，不如说是技术人才的培养，如果只是直接用Dubbo一套，笔者相信也很难找到其他亮点能表明这是一家技术实力强大的科技公司，况且那时Dubbo已经停止更新两年多，SpringCloud也才异军突起不久。

2）

对于SpringCloud，则要慎重，因为毕竟SpringCloud系列技术栈功能足够，是一套完整的微服务体系，Dubbo作为rpc框架当然也有相应周边组成微服务体系，笔者觉得要说服不仅要从性能功能等方面，也应从但维护团队却不同以及人员变动，他们的未来甚至行业里类似几家互联网金融产品公司也是Dubbo体系（即便其技术人员可能非阿里系的）。

不过，笔者认为如果他们是业界都被认可的方案，那么很难有足够的理由说服，毕竟他们也是都经历过足够的优劣对比才被业界认可的方案，而作为变革者你能找到的理由不会超出两种技术本身的优劣（介绍对比），[同样的，如果业界有分歧而你司却没有分歧，那么我认为变革者最好反思下了]。

3）

对于说服开发者，其实就比较简单，掌握新的技能，硬通货技能，从技术角度分析新框架带来的便利性，节省时间提高效率等，大家开发更流畅。

不论这些理由是否真实或合理，这是现状下由开发者所处境遇决定的。



但是笔者的第一反应真的是不够深度吗？

高屋建瓴者看到的是技术架构，负责真正实现的编程人员看到的是代码。“不要轻易修改或删除已经存在的代码”或“宁愿重写也不修改”可能是很多编程人员的经验或踩坑后的感言。仅从代码上来说重构也不是一件容易的事，否则Martin Fowler也不会写一本《重构》的书去讨论了。

Knuth告诫“不要过早优化”，这句话不同人理解不同，支持反对皆有。不过，笔者还是赞同优化要慎重这个经验的。

也就是第一反应其实没有错，除非 http调用这种方式是真的遇到痛点了，并且这种痛点不是说技术变革者找出来或者PPT里列出来的，而是真正使用者即编程人员们切切实实感受到的痛点，并且非优化不可，而决策者体会到开发者这种痛点时，这个时候去推广Dubbo才是水到渠成事半功倍。

而过早提议、主动提议、没感受到痛点的时候就去推行技术变革，那很可能得到的是老开发人员的阻力，甚至即便他们支持你，但是领导者可能不是那么清楚到你的成效，而迁移过程稍微遇错则很可能被无情的放大。

笔者认为通常两种成功的路径：

其一：来自上层技术决策者强烈的个人意志力。一个成功的例子就是携程从.net转Java。

其二：来自团队切实跟受到痛点。这类或许大家都有类似经历。一个听来的故事，Twitter早期即是Ruby系列，之后经历Java/Scala，在解散诸多Scala核心人员后，据说Twitter有技术决策权的领导被问到如果可以再选择是否依旧Scala时，给出了“不确定”的回答。

扁鹊三兄弟的故事岂不值得一听。

但不管如何，技术变革者要清楚待面对的问题--不仅仅是作为单纯的技术人员的清楚。



题图为 Bing20200216 壁纸