技术选型：喷子、胆量和产品意识

这也许是我上半年最大的欠账，在去普吉的飞机上突发无聊，想想还了这债吧。

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

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

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

本文讲的是技术选型。

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

选型最怕什么

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

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

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

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

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

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

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

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

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

选型需要什么

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

###分析

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

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

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

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

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

实验

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

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

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

“步子大了，容易扯到蛋。”

胆量

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

你需要胆量。

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

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

“你行你上啊！”

对技术服务的提醒

得到认可

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

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

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

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

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

产品意识

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

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

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

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

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

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

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

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

后记

还是要声明一下，本文用神仙举例，纯粹是因为他太典型了。我内心是希望他不要介意的，而且也曾慎重考虑，给这篇文章起一个更加温柔的标题，比如如何在微博上做一个安静的美男子。

然而还是这样吧。