我15年初加入阿里的前半年，观察到当时的交易平台已经无法很好的对业务进行敏捷支撑：人手不够，加班严重；排期时间很长，经常延期；共建机制，协同困难等问题。本文是在当时背景之下，提出中台概念以及构建TMF2.0框架之前，所记录我观察到的问题和一些初步想法

在早期淘宝网刚建立时，业务比较单一，业务量也较小，一个业务系统、几台机器就可以支撑。在这些机器部署的都是完整的业务功能，如：商品发布、购物车管理、订单管理、订单履行等等。

随着电商的迅猛发展，到2007年团队规模就达到了上千人，每天都有上百个需求需要进行变更与发布。这个时候，就需要把原来单一的系统拆分成多个功能内聚的中心化系统。现在耳闻目详的用户中心，商品中心，交易中心，店铺中心，就是这个阶段出现的。在这种去中心化的分布式架构下，每个独立的系统都可以独立的独立设计、独立承接需求、独立发布，整个研发效率和系统稳定性都上了一个台阶。

但这种分布式架构随着业务的高速发展，业务场景覆盖的行业越来越广，细分应用、微服务如雨后春笋般的大量涌现。截止到目前，整个阿里巴巴集团内针对电商服务已经有超过1万个应用。应用架构复杂到这个程度后，对于业务的支撑也开始面临巨大的问题与挑战。

挑战 1 ： 项目中团队间协同配合效率低下、复杂度高

当支撑一个业务的应用数量达到成千上万这个数量级后。任何一个业务需求，往往都需要上下游多个应用、多个团队协同配合进行需求分析、方案制定、编码实现并经过精密的集成联调后按照一定的先后顺序发布上线，才能完成一个需求的交付。随着时间的推移，已经没有一个人能非常清楚的评估出一个业务需求究竟会涉及到多少个应用、个团队需要一起修改。在一些异常场景、分支场景才会涉及到的应用一旦评估遗漏，就会出现在后期的方案重评、设计返工、进度延迟甚至是项目失败。

挑战 2 ：业务定制是基于应用视角，而不是业务视角

这些功能内聚的各个应用系统，他们在自主演进的过程中也会做一些平台化的工作来应对各种业务场景下的差异化需求。当应用的数量在一定规模内，还可以通过成立一个横向的架构组、业务分析组进行一致性的规范定义与约束。但是，当应用数量超过几百个，这种机制就因为团队间协同配合效率低下、复杂度高的原因开始失效。各个应用系统系统开始野蛮生长。每个应用都在按照自己对“定制场景”的理解来设计各自应用的可扩展机制。负责业务需求实现的开发团队，需要对各个应用能提供什么样的可扩展能力进行熟悉，并还需要了解清楚一个业务需求需要分布在不同应用上的可扩展点如何相互协调配合才能工作。

我们以一个简单的“商品能否添加到购物车”这个需求为例子。某个业务不希望自己的商品通过购物车进行购买，如果从应用视角来看，这个业务需要分别到各个应用上做如下定制：

  • 在商品详情系统中，通过实现该应用对外提供的 “屏蔽展示添加购物车按钮”扩展点，完成该商品在详情页面上不展示“添加到购物车”按钮
  • 虽然屏蔽了商品详情页面上添加到购物车按钮的展现，但从技术上依然是可以通过拼链接、模拟HTTP请求的方式，直接调用购物车对外提供的API接口实现将指定商品添加到购物车中。因此，还需要在购物车系统中，通过实现该应用对外提供的“对商品添加到购物合法性校验”扩展点，防止该业务的商品通过这种途径添加到购物车中
  • 在分布式架构下，订单创建也是由一个独立的应用提供的服务。这个服务同样需要防止第三方黑产通过技术上的拼链接、模拟HTTP请求的方式模拟该业务的购物车方式创建交易订单。因此，我们还需要在交易下单系统中，通过实现该应用对外提供的“对下单合法性校验”扩展点，进行下单渠道的有效性校验
  • ……

从上面这个例子可以看出，针对该业务不允许商品可添加到购物中，原本以为只需要定制一个“是否允许商品添加到购物车”扩展点，但确做了大量的面向应用视角的定制来确保业务逻辑的正确性。这对于业务定制与交付团队是个巨大的挑战，对于业务定制交付团队，他不得不去尝试理解整个电商体系下究竟有多少个应用系统，这些系统对外到底提供了什么样的功能以及这些功能之间有什么潜在的关系？对于一个业务需求开发，需要去仔细的评估这些分散的点之间要如何配合起来，确保逻辑上的完整与严密。

随着业务的高速发展与扩张，一个业务定制交付团队不可能理解与支撑所有行业的定制交付。因此，业务定制交付团队还会进一步按照行业维度进行团队拆分。如果每个业务定制交付团队都需要理解整个电商体系里有多少个应用以及每个应用对外提供的可定制点，这会极大的提高业务定制团队的技能要求。最终，被大量拆分掉的应用与微服务，成为阻碍业务创新、快速迭代的关键。