大家好，我是李运华。
互联网的呈现岂但扭转了普通人的生存形式，同时也促成了技术圈的疾速倒退和凋谢。在开源和分享两股力量的推动下，最近 10 多年的技术倒退能够说是应接不暇，你方唱罢我退场，大的方面有大数据、云计算、人工智能等，细分的畛域有 NoSQL、Node.js、Docker 容器化等。各个大公司也乐于将本人的技术分享进去，以此来晋升本人的技术影响力，打造圈内技术口碑，从而造成弱小的人才吸引力，典型的有，Google 的大数据论文、淘宝的全链路压测、微信的红包高并发技术等。
对于技术人员来说，技术的疾速倒退当然是一件大好事，毕竟这意味着技术百宝箱中又多了更多的可选工具，同时也能够通过学习业界先进的技术来晋升本人的技术实力。但对于架构师来说，除了这些益处，却也多了“苦涩的懊恼”： 面对层出不穷的新技术，咱们应该采取什么样的策略？
架构师可能常常会面临上面这些引诱或者挑战：
- 当初 Docker 虚拟化技术很风行，咱们要不要引进，引入 Docker 后能够每年节俭几十万元的硬件老本呢？
- 竞争对手用了阿里的云计算技术，据说因为上了云，业务增长了好几倍呢，咱们是否也应该尽快上云啊？
- 咱们的技术和业界顶尖公司（例如，淘宝、微信）差距很大，应该投入人力和工夫追上去，不然招聘的时候没有技术影响力！
- 公司的技术倒退当初曾经比拟成熟了，程序员都感觉在公司学不到货色，咱们能够尝试引入 Golang 来给大家一个学习新技术的机会。
相似的问题还有很多，实质上都能够演绎总结为一个问题：架构师应该如何判断技术演进的方向？
对于这个问题的答案，基本上能够分为几个典型的派别：
1. 潮流派
潮流派的典型特色就是对于新技术特地热衷，紧跟技术潮流，当有新的技术呈现时，迫切想将新的技术利用到本人的产品中。
例如：
NoSQL 很火，咱们要大规模地切换为 NoSQL。
大数据好牛呀，将咱们的 MySQL 切换为 Hadoop 吧。
Node.js 使得 JavaScript 对立前后端，这样十分有助于发展工作。
2. 保守派
保守派的典型特色和潮流派正好相同，对于新技术抱有很强的警戒心，稳固压倒一切，曾经把握了某种技术，就始终用这种技术打天下。就像有句俗语说的，“如果你手里有一把锤子，那么所有的问题都变成了钉子”，保守派就是拿着一把锤子解决所有的问题。
例如：
MySQL 咱们用了这么久了，很相熟了，业务用 MySQL，数据分析也用 MySQL，报表还用 MySQL 吧。
Java 语言咱们都很熟，业务用 Java，工具用 Java，平台也用 Java。
3. 跟风派
跟风派与潮流派不同，这里的跟风派不是指跟着技术潮流，而是指跟着竞争对手的步子走。
简略来说，判断技术的倒退就看竞争对手，竞争对手用了咱们就用，竞争对手没用咱们就等等看。
例如：
这项技术腾讯用了吗？腾讯用了咱们就用。
阿里用了 Hadoop，他们都在用，必定是好货色，咱们也要尽快用起来，以进步咱们的竞争力。
Google 都用了 Docker，咱们也用吧。
不同派别的不同做法实质上是价值观的不同：潮流派的价值观是新技术必定能带来很大收益；稳固派的价值观是稳固压倒一切；跟风派的价值观是他人用了我就用。这些价值观自身都有肯定的情理，但如果不思考理论状况生吞活剥，就会呈现“橘生淮南则为橘，生于淮北则为枳”的状况。
上面咱们来看一下不同的派别可能存在的问题。
1. 潮流派
首先，新技术须要工夫成熟，如果刚进去就用，此时新技术还不怎么成熟，理论利用中很可能遇到各种“坑”，本人成了试验小白鼠。
其次，新技术须要学习，须要破费肯定的工夫去把握，这个也是较大的老本；如果等到把握了技术后又发现不实用，则是一种较大的人力节约。
2. 保守派
保守派的次要问题是不能享受新技术带来的收益，因为新技术很多都是为了解决以前技术存在的固有缺点。就像汽车取代马车一样，不是质变而是量变，带来的收益不是线性变动的，而是爆发式变动的。如果忽视技术的倒退，形象一点说就是有了拖拉机，你还偏偏要用牛车。
3. 跟风派
可能很多人都会认为，跟风派与“潮流派”和“保守派”相比，是最无效的策略，既不会承当“潮流派”的危险，也不会蒙受“保守派”的损失，破费的资源也少，几乎就是一举多得。
看起来很美好，但跟风派最大的问题在于如果没有风可跟的时候怎么办。如果你是领头羊怎么办，其他人都筹备跟你的风呢？另外一种状况就是竞争对手的这些信息并不那么容易获取，即便获取到了一些信息，大部分也是不全面的，一不小心可能就变成邯郸学步了。
即便有风可跟，其实也存在问题。有时候实用于竞争对手的技术，并不一定实用于本人，自觉模拟可能带来相同的成果。
既然潮流派、保守派、跟风派都存在这样或者那样的问题，那架构师到底如何判断技术演进的方向呢？
技术演进的能源
这个问题之所以让人困惑，要害的起因还是在于不论是潮流派、保守派，还是跟风派，都是站在技术自身的角度来思考问题的，正所谓“不识庐山真面，只缘身在此山中”。因而，要想看到“庐山真面目”，只有跳出技术的领域，从一个更广更高的角度来思考这个问题，这个角度就是企业的业务倒退。
无论是代表新兴技术的互联网企业，还是代表传统技术的制造业；无论是通信行业，还是金融行业的倒退，归根到底就是业务的倒退。而影响一个企业业务的倒退次要有 3 个因素： 市场、技术、治理 ，这三者形成撑持业务倒退的铁三角，任何一个因素的有余，都可能导致企业的业务停滞不前。
在这个铁三角中，业务处于三角形的核心，毫不夸大地说，市场、技术、治理都是为了撑持企业业务的倒退。在专栏里，我次要探讨“技术”和“业务”之间的关系和相互如何影响。
咱们能够简略地将企业的业务分为两类：一类是产品类，一类是服务类。
产品类：360 的杀毒软件、苹果的 iPhone、UC 的浏览器等都属于这个领域，这些产品实质上和传统的制造业产品相似，都是具备了某种“性能”，单个用户通过购买或者收费应用这些产品来实现本人相干的某些工作，用户对这些产品是独占的。
服务类：百度的搜寻、淘宝的购物、新浪的微博、腾讯的 IM 等都属于这个领域，大量用户应用这些服务来实现须要与其他人交互的工作，单个用户“应用”但不“独占”某个服务。事实上，服务的用户越多，服务的价值就越大。服务类的业务合乎互联网的特色和实质：“互联”+“网”。
对于产品类业务，答案看起来很显著：技术创新推动业务倒退！
例如：
苹果开发智能手机，将诺基亚推下王座，本人成为寰球手机行业的新王者。
2G 时代，UC 浏览器独创的云端架构，很好地解决了上网慢的问题；智能机时代，UC 浏览器又自主研发全新的 U3 内核，兼顾高速、平安、智能及可扩展性，这些技术创新是 UC 浏览器成为了寰球最大的第三方手机浏览器最强有力的推动力。
为何对于产品类的业务，技术创新可能推动业务倒退呢？答案在于用户抉择一个产品的基本驱动力在于产品的性能是否可能更好地帮忙本人实现工作。用户会自然而然地抉择那些性能更加弱小、性能更加先进、体验更加顺畅、外观更加丑陋的产品，而性能、性能、体验、外观等都须要弱小的技术撑持。例如，iPhone 手机的多点触摸操作、UC 浏览器的 U3 内核等。
对于“服务”类的业务，答案和产品类业务正好相同：业务倒退推动技术的倒退！
为什么会呈现截然相同的差异呢？次要起因是用户抉择服务的基本驱动力与抉择产品不同。用户抉择一个产品的基本驱动力是其“性能”，而用户抉择一个服务的基本驱动力不是性能，而是“规模”。
例如，抉择 UC 浏览器还是抉择 QQ 浏览器，更多的人是依据集体爱好和体验来决定的；而抉择微信还是 Whatsapp，就不是依据它们之间的性能差别来抉择的，而是依据其规模来抉择的，就像我更喜爱 Whatsapp 的简洁，但我的敌人和周边的人都用微信，那我也不得不用微信。
当“规模”成为业务的决定因素后，服务模式的翻新就成为了业务倒退的外围驱动力，而产品只是为了实现服务而提供给用户应用的一个载体。以淘宝为例，淘宝提供的“网络购物”是一种新的服务，这种业务与传统的到实体店购物是齐全不同的，而为了实现这种业务，须要“淘宝网”“支付宝”“一淘”和“菜鸟物流”等多个产品。
轻易一个软件公司，如果只是模拟开发出相似的产品，只有违心投入，半年工夫就能够将这些产品全副开发进去。然而这样做并没有意义，因为用户抉择的是淘宝的整套网络购物服务，并且这个服务曾经具备了肯定的规模，其余公司不具备这种等同规模服务的能力。即便开发出齐全一样的产品，用户也不会因为产品性能更加弱小而抉择新的相似产品。
以微信为例，同样能够得出相似论断。如果咱们进行技术创新，开发一个耗电量只有微信的 1/10，用户体验比微信好 10 倍的产品，你感觉当初的微信用户都会摈弃微信，而转投咱们的这个产品吗？我置信绝大部分人都不会，因为微信不是一个互联网产品，而是一个互联网服务，你一个人换到其余类微信类产品是没有意义的。
因而，服务类的业务倒退门路是这样的：提出一种翻新的服务模式→吸引了一批用户→业务开始倒退→吸引了更多用户→服务模式不断完善和翻新→吸引越来越多的用户，如此周而复始。在这个倒退门路中，技术并没有成为业务倒退的驱动力，反过来因为用户规模的一直扩大，业务的不断创新和改良，对技术会提出越来越高的要求，因而是业务驱动了技术倒退。
其实回到产品类业务，如果咱们将察看的工夫拉长来看，即便是产品类业务，在技术创新创始了一个新的业务后，后续的业务倒退也会反向推动技术的倒退。例如，第一代 iPhone 短少对 3G 的反对，且只能通过 Web 公布应用程序，第二代 iPhone 才开始反对 3G，并且内置 GPS；UC 浏览器随着性能越来越弱小，原有的技术无奈满足业务倒退的需要，浏览器的架构须要进行更新，先后通过 UC 浏览器 7.0 版本、8.0 版本、9.0 版本等几个技术差别很大的版本。
综合这些剖析，除非是开翻新的技术可能推动或者发明一种新的业务，其余状况下，都是业务的倒退推动了技术的倒退。
技术演进的模式
明确了技术倒退次要的驱动力是业务倒退后，咱们来看看业务倒退到底是如何驱动技术倒退的。
业务模式千差万别，有互联网的业务（淘宝、微信等），有金融的业务（中国安全、招商银行等），有传统企业的业务（各色 ERP 对应的业务）等，但无论什么模式的业务，如果业务的倒退须要技术同步倒退进行撑持，无一例外是因为业务“复杂度”的回升，导致原有的技术无奈撑持。
依照专栏后面所介绍的复杂度分类，复杂度要么来源于性能一直叠加，要么来源于规模扩充，从而对性能和可用性有了更高的要求。既然如此，判断到底是什么复杂度产生了变动就显得至关重要了。是任何时候都要同时思考性能复杂度和规模复杂度吗？还是有时候思考性能复杂度，有时候思考规模复杂度？还是随机挑一个复杂度的问题解决就能够了？
所以，对于架构师来说，判断业务以后和接下来一段时间的次要复杂度是什么就十分要害。判断不精确就会导致投入大量的人力和工夫做了对业务没有作用的事件，判断精确就可能做到技术推动业务更加疾速倒退。那架构师具体应该依照什么规范来判断呢？
答案就是基于业务倒退阶段进行判断，这也是为什么架构师必须具备业务理解能力的起因。不同的行业业务倒退门路、轨迹、模式不一样，架构师必须可能基于行业倒退和企业本身状况做出精确判断。
假如你是一个银行 IT 零碎的架构师：
90 年代次要的业务复杂度可能就是银行业务范畴逐步扩充，性能越来越简单，导致外部零碎数量越来越多，单个零碎性能越来越简单。
2004 年当前次要的复杂度就是银行业务从柜台转向网上银行，网上银行的稳定性、安全性、易用性是次要的复杂度，这些复杂度次要由银行 IT 零碎本人解决。
2009 年当前次要的复杂度又变动为挪动领取复杂度，尤其是“双 11”这种海量领取申请的状况下，高性能、稳定性、安全性是次要的复杂度，而这些复杂度须要银行和挪动领取服务商（支付宝、微信）等一起解决。
而如果你是淘宝这种互联网业务的架构师，业务倒退又会是另外一种模式：
- 2003 年，业务刚刚创建，次要的复杂度体现为如何能力疾速开发各种需要，淘宝团队采取的是买了一个 PHP 写的零碎来改。
- 2004 年，上线后业务倒退迅速，用户申请数量大大增加，次要的复杂度体现为如何能力保证系统的性能，淘宝的团队采取的是用 Oracle 取代 MySQL。
- 用户数量再次减少，次要的复杂度还是性能和稳定性，淘宝的团队采取的是 Java 替换 PHP。
- 2005 年，用户数量持续减少，次要的复杂度体现为繁多的 Oracle 库曾经无奈满足性能要求，于是进行了分库分表、读写拆散、缓存等优化。
- 2008 年，淘宝的商品数量在 1 亿以上，PV2.5 亿以上，次要的复杂度又变成了零碎外部耦合，交易和商品耦合在一起，领取的时候又和支付宝强耦合，整个零碎逻辑简单，性能之间跳来跳去，用户体验也不好。淘宝的团队采取的是零碎解耦，将交易中心、类目治理、用户核心从原来大一统的零碎外面拆分进去。
小结
明天我为你讲了架构师该如何判断技术演进的方向，心愿对你有所帮忙。
留一道思考题给你吧，如果业界曾经有了一个显著的参照对象（例如电商企业能够参考淘宝），那架构师是否还须要依照步骤逐渐演进，还是间接将架构一步到位设计好？
欢送你把答案写到留言区，和我一起探讨。置信通过深度思考的答复，也会让你对常识的了解更加粗浅。