大家好，我是烟花易冷。
App应用早已渗透到了我们生活的每个角落。这两年我一直在思考一个问题：App应用有什么共性? 在开发过程中能否利用这些共性极大提高开发的效率？笔者经过了不断的摸索与实践，沉淀了一套乐高业务中台架构跟大家分享。本文不涉及到技术细节，尽量以"通俗易懂"的表达照顾到每一位读者。
1. 思想的起源 ------ "活字印刷术"
唐朝为了解决大量书籍抄写费时的问题，发明了"雕版印刷"；其工作流程是：工人用刀具雕刻雕版，然后将墨汁刷在雕版上，将白纸覆盖在雕版上用刷子轻轻地刷一遍，这样就印刷好了一页字，如此反复下去，将书页装订成册，一本书籍就印刷成功了。
"雕版印刷"的缺点是显而易见的：每本书都会有书页大小、字体类型与排列、文字内容上的不同，这也就意味着要将每本书的每一页都制作成雕版才能够进行印刷。假如书本的某一页雕版上出现了一个错别字，就需要重新制作新的雕版。"雕版印刷"虽然解决了大量书籍抄写费时的问题，但仍然存在很大的局限性。
活字印刷术应运而生。其工作原理如下：首先制作字模，将要印刷书本上的单字都挑选出来，制作成"活泥字"；然后根据要印刷书本的大小和内容，将活泥字一个个的挑选出来，排列好放进框内制作好版型，再然后就跟"雕版印刷"没有差别了，印刷书本的每一页，装订成册。事后从雕版上取下活字，留着下次印刷备用。
很显然，活字印刷术避免了雕版印刷的不足，在印刷之前只要准备好充足的活泥字，就可以随时进行排版，制版的时间大幅度加快，取下的活泥字也可以重复循环的使用。
对应到App应用上来讲，如果我们将微博、淘宝、小红书等等这些App看作一本书的话，这些App也是由一个个页面组成的，我们也可以像活字印刷术一样，将App页面拆分成像"活泥字"一样的一个个卡片组件，乐高式的组装这些卡片组件来构建App页面，从而实现App的快速迭代开发，这就是本文要给大家分享的"App乐高业务中台架构设计"的核心思想。
App页面的构建远比使用"活字印刷术"印刷书本要复杂的多，App页面中的内容是动态的，卡片内容存在交互，更加复杂的还有App千人千面的实现，卡片与卡片之间还可能存在用户状态和数据的共享，本文以最简单的情况展开。
2. 中台的思考
2.1 中台的产生
在"中台"没有出现以前，App的开发都是基于"前台+后台"架构开发的。前台是系统的前端平台，是直接与终端用户进行交互的应用层。后台是指系统的后端服务，终端用户感知不到他的存在，后台服务存储和计算企业的核心数据提供给前台。随着业务的发展，前台需要进行快速迭代，而后台服务则需要保证稳定和安全，前端的快速迭代又依赖后台服务的快速响应，为了解决这个矛盾，中台应运而生。中台一般应用于大型企业，一般指搭建一个灵活快速应对变化的架构，快速实现前端提的需求，避免重复建设，达到提高工作效率的目的。
2.2 中台的价值
根据上一小节对中台的介绍，我总结出中台具备的几点价值：
- 实现通用能力的复用，不重复造轮子。
- 易拓展，不断沉淀通用能力。
- 灵活的整合现有的能力，快速满足业务需求。
"中台"并不是银弹，不是所有的业务都适合建设中台架构。业务中台架构的建设更是困难，需要结合具体的业务做深入思考，很多"业务中台"都因为过度设计导致灵活性差或偏离业务而以失败告终。本文所讲的App乐高业务中台架构具备很高的普适性，读者可以结合各类App思考。
3. 乐高式业务中台架构设计
3.1 卡片组件
我们前边说到了"活字印刷术"，它的灵魂就在于"活泥字"，因为有了"活泥字"，印刷书本这样的工作就可以理解为"活泥字"的沉淀、复用与整合了。那么对应到我们的App乐高业务中台架构设计上来，它的灵魂在于"卡片组件"，只要明确了什么是"卡片组件"，我们的业务中台架构要做的事情就是对"卡片组件"的沉淀、复用与整合了。只要满足以下两个条件就可以作为可复用的"卡片组件"：
- "标准化"的数据协议
- "原子性"的操作API
之所以要实现"标准化"的数据协议，是因为"卡片组件"会被翻译成App页面上的"卡片"，如果想要不同的App页面都能够复用"卡片"，就要有一个统一的规范。就像活字印刷术中的"活泥字"一样，不能奇形怪状的拼凑不到一起去，也不能高低不一。而提供"原子性"的操作API则是保证卡片组件之间的交互没有"依赖"。
3.2 架构设计与概述
以淘宝App服务为例，下边给出的是乐高业务中台架构的设计图，下边对这个架构做一个概述。
我们分为前台、中台、后台三部分介绍，重点关注一下中台部分。
前台是由页面组成，App页面统一由App卡片引擎渲染，前台也是在业务发展过程中需要快速迭代，产生各种各样的交互效果，衍生很多页面。
后台则是我们通常说的服务端，随着业务的发展越来越稳定，比如：商品服务、订单中心服务等，都是后期不怎么发生变化的。但是为了应对前台业务的快速迭代，我们抽出了业务聚合层提供给中台服务调用，业务聚合层是根据业务迭代做一些聚合与定制化服务的开发工作。
乐高中台就是我们本文所讲的，为了快速满足前台业务的迭代，实现通用能力的复用、沉淀和整合。我们第一小节说过，我们将页面看成由卡片组装而成，而卡片里边的数据我们统一称之为"物料"，物料是组成卡片的基本单位，比如：对于金刚卡片来说，每一个金刚就是一个物料，我们需要一个页面 --- 卡片 --- 物料管理关系的配置服务，页面构建引擎服务的功能则是根据配置构建出一张张卡片给前台使用。
那么什么是召回策略引擎呢? 召回策略引擎可以看作是规则引擎，用来标识物料或者卡片在什么条件下出现，什么条件下不出现的一组规则，它是实现千人千面的基础。
总结来说，乐高业务中台就是通过解析页面-卡片-物料的配置，完成服务数据灵活整合的。同时也通过页面-卡片-物料的配置实现了卡片组件的复用和沉淀。更多的技术实现细节，我们下一小节再展开。
4. 乐高业务中台核心模块实现概述
4.1 页面-卡片-物料配置管理
上一小节我们说到了"物料"，我们再来深入了解一下它，物料可以是一段静态数据配置，比如说静态的金刚可以配置成物料：
css
[{ "diamond_img" : "http://xxxx.png", "diamond_text" : "天天特卖", "icon" : ""},{ "diamond_img" : "http://xxxx.png", "diamond_text" : "天猫超市", "icon" : "猫超卡"},......]物料还可以是标识从下游服务请求获取的数据，就像postman一样，配置好以后，页面构建引擎解析这个服务发起rpc请求，就可以从下游获取数据了。比如我们规定下面的配置就是从商品中心获取商品信息的服务(作为feed流的一部分)。
json
{
"build_mode" : "rpc_http",
"server_name" : "good_center",
"router" : "/good/list"
}物料是卡片构建的基本单位，是中台与后台交互的纽带。物料是可以被复用的，也就是物料和卡片的关系是多对多的关系，卡片和页面是一对一的关系，一个卡片只能属于一个页面，卡片组件想要复用可以通过组合相同的物料来实现。
4.2 千人千面 ------ 召回策略引擎
通过给卡片或者物料配置过滤规则，召回策略引擎根据参数和规则进行过滤，召回不同的卡片和物料，卡片构建引擎根据召回的卡片和物料信息构建卡片给前台，就实现了千人千面的效果。
4.3 页面构建引擎的实现
页面构建引擎的实现是根据召回的卡片和物料配置，组合卡片的过程，在这个过程中可能会调用后台获取数据，也可能根据配置对物料进行整合，最终产出的是标准的卡片组件协议给前台渲染。
5. 小结
本文根据中国古代四大发明之一"活字印刷术"，结合"中台"思想，分享了"乐高业务中台"的架构设计。其中页面-卡片-物料的配置管理、召回策略引擎和页面构建引擎每一个模块都是一个庞大的主题，本文只是做了简单的介绍，关于这套架构更复杂的设计细节也都没有展开，本文的目的是从架构设计的全貌和读者分享，希望读者能有所收获。感谢阅读！