竞争期系统数量质变的两个问题，及平台化、服务化应对

承接[[优化期”优化派”与”架构派”之争，及架构期”拆”字诀的三个方向]]，业务发展到一定规模后必然会引来竞争对手，大家互相学习模仿、催生更多新业务创新，同时竞争压力也把技术要求推上一个新台阶。新业务创新意味着更多新系统，架构拆分又让原有系统越拆越多，两股力量叠加，系统数量在原有基础上进一步暴增，好不容易靠拆分换来的”快”又开始变”慢”——这背后是系统数量的量变到了临界点、引发了技术工作的质变，具体表现在两方面。一是”重复造轮子”：系统越来越多，各系统需要处理的相似问题也越来越多（每个系统都要存储、都要缓存、都要数据库），新建一个系统，这些基础工作又要重新做一遍，即使别的系统早就做过，也没法直接复用，速度自然快不起来。二是”系统交互一团乱麻”：系统之间的交互关系变成网状结构，交互数量和系统数量呈平方比关系（4个系统交互路径是6条，10个系统就变成45条），实现一个业务需求往往要同时改好几个甚至十几个系统、还要处理它们之间层层调用，联调成了研发的灾难、联测成了测试的灾难、部署成了运维的灾难。针对这两个问题，技术上主要的应对手段是平台化和服务化。平台化专门解决”重复造轮子”：把通用的基础能力沉淀成统一平台，比如存储平台化（淘宝TFS、京东JFS）、数据库平台化（百度DBProxy、淘宝TDDL）、缓存平台化（Twitter Twemproxy、豆瓣BeansDB、腾讯TTC），让新系统直接复用这些平台能力，不用每次都从零造轮子。服务化专门解决”系统交互混乱”：常见做法是用消息队列完成系统间的异步通知（淘宝Notify/MetaQ，开源Kafka/ActiveMQ），用服务框架完成系统间的同步调用（Facebook thrift、当当Dubbox、淘宝HSF），把原本网状的点对点调用收敛成有规范的通信方式。

结构图：

flowchart TB
  A["竞争期：新业务创新+架构拆分<br/>共同导致系统数量再度暴增"]
  A --> B["问题①重复造轮子<br/>各系统重复处理存储/缓存/数据库等基础工作"]
  A --> C["问题②系统交互一团乱麻<br/>交互数量随系统数呈平方增长(N系统≈N(N-1)/2条交互)"]
  B --> D["应对：平台化<br/>存储平台化(TFS/JFS)<br/>数据库平台化(DBProxy/TDDL)<br/>缓存平台化(Twemproxy/BeansDB/TTC)"]
  C --> E["应对：服务化<br/>消息队列做异步通知(Notify/Kafka)<br/>服务框架做同步调用(thrift/Dubbox/HSF)"]