你好，我是前台，但请不要误会，我是前台不代表我只是个前端，我是一个包含后端服务和前端应用的前台，只是我距离业务比较近，所以公司的人都把我们叫做了前台。
都说了我距离业务比较近，那我当然要快速响应业务，去及时的实现需求，响应需求的变化，消费者的需求实在多变。
而且，在这样的变化频率中，我还要能够做到试错的成本，要低。
对，我要的是变化，而且是成本低的那种变化。
怎么办。
你好，我是后台，公司的ERP、WMS、CRM都在我这里，当然，现在的互联网企业中，订单服务、商品服务、用户服务等等，也都在我的地盘里。
我不想随着前台的变化而变化，前台变自己的，我不想随意的调整，因为，我一动，有时候影响面就非常大，成本也高。
我就想保持我自己的业务流程稳定。
对，我要的是稳定。
怎么办。
小插曲1：
有一天，前台找到了后台，商量一下，让后台给前台提供接口，有个手机的促销活动，需要短时间上线，于是后台给前台封装了一个接口。
没过多久，前台又来找后台，这次还是个促销活动，商品变成了电视，而且规则也变了，后台再次给前台封装了一个接口。
又没几日，前台再次找到后台，上次做的手机促销的相关接口，我要改变下，你能否支持支持。好了，后台突然说，我知道了，我们不能这样下去了，你的变化太频繁。
小插曲2：
小王在一家电商公司做程序员，先是在主站，亲身经历了商品的搜索、购物车、下单、支付流程的开发。
后来公司拓展线上业务，开辟了一个新的业务场景，采用了小程序的方式来为C端用户提供服务。
小王得知后，很是感兴趣，申请异动到了新的业务部门。
来到新的岗位的小王，在过了一段时间之后，发现这里的流程仍然是商品搜索、购物车、下单、支付。
于是，小王跟着团队又走了一遍类似的流程开发。
突然，小王意识到，不能这样，如果公司再发展一个类似的业务线，岂不是要又来一遭。
你好，我是中台。
你要效率，他要稳定，那么我在思考，我应该怎样帮助你们呢。
首先，我想到了如果要提高前台效率，是不是可以复用一些业务场景，比如下单流程，这样不同的业务来了，基础的下单流程是不变的。
那么，后台，你是不是就需要来抽象一下，有哪些通用的，共享性的服务可以提供出来。
然后，由我来把这些通用的服务横穿起来，这样的话，我觉得我能帮助你们，来实现平滑的对接。
“人”到齐，开始对话。
后台：我想了下，中台的建议很好，基础的业务数量，毕竟，还是有限的，我觉得可以让这些有限的，而且相对固定的业务作为基础。
前台：我是距离业务形态最近的地方，上层的业务场景是相对多变的，我肯定希望后台你能够将那些通用的基础业务，进行平台化，然后来支持我。
中台：是的，我就想收敛一些业务场景，来统一这些业务规则，把后台的这些业务抽象封装一些，然后，对外提供标准化的接口。通过有限的且固定的基础业务，来满足无限的且快速变化的前台业务场景。
前台、后台：那我们开始干吧。
中台：哈，我已经有了方案。
开始执行。
稍等，如果，我是说如果，后台系统首先已经微服务了。
这样，执行起来就稍微轻松些。
什么逻辑，为什么就轻松些了，松散的微服务->共享服务体系->中台，就是这样的逻辑，中台是微服务的升级。
互联网企业大多都已经实现了微服务化，象上面提到的订单服务、商品服务、用户服务，升级到中台之后就是订单中心、商品中心、用户中心。
不就是变了个名字吗？
当然不是，中心强调了体系化，有更好的业务通用能力，更好的系统运营能力，更好的业务运营能力。
咋实现的。
路子：模块化->规范化->接口化。
对于原来嵌入某个具体业务的模块，对其中的特殊部分（也就是原有的业务信息）进行剥离，使其变成一个公共的模块并且与原有业务没有任何关系，形成模块。
将剥离出来的模块与之前调用的业务线进行内部统一，使其变为多条业务线在操作同一事物。同一事物的名称、属性都能保持一致，形成规范。
通过对剥离出来的模块进行设计，使其拥有接收外部输入信息与向外传送该模块计算结果的接口，形成接口。
哦，就是这个道理。
为不同的前台业务提供可以重复使用的能力，形成一次建设、多次使用的效果。
向前台业务提供服务共享，更好地支持前台业务方快速地响应用户需求。同时，降低软件开发的边际成本，最大化开发人员的生产力，最小化系统的运营总成本。
后传。
有一天，前台想了下，我要把我的后端服务给扔出去，我只想轻松上阵，就玩JavScript、H5、Android和Ios，可以不。
那后端服务该扔到哪里去呢，哦，可以，那是BFF。
前台，后台都不想增加自己的成本，那么成本会凭空的消失吗，不会。
只会转移，去转移到一个“甘心情愿”接收这个成本的地方去，但是呢，这个地方也不是时刻都在增加成本，它是一次性的建设成本，以后前台、后台都来复用它。
再后传。
任何事情都可以从微观和宏观两个方面来考虑。
比如复用这件事。
先说微观上
在一个程序里面的时候，我说的这个程序是运行在一个进程中的。
比如，有同学写了一个计算时间的方法，给定一个日期和变量，就能给你算出来任意一个日期，这位同学把这个方法封装在了一个类里面。
其他同学都在使用这个类，这就是复用。
写这个类的同学，把这个类打成了一个jar包，其他同学通过maven来下载使用，这是更好的复用。
再说宏观上
有一个同学，在系统A里面，写了一个查询订单的模块，给定一个用户和日期，就能给你返回这个用户的订单信息列表，这位同学把这个功能封装成了一个API接口。
维护其它系统E、F、G的同学都在通过这个API来请求订单数据，这是跨进程的复用。
微观，进程内，宏观，进程间。
中台在哪里
先别急，来看个例子，《中台产品经理宝典》一书中，有这样一个形象的例子。
说一个客流量非常大的餐厅，有3名厨师来负责买菜做菜，如何来解决缩短客人等餐的时间呢。
很多人第一想到的就是增加厨师，可是，餐厅也不是24小时，客流量都大，只有中午和晚上是高峰期。
这样，岂不浪费。
仔细分析了一下，将做菜的的任务进行拆分，做菜的流程：买菜-配菜（洗、切、配）-做菜。
于是，餐厅将买菜和配菜，来单独找了一个小师傅负责。
这里的小师傅做的事情，买菜、配菜便成为了复用。
当我们说中台在哪里，实际上，更想说的是中台思想在哪里。
就是复用的思想。
再回到，开始不久的地方，那位同学写的查询订单的API。当PC用到订单查询的时候，当移动APP用到订单查询的时候，当其它新业务场景用到订单查询的时候。
都可以使用订单查询API。
这个这个能力，查询订单的能力，复用给N多平台或者业务，这就是中台的思想。
是的，中台是一个词，更是一种方法论，是一种架构的思想。
中台的核心本质就是向前台提供共享服务，目标是更好地支持前台业务方进行规模化创新，从而更好的响应市场需求。
部分参考资料：
极客时间.王庆友.可扩展的架构案例（三）：你真的需要一个中台吗？
《中台产品经理宝典》
文图来自网络