NEW
《中国传媒科技》刊登拓尔思文章
以下为文章内容
中台是什么？
2015年中，阿里巴巴管理层参观了当时世界上最成功的移动游戏公司——芬兰的Supercell，这家游戏公司不到200人，推出的游戏不到10款，但是每款都是爆款，Supercell则几乎每月都高居全球游戏公司收入排行榜榜首（次年被腾讯收购）。
Supercell如此成功的关键因素之一是：有个强大的游戏中台在做支撑，每个游戏开发团队平均只需要3-7 个人，因此可以并行开发 50 款游戏，然后通过“内部赛马”选出一到两款经典再上市。
2015年底，阿里巴巴集团对外宣布全面启动阿里巴巴集团2018中台战略，构建符合DT时代的更具创新性、灵活性的“大中台，小前台”组织机制和业务机制。
2017年4月，阿里巴巴中间件首席架构师钟华的《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》[1]一书出版，此书详细介绍了阿里巴巴中台的源起、试错、实施方法论等，被奉为经典，销量超过10万册。
2019年中，中台被百度指数收录，中台一词进入越来越多IT从业人的视野：
中台的百度指数趋势(2015.06-2021.02)
虽然中台自此大热，不过并没有一个统一的定义。对中台的理解，始终是见仁见智。网上常见的一个定义是ThoughtWorks王健给出的“企业级能力复用平台”[2]。作为一家to B的ISV，我们面向的都是企业级客户，提供给B端客户的必须是企业级软件产品，因此我们的理解相对要简单实际一些，重点并不是放在能力复用上，因为复用一直是商用软件开发的内在要求（虽然实际达成并不是那么容易）。
能力复用最终是为了能够快速交付满足客户诉求的软件产品，从而和客户双赢。因此我们将中台理解为，有助于快速交付出满足需要的产品设施。如果这个设施只是在我们的研发生产过程中需要，那么这个设施是何种形态，不用太在意，顺其自然。如果这个设施在客户的生产环境上也需要，那么这个设施就必须也要能以产品的形态提供。
由于交付出的软件产品必须要持续、稳定地运行，才能满足客户的各种诉求，所以我们交付的软件产品并非只是个静态的产品介质，而是包括了运维等各种服务在内的动态、成体系的组合。也就是说，交付产品介质仅仅只是一个开始，在整个服务期内，需求迭代、bug修改、性能优化、安全增强、故障恢复、环境调整……都在满足客户诉求的范畴内，都需要快速交付，所以，中台这个设施并不只是作用在研发生产过程，还需要作用在客户生产环境，因此，我们的中台，在形态上，也是个产品。
中台的建设思路
阿里在他们的中台战略实践中，根据实际情况演化发展出六个中台：业务中台、数据中台、算法中台、技术中台、研发中台、组织中台，后来还增加了一个移动中台。有些企业也效仿阿里的做法，规划了这六七个中台，但是可能并不符合自身的需要以及实际情况，这样很难达成比较理想的效果。我们认为，中台在规划时，就要从自身实际出发，要能为自己和客户带来实际的价值，不能为了中台而中台。由于中台的挑战性和不确定性，规划时只能先确立大致方向和总原则，需要在实践中不断探索、试错，逐步得出一些具体准则。
根据我们自身的情况，我们将中台产品规划为四类：技术中台、数据中台、行业中台、AI中台。其中，行业中台对应阿里的业务中台，主要的差异是：阿里的业务就是电商，所以就是一个业务中台；而我们的客户分布在多个行业，因此不能只是一个，而是多个，为了体现和行业相关，所以叫做行业中台，具体如媒体行业中台、政务行业中台、网信行业中台等等。
在研发思路上，我们主要是一条总原则：尽早创造实际价值。这个总原则可以帮助我们做出很多决策，比如：
1） 对于行业中台，有个必须的先决条件：只有我们深刻理解吃透了业务的行业，才能进行研发规划。这是因为，只有吃透了业务，才能做出可以快速响应业务需要的行业中台，否则，下大力气投入研发的中台，不仅起不了作用，不能给客户带来价值不说，还会拖后腿。而技术中台和数据中台，特别是技术中台，一般不会受到行业业务的影响，因此，我们的中台产品研发，先从技术中台和数据中台开始。
2） 技术中台有太多太多的子领域，需要先找当前价值较大且见效较快的痛点或增长点的。
3）不重新发明轮子，而是融合它。比如，对于我们已有的传统产品，虽然古老，但是如果能解决问题，就不必为了架构的统一而从头重写，因为多数时候，小的改良远胜于重写。事实上，我们只用了几天的时间，就让一款10多年前开发的产品顺利运行在了由K8S编排的无状态容器中。
根据研发思路和我们的实际情况，我们率先启动的是技术中台和媒体行业中台的研发。理论上，媒体行业中台应该要用到技术中台、数据中台和AI中台，但由于拓尔思在媒体行业与客户的深度合作耕耘，自媒体融合初期就已逐步形成了中央厨房、媒体大数据等媒体能力复用平台，按照尽早创造实际价值的原则，可以直接下沉形成媒体行业中台，不必非等技术中台、数据中台出来后再造一遍。
拓尔思的技术中台建设
现阶段，我们大多数项目最主要的痛点是无法快速、稳定地交付，因此我们技术中台的重心放在DevOps和API网关产品上。下图为技术中台的规划图，不追求大而全，而是从我们的实际需要出发，删繁就简，聚焦在刀刃上，为我们和客户发挥出实际价值。
拓尔思技术中台规划
从图中可以看到，技术平台的底层资源环境已经是基于容器的PaaS平台环境了，它可以提供完整的云原生能力。云原生能够为上面的DevOps提供更完整强大的支撑能力，有助于实现从研发到运维的一站式处理能力；API网关则可以配合DevOps进行更灵活的灰度发布、优雅降级等功能。基础应用则是纳入了一些较通用的应用产品或组件，因为它们都是行业业务松耦合的，所以能较好地适应各个行业，因此专门将它们沉积下来。下面详细介绍各个部分。
??容器PaaS平台
核心是Docker K8S的资源调度平台，实现容器化的中间件资源池，资源的动态分配和调度，中间件集群等。容器/云原生早已成为趋势。云原生不只是指应用程序所在的位置，更重要的就是指应用程序的构建和部署方式。云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。
这些技术能够构建出容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术让工程师能够轻松地对系统作出频繁和可预测的重大变更。
云原生的核心目标是将企业IT应用和IT基础设施的部署变得更加敏捷，从而使企业能够采用较低的技术成本享受到云的弹性和灵活性。
云原生计算基金会(CNCF)将云计算定义为：容器化封装 自动化管理 面向微服务。在2018 年，CNCF 更新了云原生的定义，加入了服务网格(Service Mesh)和声明式 API。[3]具体而言，容器技术，服务网格，微服务和Serverless是云原生的核心技术，而DevOps是对这些技术进行整合的一个关键实践。
云原生的关键优势主要包括：
1）与传统的单体应用程序相比，由于使用敏捷和DevOps流程进行迭代，加快了产品交付和迭代；
2）微服务架构下自动地逐步改进云原生应用程序，以不断添加新功能或者改进原有功能；
3） 可以非侵入式地进行改进，不会造成停机或中断服务，给用户造成不良体验；
4） 支持云原生的应用程序，对于不同的访问负载压力，可以轻松进行弹性伸缩；
5）云原生的开发流程，能更好地适应当今业务环境所需的速度和创新。
??一站式DevOps平台 API网关
DevOps的核心是实现持续集成和持续交付能力，同时实现测试管理和自动化测试、环境管理、配置管理、监控告警、应用节点规模的弹性伸缩等关键的测试能力和运维能力。
DevOps本质上是一种思想，即“开发运维一体化”，打破开发（Development）和运维（Operations）各自为战的屏障，突出开发人员和运维人员的沟通合作，以CI/CD（持续集成/持续部署）为基础，来优化开发、测试、系统运维等所有环节。
在具体实施上，DevOps强调CI/CD（持续集成/持续部署）。这是因为，困扰业界已久的一个问题就是IT的变化赶不上商业的变化：IT的变化耗时实在太过漫长——它需要开发、测试、部署等多个环节，而且要综合考虑每个变化所产生的影响，比如某公司上线功能H，它必须要确保公司已有的功能ABCDEFG不会受到影响。只有合规的持续集成/持续部署，才能够保证IT能够跟上市场的变化。
DevOps还包括监控告警，这是提升运维能力的重点之一。核心是实现容器、中间件、应用等资源的监控，服务和服务链的监控，以及问题的发现和自动化运维流程。监控发现的问题会进入到运维流程，用户反馈的问题也可以进入到运维流程。
关于API服务网关：中台是一个独立的组织负责并为多个前台业务服务，因此需要一个标准的服务接口、成熟的服务治理能力和高效的敏捷研发技术。在当前的技术环境下，采用地球人都熟悉的 REST 风格的同步 API、消息队列异步通信作为标准的服务接口技术，采用API 网关作为标准的服务治理是最合适的选择，同时在网关子系统中整合服务注册中心、服务链监控、服务限流熔断等关键能力。
??基础应用
基础应用首先是行业无关的应用，其次要提供有简捷易用的API或者更加轻量快捷的接入方式，使得其他应用（主要是业务应用）做少量编码甚至不需编码就能快速具备相关能力。比如：
音视频处理：很多业务系统都有音视频文件的处理诉求，比如CMS要能上传和发布视频、知识管理系统要能传播视频形态的知识等。由于音视频文件的格式多样，使用各不相同，如果每个业务系统都自己开发，那么一方面是重复开发的内容多，周期长；另一方面，音视频文件散布在不同的业务系统中，给存储和管理、网络传输、文件流转、用户交互等都带来了很多麻烦。
于是，音视频处理应用此时发挥了中台的作用，它提供了组件式的上传页、播放页，供其他系统外嵌，其他系统只要按接入规范，做少量的页面开发，就可以给自己增加音视频功能，用户通过浏览器交互即可顺畅地在原有业务流程中使用到音视频的功能，一方面极大地降低了开发工作量；另一方面，音视频文件也能够集中管理，优化存储等。
总体效果是音视频的上传、转码、播放等处理，完全都封装在音视频处理应用系统内部，其他系统无需了解细节，也就无需做多少开发工作。
统一认证：同理，各个业务系统只需要按接入规范，增加一个类，无需改动已有代码，就可以从统一认证系统获取到统一用户供应，并具备单点登录能力。
全文检索、消息队列：只要调用各自的SDK就可以了，不再赘述。
拓尔思媒体行业中台建设
拓尔思媒体行业中台体系规划
移动互联网时代，用户的需求才是核心，平台化的力量可以使我们事半功倍。鉴于传统的“前台 后台”的平台化架构已逐渐不能满足用户不断快速变化的需求，我们的媒体产品采用“中台”理念，以真正为前台而生的平台，更好地服务前台规模化创新，更好地响应服务需求，做到自身能力与用户需求的快速、持续对接。
通过业务中台、技术中台、数据中台、AI中台的构建，完成跨业务线的媒体行业中台，以构建大融合、大管控的平台能力层来实现能力复用平台建设。我们的媒体行业中台通过服务重用，可以方便各业务线快速简单地获取能力，对能力和数据进行沉淀，更利于创新，解决“业务变化快”和“技术系统迭代慢”的矛盾。
在我们的媒体行业中台体系下：
容器技术为PaaS中台的服务能力、技术组件、中间件提供稳定的运行支撑环境和敏捷开发基础；微服务架构使PaaS中台对上层媒体应用的服务能力更加快速地实现；DevOps加快PaaS中台服务能力实现的迭代速度；
通过数据中台，将媒体的自有数据资产和外部数据资源进行集中管理，依托大数据和AI技术对数据进行标签和归档管理，制定对上层媒体服务的统一数据服务标准和接口，方便对媒体不同的应用场景提供标准化的数据服务；
人工智能服务提供媒体智能引擎服务，在内容感知和认知两个方向上涵盖了智能语音、智能视觉和自然语言处理等多个维度支撑。AI中台以机器学习和深度学习为基础，结合我们多年在媒体行业的积累，并为媒体行业独立定制了服务语料和学习样本，使得AI在媒体场景的落地上更加具象化。
我们的媒体行业中台可根据用户项目的规模和实际需求进行拆解，如整体项目采用大中台的概念，打造统一中台能力服务；也可独立部署技术中台、数据中台或者AI中台服务，实现面向不同需求方向的中台能力层建设，以更好地和用户的现实情景相契合适配，完成技术平台向中台服务的升级转型。
结语
中台的规划和建设，要从业务价值出发，始终围绕能给业务带来什么价值来进行规划和实践。回顾软件过往发展中的各个热词：大数据、云计算、区块链、AI，无不如此。如果业务上没有想清楚，不能讲清楚的话，那么任何技术手段都是徒劳的。
由于拓尔思的to B业务和互联网企业的to C业务的模式不同，因此，拓尔思的中台建设，不能盲目照搬互联网企业的中台建设方案。而是根据自身的需要和资源实际情况，按技术中台先行、媒体行业中台先行的策略，进行建设。
最后，本文是我们中台建设中的一些研发实践与思考，期间也走过弯路，希望通过本文的总结，与大家共同探索媒体行业的中台建设路径，推动媒体行业发展。
参考文献：
[1]钟华.企业IT架构转型之道：阿里巴巴中台战略思想与架构实战[M].机械工业出版社，2017-4-1.
[2]互联互通社区.中台到底在共享什么[EB/OL].知乎，2020-10-27.
[3]比特网.别再云里雾里，或许我们可以这样理解云原生[EB/OL].比特网，2021-01-12.
刘珅（1980-）， 男，湖北省红安县，拓尔思信息技术股份有限公司第二研发中心总经理。
林松涛（1977-），男，安徽省合肥市，拓尔思信息技术股份有限公司副总裁兼新闻出版事业部总经理，研究方向：融媒体。
关于《中国传媒科技》
