技术选型最怕的是什么？

环信 · 7 年前

引言

昨天聊聊架构发布了一篇关于技术选型的文章，文章作者介绍了目前流行的技术选型方式，比如有微博驱动、技术会议驱动、嗓门驱动、领导驱动.....不少读者都表示深有体会，并在评论区贴出了自己的经历。今天再推荐一篇由环信首席架构师一乐所撰写的关于技术选型的文章（旧文），希望能帮到各位。另推荐一乐的个人微信一乐来了，id是yilecoming，欢迎关注。这也许是我上半年最大的欠账，在去普吉的飞机上突发无聊，想想还了这债吧。

去年的时候，我们使用Cassandra出了一次问题，定位加修复用了一晚上。当我把经历发出来的时候，收到了下面一段话：

“一个开源产品，连官方文档都没看完大半，然后匆匆忙忙上生产环境，出了问题团团转。若是不能掌控就先不要玩，说回这Cassandra的例子，在对它不了解的情况下，仅通过Google就能解决问题，不正说明它不难掌握有大量资料可查吗，实在不行还能翻代码。”

我现在都不知道这位神仙从哪里看到的匆匆忙忙上和团团转，当时我还是忍了，因为实在太忙，口水又没那么多。当然我思考了很多，这就是你现在看到的文章。我相信它会有一些价值，毕竟有些事情有的人你不告诉他，他永远不可能知道。比如个体认知的局限，比如口无遮拦的损失，比如做事之人才会有的思考角度。

本文讲的是技术选型。

大多数技术都存在选型问题，因为技术的发展已经让一件事情可以有多种解决方案，选型问题就自然出现。前段时间也有人说过语言选型，这里举的例子是在组件、框架、服务的范畴。其中有相通之处，各位可以自行领会。

选型最怕什么

怕失败么？那肯定的。你的服务崩溃，用户愤而投诉，客户电话打到老板那里，明天你要洗干净到办公室去一趟（笑...）。而所有对失败的无法容忍，最终都会变成一句话，为什么你要选这个型？

你总要回答这个问题，所以选型一怕随意，公鸡头母鸡头，选上哪头是哪头；二怕凭感觉，某某已经在用听起来还不错。你需要真正的思考，而且尽可能的全面。我下文会详细讲解，但这还不是最怕的。

最怕的是什么？看看本文开头引用的那句话，你体会一下。

嗯，最怕的是喷子。怕任意总结，如果再加上一些诋毁，一次选型失败足以让人心碎一万次。

失败不可怕，可怕的是没有总结，因为没有总结就没有提高。而比没有总结更可怕的是乱总结。

为了方便理解，我再帮你换个角度。你天天在河边走，一次不小心湿了鞋。如果是本文说的这种人，那肯定要说：

一条公共的河，你连旱季旺季都没搞清楚，就匆匆忙忙跑过来散步，湿了鞋还到处讲。若是脚不行就别在这玩，说回这条河，湿了鞋就能爬上来，不正说明他水不深么。

这种人实在不算少见。他说的每一句话都有一点道理，但都跟事情的本质毫无关系，每一句话又都掺加了嘲讽，来体现那无处安放的莫名优越感。而所有的这些，对于解决问题和后续提高通常毫无帮助。

想想也真遗憾，人生本是如此美好，有的人却硬生生地活成了奇葩。

选型需要什么

言归正传，我认为有三点不可或缺：分析、实验和胆量。

分析

分析主要有定性分析和定量分析。实际操作中，前者主要针对的是模型维度的估计，用来考虑一个组件是否有可能达到它宣称的目的，后者主要用来验证，用来确认它是否在真的做到了。

比如在语言选型时，你要考虑它的范型、内存模型和并发设计；数据库选型时你要考虑存储模型、支撑量级、成本开销；开源项目要考虑它的社区发展、文档完善程度；如果是库或者中间件，还要考虑他的易用性、灵活性以及可替代性，等等。

需要说明的一点是，我个人并不觉得阅读全部源码或者文档这种事情是必须的，这不局限在OS、VM层面。不仅因为这样的事情会耗费过多精力，而且受制于代码以及文档质量，就算真正阅读完毕也未必意味着完全领会。

