本篇文章是对前两篇设想文章商户中台解决方案以及解决方案编排架构 的落地，标题暂时还叫中台吧，随着对业务更深入的理解以及在和集团中台的合作上对这个名词又有了新的认知，有些排斥这个概念。
背景
B端业务和C端业务有很大的不同，C端重点关注用户体验、用户规模、转化以及创新功能，B端更关注在工作流程、业务支撑。从技术上来看给我们研发同学带来的挑战也有相当大的差异，C端更偏高并发等流量场景以及页面会场的快速搭建能力，用来支撑快速多变的创新玩法。B端则是需要解决复杂业务场景以及冗长的业务流程对研发带来的冲击。
下图是个大商家概念模型，从线下的POI兴趣点到不同渠道的线上门店，在整个业务场景中贯穿了这么多概念。
主流程扩展
上面的模型里面隐藏了整个供给流程，在这个流程里面我们需要支撑不同业务方的各种定制需求，比如：新零售的资质审核和餐饮的审核就有很大差异。我们除了承接新零售的需求，还有很多业务方。每个业务方在不同环节都会有不同的定制。
如果是一块代码块的话，大家很容易想到使用策略模式，把易变的逻辑通过接口提炼出来，各自实现自己的业务逻辑。我们的现状首先是供给流程跨了多个应用，定制的逻辑散落在各个应用里面，由我们餐饮业务的研发负责开发其他业务的定制逻辑。这就带来了两个问题，一是业务逻辑虽然通过策略模式能够在应用级别上做隔离，但没有做到应用级别隔离；二是其他业务的逻辑由同批研发开发，其他业务研发只能干等，成为瓶颈。
后来验证了内部soa服务路由重新配置能力，在拉取路由配置的阶段可以重新定制，这就有了我们下面的想法，基于soa接口的多态调用。
基于这个设想，我们搭建了SPI路由配置台，不同的业务可在这个配置台上申请场景code以及需要扩展接口，并且把场景code和由各业务研发自行实现的soa服务做绑定。具体运行时架构可以参考下图。
此外我们还给增强了这个配置台的能力，包括整体业务逻辑的表达，能够扩展的扩展点介绍。我们给这个平台起了个名字：fishbone，fishbone一般用来分析问题的因果关系，对技术平台来说整个骨架代表着我们的平台业务，分叉的鱼刺则表示每个业务的扩展。
多流程扩展
除了一个供给主流程外，在业务的日常工作中以及B端的业务流程中，还有很多其他流程在复用不同的服务能力。这很难不让人想起使用工作流引擎来解决该类问题，这里我们对比了一些工作流引擎，挑了个很轻量的开源的工作流引擎，支持bpmn2.0，在此基础上扩展了扩应用调用的能力，每个task节点都可以是一个soa服务。
总结
所以基于上述的两类场景，整体架构如下图，fishbone解决主流程多扩展问题，流程中心解决多流程问题。
