以下内容是对我自己提出的几个问题的回答：
- 中台的相关概念
- 中台与微服务的关系
- 仅代表个人的，从入职以来对公司业务的理解、架构的不断学习
写在开头
我明白，思考中台，微服务以及架构。对我们这种初级程序员没有什么意义，学而无用。脑子里总是不停的出现类似的话，”要多学点基础知识，linux、https、tcp、计算机原理….”。思考这些狗屁中台的确是80%的无意义。同样我也会因为看了一本烂书而愤愤，浪费了我的时间。但我不能接受一知半解，潦草的对待，抛在一边不管。几年前读完柴静的《看见》，文中写道一段话我感触颇深，我一直记着。原文是这样的：
我采访过一个与女儿有严重隔阂的母亲，她二十几年后反思说：“不论是谁，都不要对别人说‘应该’这两个字”。 “应该”，是一个人认识生活的模式，一旦形成，很难摆脱，对人对事的看法往往是只是一再加强这个模式。 要想完成客观的采访，就要尽力削除这个“应该”，只陈述，只发问，不评判，唯有如此，才能了解更多事实
By the way, 对待有争议的话题时我尽力保持不发声，网络暴力越演愈烈的今天，需要学会不说话。
扯远了，回到学习这个话题，把想做的做完就行了。生活与工作的意义在于不断刷新你认知的上限，或者是下限。
我在做什么——什么是中台？
从入职开始的那天起，部门的架构师和产品经理循循善诱的告诉我：”我们在做中台的项目呀～作为餐饮业最重要的就是菜品啦～这就是我们的数据源“。
那天，我上网搜索了非常多关于中台的文章，一篇篇的看下去，接连不断的Infos OR Knowledge冲击我的大脑。无上的荣誉感净化我的心灵（跳槽可以拿去吹牛了～）
但有一天，随着我真正的开始反思公司的架构，思考中台存在的作用、必要性。我的脑子里不断的出现了疑问。
如果你也对此感兴趣，请往下看：
Q & A
什么是数字化建设？
在介绍中台之前我们先来看看数字化这个概念，什么是数字化？与以前的信息化建设有何不同？
数据的阶段：
阶段一：数据不被存储
软件只为了解决一次性的问题。比如计算机，画图工具，扫雷等等
阶段二：少量的数据被存储和查询
应对业务上的需求，软件从解决单点问题的工具演进到处理一类业务问题，从而有了多个功能模块，这时候有了数据的产生。类比扫雷，添加了用户名、排行榜、通关时间、游戏次数、玩家点击次数等等
阶段三：数据仓库的出现，数据被大量存储
这个阶段是当数据规模大到一定量级，软件应对更多的需求作出的改变。继续拿扫雷这个游戏举例：当我玩了100万次扫雷之后，有了1PB的扫雷对战记录、通关时间等等数据。这时候就会有“平均通关时间”，“通关率是多少”，“开局第一个次点击的位置分布在哪”等等更加复杂的需求，软件不停的变更才能更好满足用户的需求。然而这些信息很难单纯的从业务数据库中查询出来，业务数据库只是为了完成记录，并不是为了分析而记录。因此就来到了阶段四
阶段四：从数据中挖掘价值
业务从数据中发现市场的规律，洞察客户的兴趣，产生一些人们不知道的信息。这个阶段在市场营销、生产调度等影响因子较多，动态性较大的业务领域，数据的重要性愈加凸显。（扫雷搞个彩蛋？通关送个彩票、设立个世界最快通关纪录、再打打广告…）
阶段五：数据成为企业核心资产
数据成为了企业的核心资产，所有的业务都被数据化。数据能够产生价值，数据无比重要。
总结一下，我们会发现在信息化时代，数据是流程的副产品，流程是预先设计好的，然后在设计好的流程中产生了数据
在数字化时代，业务流程应用软件（业务流程的显形载体）会随着市场的变化快速而不断动态迭代甚至消亡，而数据成为了物理世界映射到数字化世界的原子，数据思维（”Data First” ）成为战略核心之一。
什么是数据中台（CDP）？
既然中台这概念火了起来，那就有“前台”，“后台”吧。我们把它与企业中实际应用场景一一对应，这样就能对中台有个大概的理解。我用京东作为例子：
- 前台：京东金融、京东到家（线上买菜）、京东拍拍（二手）、京东（自营商品）
- 后台：内部OA系统、ERP、CRM、财务系统等等
这下就很好理解吧。对于传统信息化的企业来说，后台系统都是过于繁重的。应对前台业务的需求不能及时响应。甚至需要大改内部系统。中台就是介于这两个之间的缓冲层。将复杂的后台功能解耦，前台的通用模块复用。就是一个独立的数据中台。
正因此，我们可以从业务垂直划分出 用户中心、商品中心、交易中心等等作为中台服务之一。中台的意义在于建立通用化服务，链接前台和后台，避免重复造轮子，使业务可持续发展。前期实现核心功能，完成业务接入，中期灵活满足个性化需求、提升中台数据表现，以便让业务大量接入。后期则是组件化、新业务能灵活接入
中台和微服务的关系？
微服务
伴随中台火起来的微服务概念究竟是什么呢？
微服务是Martin Fowler 与 James Lewis 早在2004年共同提出的概念，在2014年正式命名微服务。根据业务功能设施，全自动的方式部署，与其他服务使用HTTP API通信，服务可以用不同的编程语言与数据库等组件实现。
企业中需要持续交付、快速迭代的业务、系统性能高可用（不适用于证券系统等性能要求苛刻的场景）、数据一致性层面可以使用微服务架构来拆分业务单元。常见的架构拆分方法一般有两种：
功能单元垂直拆分，如图（图片无法显示请挂vpn）：
这种将商品、用户、交易这些模块按照业务逻辑进行拆分，但业务有交集
水平拆分，如图（图片无法显示请挂vpn）：
- 网关层Gateway：过滤器、路由转发
- 业务逻辑层：RPC或者是Restful的形式去调用数据访问层，做业务逻辑处理的一些工作
- 数据访问层：CURD等一些数据交互的工作
- DB：关系非关系型数据库
- 独立于这些之外的配置中心（Apollo）， 注册中心（CP模型-Zookeeper，AP-Erukal）
常见架构模式
链式架构模式（交易系统，业务单一、下单减库存）
聚合器架构模式（聚合各个微服务）
数据共享架构模式（读写分离、数据量小的DB可以共享一个DB实例）
异步消息架构模式（MQ转发请求）
由此可见，微服务只是中台的一种解决方案，中台真正需要的不一定是微服务架构。微服务架构能很好解决引入中台的问题，而微服务带来的问题，又是否能很好的解决呢？
Where are we ？
如果对比理想化的中台系统来说，我们正在路上——目前只是建设好了“数据仓库”，可以持续接入业务中（提供对大数据分析的数据、小程序的数据接口、POS端点餐、ERP系统的物料成本等、财务系统的税率法人信息等等）。
我们在现阶段上可以针对订单数据、用户数据这两块做交易中台、用户中台以此完备中台。但所投入的人力与成本，是否值得回报？
中台真的值得做吗？引入中台又将带来什么问题？由微服务架构带来的维护成本真的承受得起吗？
这些问题值得我们去思考，道路是曲折的。一名好的架构师，我觉得最重要的是能在技术与成本之间平衡，为公司找到可持续发展的架构。既不拒绝旧技术，也不盲目追赶新技术。这样在浪潮退去之后，留给企业的才是真正的数据资产，数据价值。
半个月前，36kr报道，云徙科技外包茅台集团的项目成了中台概念下的第一个牺牲品。一份包治百病的PPT导致悲剧的发生。人们总是过于理想化，却没有看到他背后的缺陷。
on the way…