这些都是定性的，而定性的东西就有可能存在理解偏差。一个库可以完成工作，并不代表它在高并发压力下依然表现正常；一个语言做到了自动管理内存，并不代表他能做得很好没有副作用；一件事情设计者觉得达到了目标并不代表能够满足使用者期望。因此我们还需要量化分析，也就是一直口口相传的，用数据说话。

量化分析需要你构建或使用现成的工具和数据集，对服务进行特定场景下的分析。通过提高压力、增加容量或者针对性的测试，来验证之前的定性分析是否达到预期，并分析不同技术之间的差异和表现。

实验

量化分析可以为真正的实验做一些准备和帮助，但是实验要走的明显更远。到了这一步，意味着要在真正的业务场景下进行验证，这跟量化分析中通用性场景有所不同。

在真正的业务中采用需要很多细致和琐碎的工作，除此之外，还要构建自己的测试工具集，这需要非常扎实的业务理解能力和勤奋的工作。而所有这些，你需要在开发环境做一次，在沙箱环境做一次，然后在仿真环境再做一次。

这几步经常被简化，但经验告诉我们，如果你想做一个高可用的系统，你就不应该少走任何一步。

步子大了，容易扯到蛋。

胆量

实验做完，剩下的就是上线，但这一步有很多人跨不过去。因为就算做了再多准备，你依然不敢说百分百保证没问题。现实情况是，80%的线上问题都是升级或者上线引起的。

你需要胆量。

这不是说要硬着头皮做，人家都是艺高才胆大。所以为了让胆子大一点，你首先需要考虑降级和开关。从最悲观的角度来重新审视整个方案，如果升级出现问题怎么办，如何才能让出现的问题影响最小化。

而只要弄完了这些，也就只要再记住一句话就行：

你行你上啊！

对技术服务的提醒

得到认可

刚才在胆量里没说的一点。我们经常会看到，一项新技术在公司内久久难以推行，因为业务主管百般阻挠。即使排除利益纠葛，仍然会发现一种发自心底的不信任存在。而这种不信任，又往往来源于对同事工作的不认可。

这个问题原因很多，也许没有通用的解决方案，但我说一个例子。

我们最近开始使用Codis，就是@goroutine 和几个家伙之前搞过的玩意儿。虽然他们最近已经独立开搞像Google Spanner但拥有更高级特性的TiDB（就是太牛了的意思）。由于我对他们比较熟悉和认可，所以在Codis尝试方面也多出很多底气。这种信任并非完全来自于出问题之后的直接电话支持，而是真心觉得活儿好。

反过来，这对很多服务也是一个提醒，特别是云服务。也许只要你得到合作伙伴的认可，或者至少让他们觉得，自己动手不会比你做得更好，你基本也就成功了。

对于大多数理性创业公司来讲，他们还是更愿意把精力放在自己的主要业务上，不会希望所有的服务都自己做，因为这个年代，唯快不破，创业等不起一辈子。

产品意识

回到开始那句话，“在对它不了解的情况下，仅通过google就能解决问题，不正说明它不难掌握有大量资料可查吗，实在不行还能翻代码。” 这话有些道理，然而却存在一个问题，这个问题就是：

作为一个使用者，是否有能力解决遇到的问题，与是否有意愿去遇到并解决问题，是两回事。

你有本CPU设计手册，你可以说处理器很简单，但我只想看个电影啊？给你Linux内核的源码，你可以说内核设计不难掌握，但我只想跑个游戏啊？何况他们是否因此就变得不难了，也是值得怀疑的。

这其实反映了技术人的产品意识。

很多技术人员喜欢玩酷的东西，他们愿意去探索新的领域，把不可能的变为可能。但是很多时候，他们做出来的东西却很难使用。

有的库可以增加很多参数，参数之间却有耦合，导致你在采用的时候需要写很多设置代码，而有点库却只需要一行代码；有的服务功能众多，却需要用户学习繁杂的步骤，而有的服务却可以开箱即用；有的服务功能可以实现，却会有很多不稳定甚至崩溃的情况出现，等等。

对于实现的工程师来讲，可能最大的区别在于，你是否考虑从用户的角度审视过自己的东西。即使这个服务也许只是为其他技术人员使用的。

技术人员可以，也应该，让技术人员更幸福。