38 | 架构师应该如何判断技术演进的方向？

Jul 24, 2018

38 | 架构师应该如何判断技术演进的方向？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

38 | 架构师应该如何判断技术演进的方向？

2018-07-24 李运华来自北京

《从0开始学架构》

课程介绍



讲述：黄洲君

时长15:20大小7.02M



互联网的出现不但改变了普通人的生活方式，同时也促进了技术圈的快速发展和开放。在开源和分享两股力量的推动下，最近 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 亿以上，主要的复杂度又变成了系统内部耦合，交易和商品耦合在一起，支付的时候又和支付宝强耦合，整个系统逻辑复杂，功能之间跳来跳去，用户体验也不好。淘宝的团队采取的是系统解耦，将交易中心、类目管理、用户中心从原来大一统的系统里面拆分出来。
小结今天我为你讲了架构师该如何判断技术演进的方向，希望对你有所帮助。
这就是今天的全部内容，留一道思考题给你吧，如果业界已经有了一个明显的参照对象（例如电商企业可以参考淘宝），那架构师是否还需要按照步骤逐步演进，还是直接将架构一步到位设计好？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。（编辑乱入：精彩的留言有机会获得丰厚福利哦！）

分享给需要的人，Ta购买本课程，你将得20元

生成海报并分享

赞 27

提建议

37 | 微内核架构详解

39 | 互联网技术演进的模式

 写留言

精选留言(55)

