技术演进的模式：基于业务发展阶段判断当前主要复杂度

明确[[技术演进的动力：产品类靠技术推动业务，服务类靠业务推动技术]]之后，具体该往什么方向演进技术，答案落在”复杂度”上——不管业务模式是互联网、金融还是传统企业，业务发展到需要技术同步跟进支撑的时候，无一例外是因为业务复杂度上升到原有技术撑不住的地步了，复杂度要么来自功能不断叠加，要么来自规模扩大带来的性能和可用性要求。架构师真正的核心能力就是准确判断”业务当前和接下来一段时间内，主要的复杂度到底是什么”——判断错了，投入大量人力和时间去做对业务其实没用的事；判断准了，技术就能真正推动业务加速发展。判断的标准是基于业务发展阶段来看，而不同行业的业务发展路径、轨迹、模式完全不一样，这也是为什么架构师必须具备业务理解能力，不能脱离行业发展和企业自身实际情况凭空判断。以银行IT系统为例：90年代主要复杂度是业务范围不断扩大、功能越来越复杂，导致内部系统数量激增、单个系统功能也越来越复杂；2004年以后主要复杂度变成从柜台转向网上银行，稳定性、安全性、易用性成了核心问题，这些复杂度基本由银行自己的IT系统解决；2009年以后主要复杂度又变成移动支付相关的复杂度，尤其是”双11”这种海量并发支付场景，高性能、稳定性、安全性成了主要挑战，而且这类复杂度需要银行和支付宝、微信这类移动支付服务商一起协作解决，不再是单一机构能独自搞定的。以淘宝为例，路径完全不同：2003年创立初期，主要复杂度是”如何快速开发满足各种需求”，团队选择直接买一个PHP系统来改；2004年上线后用户请求量激增，主要复杂度变成”如何保证系统性能”，团队用Oracle替代MySQL；用户继续增长，性能和稳定性依然是主要复杂度，团队又用Java替代PHP；2005年单一Oracle库撑不住性能要求，做了分库分表、读写分离、缓存这些优化；到2008年商品数超1亿、PV超2.5亿，主要复杂度变成系统内部过度耦合（交易和商品耦合、支付时又和支付宝强耦合，逻辑复杂、用户体验也差），团队因此做了系统解耦，把交易中心、类目管理、用户中心从原来大一统的系统里拆分出来。这两个案例说明：同一个”复杂度”框架下，不同企业、不同发展阶段，主要矛盾点会完全不同，架构师的价值正体现在能否在每个阶段准确抓住那个真正制约业务的复杂度，而不是照搬别的企业当下正在用的技术。