前言

技术的浪潮汹涌澎湃，每隔数年便有一波新浪潮涌来。大数据、云计算、人工智能、NoSQL、Node.js、Docker……潮流更迭之间，技术人员欣喜于百宝箱中又添新兵，而架构师却面临着一道艰难的抉择题：这些新技术，要不要跟？

这个问题之所以让人寝食难安，是因为它关乎技术方向，关乎团队精力，更关乎业务的未来。架构师不是技术的奴隶，但也不是技术的绝缘体。真正的智慧，在于能够在纷繁复杂的技术丛林中，找到那条通往业务成功的道路。

技术演进的三个派别

面对层出不穷的新技术，架构师们大致可以分为三类典型：

潮流派的典型特征是对于新技术特别热衷，紧跟技术潮流，当有新的技术出现时，迫切想将新的技术应用到自己的产品中。NoSQL 很火，就要大规模切换为 NoSQL；大数据好牛，就要把 MySQL 切换为 Hadoop；Node.js 统一前后端，就要用 Node.js 重写一切。

保守派的典型特征和潮流派正好相反，对于新技术抱有很强的戒备心，稳定压倒一切。就像那句俗语说的，"如果你手里有一把锤子，那么所有的问题都变成了钉子"，保守派就是拿着一把锤子解决所有的问题。MySQL 用了这么多年很熟悉，那就一切皆 MySQL；Java 业务用，工具用，平台也用 Java。

跟风派与潮流派不同，这里的跟风派不是指跟着技术潮流，而是指跟着竞争对手的步子走。腾讯用了我们就用，阿里用了 Hadoop，那肯定是好东西，Google 都用了 Docker，我们也不能落后。

不同派别的不同做法本质上是价值观的不同：潮流派的价值观是新技术肯定能带来很大收益；稳定派的价值观是稳定压倒一切；跟风派的价值观是别人用了我就用。这些价值观本身都有一定的道理，但如果不考虑实际情况生搬硬套，就会出现"橘生淮南则为橘，生于淮北则为枳"的情况。

三个派别的问题

潮流派首先会遇到的问题是：新技术需要时间成熟，如果刚出来就用，此时新技术还不怎么成熟，实际应用中很可能遇到各种"坑"，自己成了实验小白鼠。其次，新技术需要学习，需要花费一定的时间去掌握，如果等到掌握了技术后又发现不适用，则是一种较大的人力浪费。

保守派的主要问题是不能享受新技术带来的收益，因为新技术很多都是为了解决以前技术存在的固有缺陷。就像汽车取代马车一样，不是量变而是质变，带来的收益不是线性变化的，而是爆发式变化的。如果无视技术的发展，形象一点说就是有了拖拉机，你还偏偏要用牛车。

跟风派看起来最稳妥，既不会承担"潮流派"的风险，也不会遭受"保守派"的损失。但跟风派最大的问题在于如果没有风可跟的时候怎么办？如果你是领头羊怎么办？另外，竞争对手的这些信息并不那么容易获取，即使获取到了一些信息，大部分也是不全面的，一不小心可能就变成邯郸学步了。即使有风可跟，有时候适用于竞争对手的技术，并不一定适用于自己，盲目模仿可能带来相反的效果。

技术演进的动力

不管是潮流派、保守派，还是跟风派，都是站在技术本身的角度来考虑问题的，正所谓"不识庐山真面，只缘身在此山中"。因此，要想看到"庐山真面目"，只有跳出技术的范畴，从一个更广更高的角度来考虑，这个角度就是企业的业务发展。

无论是互联网企业还是传统企业，业务发展的核心驱动力在于三个因素：市场、技术、管理。这三者构成支撑业务发展的铁三角，任何一个因素的不足都可能导致企业的业务停滞不前。

我们可以简单地将企业的业务分为两类：产品类和服务类。

产品类业务：360 的杀毒软件、苹果的 iPhone、UC 的浏览器等都属于这个范畴。这些产品本质上和传统的制造业产品类似，用户对产品是独占的。技术创新推动产品类业务发展。苹果开发智能手机，将诺基亚推下王座；UC 浏览器独创云端架构解决了上网慢的问题。

