【51CTO.com原创稿件】自2009年11月11日起，“双十一”成为了一个盛大的狂欢购物节，一旦提到购物和电商，人们最关注的是GMV（商品交易总额），或者峰值时的压力，反而忽略了此平台拥有多么成熟的技术。
随着双十一的发展，越来越多的“卖家”参与进双十一的活动中，这反而给阿里的技术带来了很大的挑战，双十一的需求数量多，留给开发的时间短，质量要求又高。阿里巴巴业务平台事业部的资深专家余刚老师坦言，如何降低开发的门槛，使每个业务都能自助研发交易平台，来与峰值时的压力抗衡，成为了阿里亟待解决的问题。
《企业门诊》第二期和大家聊聊，交易平台如何能更好的满足业务方，从而提高研发效率。
病症一：开发门槛高
从2009年至2016年，双十一活动已经持续了7年，而阿里的技术也在不断丰富和创新。面对众多的支付业务，阿里选择了各个业务都在同一交易平台上完成的方式。此平台是一个大流程，所有的业务都通过这个流程完成交易，流程上各个业务的定制点写在一起，互相之间通过优先级、组合等关系完成一些业务场景。
一个好的平台，是可以让平台上的用户自助式的完成研发，而不需要依托平台人员的支持才能完成。一旦满足这个要求，平台的门槛就要尽可能的降低。可是与之相反，能够支撑应对各种情况的大型交易平台，流程相对也会庞大、复杂，长此以往就会致使开发门槛变高，业务方无法自助完成研发。面对这相悖的问题，平台应该如何降低开发门槛，成为了***问题。
病症二：开发成本高
为了降低自助平台的开发门槛，就不得不改变原有的离散定制点，其成本之高也成为了一大难题。离散式的定制点，使得每个业务方都要从零开始开发，难以复用，这样下来就引发了两个高成本问题：人工成本和时间成本。
阿里所用的交易平台是流程很复杂的一种模式，要由专门的团队来维护，每个业务方再配置各自的研发团队。因为平台开发门槛高，所以业务方的研发团队需要平台的维护人员支持，才能顺利进行开发。如此反复，过程中就会耗费许多的人工成本。
加之，业务方的定制均混杂在一起，一旦某小业务出错很可能会把非常重要的业务连累。简而言之，流程上的每个业务都写在一起，互相影响牵连，一错均错的模式会耽误众多业务的后续流程，浪费了太多的时间。
当意识到现有交易平台并不能很好的满足业务后，阿里对此进行了一次透彻的剖析。平台一定要降低开发门槛，业务方不用了解全局后再进行开发，只要关注自己应关注的定制点即可。各个业务方的代码也应该是相互隔离的状态，并且平台可以提供面对某一个业务场景的功能包，用来保证如果出现错误，问题方只影响自身业务，避免每个业务都从零开始开发所带来的开发成本问题。
药方：开放性与隔离性
业务能够使用交易平台进行自助开发，这就要求平台具有开放性。以“双十一”为例，参与活动的有数百万商家，每个商家的活动都大同小异，标准化的平台如何做到满足数量如此之多的个性化交易要求呢？如果，向买卖双方提供开放性的在线交易平台，业务方就不需要考虑平台全局，只要关注自己所需的定制点即可完成开发。这样便相当于降低了开发门槛，高效满足了业务的需求。
对于开发成本高的问题，余刚老师则认为，平台一定要具备隔离性。平台可以提供针对不同业务场景的业务包功能，业务包中包含业务的使用场景、业务产品和扩展点的定制，场景由实例构成。系统通过多种信息确定业务的唯一身份，再反馈到相应的业务包完成交易流程。通过这种“私人订制”业务包功能，可以很好的避免业务与业务之间相互牵连的问题，从而提高研发效率，节约开发成本。
总结
对于需要多团队协作的复杂平台，要从平台上所支持的业务方角度出发，如何降低其学习门槛，从而提升研发效率，这就是自助的理念。平台要做好开放性，让业务能开发；做好隔离性，让业务敢开发，同时还要做好沉淀机制，让业务与业务之间能复用更多能力，提升整体的研发效率。
延伸阅读
阿里所使用的解决方案
- 基础能力：通过域来组织交易的基础能力，通过扩展点机制来提供业务方定制的可能
- 业务产品：跨域的定制，最终能完成一个具体业务场景，产品和业务可以直接使用
- 场景：一种具体交易模式的流程定义，场景中可以包括使用的业务产品的声明
- 业务包：由业务方自己开发，业务包中指定了该业务所使用的场景，需要使用的业务产品，以及基础能力中扩展点的定制。每个业务包都有自己的场景实例，系统在请求时通过商品和用户等信息确定唯一的业务身份，路由到相应的业务包进行实现后，根据业务包中指定的场景、产品和扩展点完成业务的交易流程，这样就做到了业务和业务之间的隔离
- 业务运营平台：提供业务声明周期的管理，比如业务创建、配置、下线等
每个层次通过代码中的注解可以自动透出到运营平台，通过运营平台业务方就能看到自己业务选择的场景、使用了哪些产品以及做了哪些定制。这些信息和代码的实现完全一致，如此相当于有了一个动态的文档，从而避免了原来文档更新不及时，人员流动带来的业务逻辑不清晰等问题，与此同时也降低了学习的成本。
***进行测试。人为的准备用例库，难以保障覆盖面，并且各个业务组合时，测试边界并不清晰，线下环境测试的数据也不稳定，对于自动化测试的方法是很困难的。然而线上环境验证又困难，所以对于测试来讲，也有着不小的挑战。
面对测试，阿里认为因为线上数据的场景是最完整的，所以用线上的数据来测试有保障，在利用自动测试，这样也不会对线上产生影响。
最终测试方案，通过线上录制请求，以及系统对外部服务的调用出入参，保存结果后，再线下读取录制结果，系统回放到驱动请求时，在执行过程中对外部服务的调用全部使用mock，且直接返回线上录制再到对应的返回结果，整个过程自动执行，录制的数据可以按照业务、场景等多个维度组织。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