无问。
2018-07-24
成熟的架构演进和案例当然是可以借鉴的，相信有不少架构师都读过淘宝技术十年。但是如果说参照他人的架构演进，将自己的架构一步设计到位我觉得这本身就是个伪命题。为什么？ 1.首先淘宝自己的架构是在持续的演进中的，可能技术的变革、业务的创新、硬件性能的提升等都会迫使架构产生变化，没有所谓最优解。 2.技术和架构是不能脱离业务来谈的，否则我们怎么去衡量它们的价值和收益呢。世界上没有两片相同的叶子，淘宝的业务在结构、体量和形态上往往和很多企业有很大的差异。 3.针对于架构实践，另一个不能避免问题就是，管理和成本。不同的架构设计解决问题的广度和深度不同，相应的带来的管理复杂度和人力物力的成本也不同。那具体该怎么做呢？我的理解是 1.结合激进、保守、跟风，作为架构的实践者，必须及时跟进新的技术体系，同时需要慎重考虑引入新的内容，要想清楚它的必要性、能在短期带来的什么收益、能解决什么问题，同时还需要以观察者的角度来看业界大厂的实践，同时思考他们为什么要这么做，对于我们以后改进设计很有帮助 2.对于架构演进来说是有成本的，在准备改变之前还要想明白的一个事就是这么做的成本是什么，会给我们带来什么样的收益，当前的团队规模是否能稳定驾驭
展开
作者回复: 赞同👍
共 7 条评论
148
铃兰Neko
2018-07-24
我感觉要分情况讨论,但是本质上还是要符合 "合适" "简单" "演进" 原则的. 假设淘宝目前的架构是 100 分. A : 假设是一个量级也是很大的电商 (比如苏宁,京东) : 初始的阶段和要求就很高 ,可能一上线就有大量用户 , 建议参考淘宝的架构 , 至少达到60分. 不用一步到位, 但是要有大部分基础功能 (比如肯定要有缓存, 要服务化, 肯定要上docker , 肯定要有基础的微服务组件, 订单系统 , 用户系统至少先做的能够支持一段时间的用户增长 ; 但是可以不用自研, 先使用开源 ) B : 假设是一个量级较小的小网站. 这个就不建议一步到位, 没人没钱搞这个; 能达到淘宝的20分可能都够用. 可以根据人力,时间,机器等资源 . 解决当前的最大矛盾: 可能就是先上一版初版, 效果好后续慢慢演进 . 效果不好没有用户, 那以后人都没有了也就不用演进了. 😂
展开
作者回复: 分析到位，大公司和创业公司做法不同，例如传统的苏宁国美沃尔玛要从线下转线上，第一版电商网站确实可以参考淘宝当前架构，但也不是完全照搬，你说的60分非常到位👍👍
48
李二木
2018-07-28
最近遇到一个现实的架构设计，本来一个业务不多系统却要上微服务架构，项目经理解释说不弄点流行技术，公司就少投钱。这就是现实啊😄
作者回复: 理解，面向升职的架构设计😂
共 7 条评论
38
zhngbin
2018-07-24
请问下画架构图用什么软件的？
作者回复: libre office draw
12
今夕是何年
2018-07-25
选择什么样的架构和看病一样要对症下药。首先要预估业务规模和系统1.0上线后，系统的并发量，以略高于预估的并发量来设计，否则，系统一上线，用户来访问，分分钟挂掉，对业务是莫大的损失，又丢用户又丢技术人员的脸。系统上线后，关注系统的压力，并探讨用户数到下一个量级，架构和技术要如何支撑为课题，综合技术团队的技术水平和技术团队规模能驾驭的架构来做选择。涉及到新技术的，要尽早去学习试错，以期用时能淡定从容应对。
展开
作者回复: 正解👍
9
narry
2018-07-24
觉得还是应该按演进的思想来，先根据业务发展阶段选择合适的架构，业界的案例可以作为演进的方向
作者回复: 演进的原则没错，不要一步到位，但要考虑是从20分开始演进还是从60分开始演进，大公司例如苏宁国美可以从60分演进，小公司可以从20分演进
8
9527
2018-07-25
像浏览器这样的产品，使用规模还是会影响用户选择的，假如我有一个更好的浏览器ud浏览器但如果周边的人都用uc，网上也推荐用uc，那可能用户就选择uc了，这个还是“规模”作用啊还有打车软件，比如我自己不但提供软件可以打车，而且自己也提供车，用户会因为我提供的车更专业选择我的，也会因为这个软件的“规模”选择我的也就是说该如何严格确定，一个东西到底是产品，还是服务呢？
展开
作者回复: 服务就是别人用你才能用，例如微信，我用米聊就没法和我的朋友聊天了，除非他们都切换米聊产品就是工具，我不管别人用不用我都可以用，我用opera浏览器不影响我上网
共 4 条评论
7
问题究竟系边度
2018-07-24
有成熟的架构参考。在一定程度上，可以预知以后系统变大后，可能要做一些什么,还有大体的逻辑结构会怎么样，因为这是通过检验的。但是业务上并不完全一致的情况下和体量不一样的情况下，详细的设计还是需要结合实际去做的。
作者回复: 赞同👍
5
张立春
2018-07-24
一个企业的技术架构是随着业务发展逐渐演化生长出来的绝不可能照抄别人就可以。就像每个人都是独一无二的，拥有不一样的经历和人生。
作者回复: 细节独一无二的，大方向还是可以参考的，例如我们都是程序员，发展路径可以借鉴
4
Alan
2018-07-25
老师后面还有新的专栏吗
作者回复: 暂时没有，写专栏很辛苦的😄
2
艺超(鲁鸣)
2020-11-23
之前团队内的架构师倡导的一句话就是，脱离业务的架构就是耍流氓
作者回复: 很经典，可以加上：脱离团队的架构也是耍流氓
1
魏*_*琛
2020-06-07
好的技术架构是需要借鉴的，如果去根据自己的业务今天调整，直接复用，最后只会时间，金钱的双重丢失。根据实际业务，一定的新的技术需要，良好的架构分享，内部多次的头脑风暴。
1
monalisali
2019-01-21
请教作者，一般的企业级开发的项目应该属于产品类还是服务类呢？我觉得应该属于产品类，因为这种系统虽然不像360这种直接到个人的产品，但是实际使用的还是单个企业内的员工。如果从企业角度来看的话，应该是属于产品比较合适吧
作者回复: 属于产品类，因为是帮助企业解决特定问题的
2
呵呵
2018-08-26
看到“小龙”问的问题，我想知道一个架构已经较为完善的系统，架构师除了做需求分析，把关概要设计，还有什么工作需要做？还有很多公司需求都是被所谓的产品经理包干了，也没有架构师多少事，顶多参与需求评审，这样是否合理？
作者回复: 这就是架构师的悖论：设计好了架构师没事做，没设计好架构师被骂，所以架构师最好不要绑定在一个小业务，太浪费了😀
1
Fisher
2018-07-25
总结起来还是运华老师那几句话，按照企业当前的业务发展阶段衡量当前复杂度，逐步推演，设计合适的架构。如果有对手系统可以参考，企业自身业务能够达到一个高度，老板给时间，就预见性的设计，为后续升级留出通路。
作者回复: 要碰到好老板才行😁
1
小龙
2018-07-24
老师，架构师只需要做技术选型，不需要做需求分析、概要设计、详细设计是吗？
作者回复: 需求分析要做，概要设计要把关，防止偏离架构，详细设计真不需要，再说了，做好架构设计其实很费时间的😄
1
凡凡
2018-07-24
首先，参考和借鉴业内最好的实践经验，架构案例，对于将来的判断和技术准备都有很大的益处，也可以少踩一些坑，也能让后续的演进顺利和省心很多，淘宝技术十年再来一打。另外，需要综合考虑，看业务发展，看资源，看团队情况。如果团队很小，资源需要一步一步积累，自然要逐步演进。对于特别有经验和有未来野心的团队，可以直接上手高级阶段，尤其是对于公司基础设施比较完备的大型公司，很多资源已经云化了，实现起来比较容易。之前创业的时候，研究过网易的网易美学，自打上线就是拆分完备的系统了，如何呢？团队实力，老板支持力，妥妥的没有压力
展开
作者回复: 是的，小公司从20分开始演进，大公司可以从60分开始演进
1
feifei
2018-07-24
如果业界已经有了一个明显的参照对象（例如电商企业可以参考淘宝），那架构师是否还需要按照步骤逐步演进，还是直接将架构一步到位设计好？这个肯定是逐步的演进，比如新上线的一个小电商网站，主要服务对象是某地区的用户，业界的淘宝已经有现有的架构，能按照淘宝的模式照搬吗？答案是肯定不行 1，业务的规模达不到淘宝的规模，照搬只会浪费大量的人力投入，而且过亿级别的系统开发所需的开发，非普通的开发能够完成，人力成本非常高。 2，淘宝的服务用户数已达到亿级别，刚成立的小电商肯定没有这么大的用户数，照搬只会造成资源的大量投入，硬件成本非常高 3，初创时期是快速业务上线，照搬会造成业务上线时间长。以上就是我的理解，欢迎指正，谢谢
展开
作者回复: 小公司可以这样做，大公司可以直接参考，例如国美苏宁沃尔玛做自己的电商网站
1
小名叫大明
2018-07-24
我是一个架构小白，根据之前的学习，架构不是设计出来的，是一步一步演进出来的，哪有一步到位的架构。
作者回复: 不一定一步到位，前面有位同学说的很好，淘宝100分，苏宁国美沃尔玛做电商网站可以做到60分，小公司可能做到20分就可以了
1
月光宫羽
2022-11-23 来自广东
业界有明显的参考对象，并不能代表成功是可以复制的。作为架构师，应当审时度势，更全面的分析当下业务需求和可预测的业务发展规模，做适合自己公司的架构，而不是盲目跟风，追求潮流，拿来主义、生搬硬套。因为企业是发展的，它有它的发展路径。比如：创业期，增长期、竞争期、成熟期，各个时期规模不一样，技术需要支撑业务，所以架构是需要逐步演进的。至于是否需要将架构一步到位设计好，只能是看情况定。为什么呢？假如我预测服务的规模在5年后，可达5k个，如果提前一步将架构设计到位，相应的人力、物力，技术支撑也是线性增长的，但未来是变化的，有可能发展好，也有可能发展的一般，超前的预算支出，成本是巨大的，为了不浪费和适合才是最好的。至于什么时候需要演进？主动模式下的业务规模质的改变（稳定的），需要考虑10倍体量或系统支持的业务类型变多了（明显的）；被动模式下的业务方向改变了，业务跨界了。新东方不做教培，直播带货了。
展开
作者回复: 总结和梳理非常到位，点赞