服务类业务：百度的搜索、淘宝的购物、新浪的微博、腾讯的 IM 等都属于这个范畴。大量用户使用这些服务来完成需要与其他人交互的任务，用户"使用"但不"独占"某个服务。服务类的业务发展推动技术发展。为什么？因为用户选择服务的根本驱动力是"规模"，而不是功能。

以淘宝为例，淘宝提供的"网络购物"是一种新的服务，随便一个软件公司半年时间就可以开发出类似的产品。但是这样做并没有意义，因为用户选择的是淘宝的整套网络购物服务，并且这个服务已经具备了一定的规模，其他公司不具备这种同等规模服务的能力。

服务类业务的典型发展路径是：提出一种创新的服务模式 → 吸引第一批用户 → 业务开始发展 → 吸引更多用户 → 服务模式不断完善和创新 → 吸引越来越多的用户。在这个发展路径中，技术并没有成为业务发展的驱动力，反而是用户规模的不断扩展对技术提出了越来越高的要求。

技术演进的判断标准

明确了技术发展主要的驱动力是业务发展后，我们需要进一步理解业务发展究竟是如何驱动技术发展的。

业务模式千差万别，但无论什么模式的业务，如果业务的发展需要技术同步发展进行支撑，无一例外是因为业务"复杂度"的上升，导致原有的技术无法支撑。按照前面的复杂度分类，复杂度要么来源于功能不断叠加，要么来源于规模扩大，从而对性能和可用性有了更高的要求。

所以，对于架构师来说，判断业务当前和接下来一段时间的主要复杂度是什么就非常关键。判断不准确就会导致投入大量的人力和时间做了对业务没有作用的事情，判断准确就能够做到技术推动业务更加快速发展。

答案就是：基于业务发展阶段进行判断。这也是为什么架构师必须具备业务理解能力的原因。不同的行业业务发展路径、轨迹、模式不一样，架构师必须能够基于行业发展和企业自身情况做出准确判断。

以银行为例：

• 90 年代主要的业务复杂度是银行业务范围逐渐扩大，功能越来越复杂，导致内部系统数量越来越多，单个系统功能越来越复杂。
• 2004 年以后主要的复杂度是银行业务从柜台转向网上银行，网上银行的稳定性、安全性、易用性是主要的复杂度。
• 2009 年以后主要的复杂度又变化为移动支付复杂度，尤其是在"双 11"这种海量支付请求的情况下，高性能、稳定性、安全性是主要的复杂度。

而如果你是淘宝这种互联网业务的架构师，业务发展又是另外一种模式：

• 2003 年，业务刚刚创立，主要的复杂度体现为如何才能快速开发各种需求，淘宝团队买了一个 PHP 写的系统来改。
• 2004 年，上线后业务发展迅速，用户请求数量大大增加，主要的复杂度体现为如何才能保证系统的性能，淘宝团队用 Oracle 取代 MySQL。
• 2005 年，用户数量继续增加，主要的复杂度体现为单一的 Oracle 库已经无法满足性能要求，于是进行了分库分表、读写分离、缓存等优化。
• 2008 年，淘宝的商品数量在 1 亿以上，PV 2.5 亿以上，主要的复杂度又变成了系统内部耦合，淘宝团队采取的是系统解耦。

总结

• 技术演进的判断不能仅从技术本身出发，必须结合业务发展阶段综合考虑
• 潮流派、保守派、跟风派都有各自的问题，盲目采用任何一种策略都可能导致失败
• 产品类业务的驱动力是技术创新，服务类业务的驱动力是业务发展（规模）
• 技术复杂度的上升是业务驱动技术发展的根本原因，主要体现在功能复杂度和规模复杂度
• 架构师必须具备业务理解能力，基于业务发展阶段判断主要复杂度类型
• 不同行业的业务发展路径不同，架构师需要深入理解行业特点才能做出准确判断
• 合适的技术演进策略是演进式的，根据业务阶段逐步投入，而非一步到位或完全排斥新技术
• 竞争对手的技术选型可供参考，但必须结合自身实际情况判断是否适合

参考资料

• 软件架构基础