为什么微服务化、数据仓库都不是中台？
共 2247字，需浏览 5分钟
·
2020-11-23 23:14
导读：企业在多年的信息化进程中，基于特定应用场景，引入或建设了解决特定业务领域问题的多套垂直的IT系统或套件。这些单体系统或套件间的业务能力和数据不互通、不共享，形成了一个个系统烟囱和数据孤岛。
企业这种业务及数据的烟囱式IT架构，正是中台进化的原点。中台经历过业界的大力推广与布道，已为一些信息化比较完善的企业带来红利。
但是也如上文提及的，有些企业在演进的分叉口徘徊，由于种种原因，它们建设的所谓“中台”仅解决了短期在性能、扩展等技术架构上的问题，如单体服务微服务化、数据资产数仓化。在这里，我们需要明确一下，这些都不是中台。
作者：陈新宇 罗家鹰 江威 邓通 等
来源：大数据DT（ID：hzdashuju）
01 微服务化不是中台
以传统的思维来套用微服务，很有可能只是将原先彼此隔离的各单体业务系统通过微服务的方式强行集成在一起，如图11-1所示。这种方式不是基于领域，而是从一个系统的粒度层次来建设微服务。比如订单管理系统（OMS）关注会员和订单，客户关系管理（CRM）同样涉及会员和订单，而供应链管理（SCM）则涉及用户和订单。
▲图11-1 多个烟囱应用微服务化
可见，按此方式所建设的“中台”的各组成部分仍旧是互相交叉重叠的，数据还是重复且不一致的，并不能体现“中台是能力共享平台”的核心理念。因此，只将原有单体业务系统进行微服务封装，套上一个微服务的壳，连微服务都不算，更不能说是中台了。
还有一些企业选择针对某个业务系统，局限在此业务系统范围内进行微服务化（见图11-2），比如将OMS拆分为用户、会员、订单等，将CRM拆分为会员、订单、积分等。
▲图11-2 单个烟囱应用微服务化
从单个应用领域来看，这没什么问题。虽然使用微服务的技术架构解决了性能问题、水平扩展问题等，能充分发挥微服务的优势，但从企业全局来看，数据还是没有打通，有多套用户、多个会员系统、多份订单数据等，烟囱型系统仍然存在，因此这也不是中台，不是正确的发展方向。
中台是在将应用以微服务纵向拆分的基础上，加上横向切分，将共享能力与上层应用分开，形成可复用的共享服务层，从而促进业务和数据在各应用间的交叉共享，大大减少重复建设和重复投资，这也造就了中台的共享理念，使中台远远超出微服务的范畴。
02 数据仓库不是中台
企业对数据资产越来越重视，数据分析、数据运营被提上日程，而数据仓库规范与技术也日臻成熟，于是企业开始以经营分析为主要目的建设自己的数据仓库。在建设的过程中，企业会自底向上梳理业务板块，将各业务板块的数据分门别类，并按照数据仓库的规范进行建设。
而在中台尤其是数据中台的演进过程中，有些企业着眼于数据资产的集合，使用维度建模的方法论从业务过程中抽象出通用维度与度量，组成数据模型，从而为决策分析提供通用的数据分析能力，以满足企业数据报表分析的场景。这些企业将这种数据模型称为“数据中台”。
然而这并不是数据中台的全部。相比数据仓库，数据中台更加强调数据业务化，以服务业务的视角去规划企业的数据资产，以运营的视角去管理数据资产，以实时、智能的数据应用去服务业务。让数据用起来，不仅服务于企业数据分析，还主动迎合业务，梳理需要数据赋能的业务场景形成业务闭环。
综上所述，数据仓库只是解决了如何看数据的问题，而数据中台则进行了更全面的规划与建设，利用大数据和AI的特性解决业务洞察、精准决策、应用智能等一系列问题。
