最近几年，中台之风盛行，各行各业都希望能建设自己的”大中台，小前台“，期望能够通过强大中台的复用能力快速的赋能业务，让新业务可以快速试错，降低整体成本，但是实践下来发现困难重重。刚好最近在参与一个跨域功能点的复用开发，借此梳理下软件架构中复用的一种路径。
最开始不同业务为了快速成长，一般都是在各自的系统中开发，例如三个电商业务A、B、C会有各自的交易、支付、商品等完整的电商系统。
各自生长
随着公司的发展，发现各个业务之间有很多公共的特性，如果还是在各自系统中单独实现，不利于能力的复用与沉淀，另外还有一些其他因素的考虑（例如打造公司生态系统，打通不同业务线的数据壁垒），于是慢慢将公共的功能抽取出来形成了底层平台，例如交易平台，支付平台。
平台型
平台型解决了复用了问题，但是却面临了扩展（定制）的问题，每个业务之间都存在不同的玩法，业务逻辑存在较大的差异，例如业务A在计算订单金额时需要增加费用PA1，于是A在生成订单的接口中增加了一个额外费用的参数PA1。
金额计算逻辑
随着业务的发展，业务A中对于金额的计算发生了变化，增加的金额变成了2*PA1，但是当业务方开发修改时，不敢直接在之前的定制逻辑中修改，因为不知道参数PA1到底被多少业务方使用了（很可能业务方B也使用了这个参数），因此这个时候往往再增加一个参数或者增加一层判断。
定制增加后的金额计算
底层平台中的各种定制点越来越多，逻辑越来越复杂，很难有人能够通过代码就知道业务流程是如何运行的，在新增需求时，只能通过不断的增加补丁的方式来实现，原来的代码没人敢改动。结果就是中台的响应越来越慢，效能越来越低，低效贯穿了整个研发过程，包括需求评审与设计（无法准确评估系统的样子，只能先去试试看），功能开发，测试（随便一些小改动都需要大量回归验证，以免影响到其他业务），发布以及线上维护。
了解设计模式的都知道可以通过策略模式来将不同的定制逻辑放到专属的地方，但是这样只是代码结构好看些，问题的关键是定制逻辑没有统一的判断逻辑，无法知道某个业务方会使用哪种策略。为了解决这个问题，于是引入了统一判断逻辑：业务身份。为每个业务方分配一个业务身份，并且强制所有定制逻辑都必须根据身份来区分差异，并且将差异放到每个业务的专属地方，业务方只能修改专属代码。
金额计算业务定制
将所有的业务方的订正逻辑都放置到业务的专属代码块中就形成了下面的结构。
具有定制功能的平台
重构之后的平台难点在于如何制定定制点，如果定制点的粒度太大，把整个金额计算逻辑全部扔给业务方定制，就失去了平台的功能，没有了复用的价值，如果定制点粒度太小，对于业务方开发来说理解成本较大，看到的都是一个个离散的点，无法感知整体逻辑。
为了实现功能的复用以及扩展点过多的问题，于是在业务定制上面增加不同场景下默认实现，例如业务A与业务C都支持红包，那么A与C中就需要定制一份与红包相关的逻辑，这里红包的逻辑就可以当成一个默认往上抽取一层，然后基于这个默认实现再制定业务定制点，业务A与业务C修改这层默认定制点就好了。
具有定制以及复用沉淀的平台
系统到这个阶段已经越来越复杂了，业务混乱的问题解决了，被隔离到了业务自己的代码块中了，但是系统本身层次的增加，对于代码的阅读与理解带来了很大的成本，代码的流程不断在不同的层级之间切换，模型也不断的转换，跟操作系统中的系统调用一样，第一次看完第二次基本也不记得了，而对于业务方来说定制点的理解也是只知其一不知其二，万一不幸现有的定制点不能满足业务述求，那更是伤筋动骨。
对于复用与定制本来就是一个平衡与取舍，如果提供的是大而全的功能，就会给定制带来困难，上面的平台解决方案就是基于这种模型，在对外大接口下不断寻求定制的方案，同时也要能尽量的提高复用度；另外一种方案就是提供原子能力，然后根据需求去进行组装，然后再根据业务的共性进行沉淀。
自上而下的业务定制
复用与扩展虽然很难，但是值得探索，去找到一条可以快速支撑业务以及减少资源投入的解决方案。
网友评论