写点什么

没有中台,但有微服务和 PaaS,一样吗?

  • 2019-10-25
  • 本文字数:3618 字

    阅读完需:约 12 分钟

没有中台,但有微服务和PaaS,一样吗?

不是所有业务都必须进行中台化,也不是所有中台建设都是一个充满矛盾的过程,优秀的微服务设计和完美的 PaaS 架构与中台也还是有所差异的。本文,InfoQ 采访了 ThoughtWorks 首席咨询师王健,听他分享中台建设的实施路径。


中台、微服务和 PaaS

一个概念代表一个新的边界。如果边界的定义不清楚,很多事情是没办法继续聊下去的。有关中台的基本概念已经有了很多介绍,大部分企业对于中台建设已经有了初步想法和规划,无论是解决数据孤岛问题、还是提高快速创新能力,中台都是可选的解决方案。然而,面对这些问题,企业最先想到的解决方案往往是相对轻量级的 PaaS 和微服务等解决方案,也不乏有人将 PaaS 平台称之为“中台”,但这三者之间其实是有差异的,搞清楚彼此之间的区别才可能选择出最适合自己的解决方案。


“那是我第一次帮助企业规划与建设中台,最开始我以为就是搭建微服务,后来才发现并不是这样的,微服务架构并不能解决这些问题,而这个过程让我多了很多思考”,王健如是说道:“最后,我发现当我们谈微服务时,我们更多关注的是技术架构层面的问题,而中台则往往处理的是企业架构问题。”


微服务架构通常采用前后端分离方式,按照一定的规则拆分为多个可以独立运行、独立开发、独立部署、独立运维的微服务或者页面聚合,从而满足业务快速变化及分布式多团队并行开发的需求,还可实现前端页面的复用,做到“一次开发,多端复用”,这也与中台服务的共享理念非常类似。所以,很多企业在进行中台实践时会将两者混淆。


从使用者的角度来看,大部分的微服务架构都是在支撑一个前台,而中台解决的是企业级能力复用,而这种能力复用一定是多前台、跨部门的。当然,微服务中也会提到复用问题,但这种复用一般指的是组件级别的复用,并未达到企业级的层面。一般而言,一个业务中台会同时抽调多个前台业务中可共享的能力,最终统一支持多个前台业务。


简单讲就是:中台不一定非得采用微服务架构,能够达到多前台能力复用的目标即可;而微服务架构也不一定要同时支持多前台应用,单应用的微服务化其实更多见。


那么,中台与PaaS又有什么区别呢?有观点认为中台与 PaaS 的区别只是一个定义在云上,一个定义在本地,但王健认为,更确切的说中台介于 PaaS 与 SaaS 之间,这里的 PaaS 更多是指技术的 PaaS 平台,与这类平台相比,中台更靠近业务,包含更多的业务属性,而与最靠近业务的 SaaS 相比,又具备更大的灵活性,所以也有很多的企业将中台比作 APaaS(Application PaaS)或是 BPaaS(Business PaaS)。


理论上,从业务的视角,如果 SaaS 能比较好的解决问题,那还是可以优先选择 SaaS。因为 SaaS 对于业务的封装会更加的成型,但缺点也是对于业务的支持过于固化,虽然可以通过配置化实现多条业务线的个性化需求,但仍然灵活性有限。


SaaS 的问题在于抽象层次很高,需要业务之间有很强的一致性,对业务的支持不够灵活,这也就有了中台的用武之地。中台比 SaaS 的抽象层次低一些,但更具灵活性,中台在纯技术的 PaaS 与纯业务的 SaaS 中找到一个比较好的平衡点,兼顾灵活性与业务封装,对于业务的创新支持更好。所以我们看到国外出现的一些新的 Headleass Commerce(无头电商),从思路上也和中台有着一些异曲同工之妙。


总结来看,中台就是一个企业级能力复用平台。王健补充道,企业级定义了中台的范围,区分开了单系统的服务化与微服务;能力定义了中台的主要承载对象,能力的抽象解释了各种各样中台的存在;复用定义了中台的核心价值,传统的平台化对于易复用性并没有给予足够的关注,中台的提出和兴起,让人们通过可复用性将目光更多的从平台内部转换到平台对于前台业务的支撑上;平台定义了中台的主要形式,区别于传统的应用系统拼凑的方式,通过对于更细力度能力的识别与平台化沉淀,实现企业能力的柔性复用,对于前台业务更好的支撑。

中台建设的必要性

如今,有关中台建设的文章越来越多,很多企业也希望可以建设中台,但这件事情并非短时间内就可以建设完成。在之前的文章中,我们也曾提到,建设中台,企业可能还需要考虑组织架构的调整,既然牵扯的事情如此之多,中台建设是否还有必要呢?


当一个人说“这个东西这么贵,我们真的需要么?”的时候,这个人大抵是不想要的;当一个人说“这个东西这么贵,能不能便宜点?”的时候,这个人还是想要的,只是希望以更加优惠的条件得到。——王健


很多时候,建设中台也是如此,当企业在思考“我们真的需要么”时,大抵是并未想清楚中台建设的价值。确实,中台这个概念如今热度极高,但也并不是所有企业都必须从现在开始搭建中台,也并不是所有的系统、所有功能都一定要搬到中台上,这是可以进行取舍的,比如一些功能比较固定的财务系统,可能不需要那么着急地接入中台。从本质上来说,大家常说,中台是一把手工程,但并不是只解决了一把手对于企业未来发展的焦虑。


“中台建设的前期可能没有给业务带来多大帮助,反而制造了很多问题,如果没有 CIO、CTO 甚至 CEO,或者技术委员会、战略规划部门等的支持,很难进行,可能原来想做一个业务中台,后来因为无法撬动业务,数据也拿不到,最终的建设效果就会大打折扣”,王健进一步补充道,“如果这时领导层没有驱动力帮助继续推进这件事情,这个中台推也不是,不推也不是,因此我认为中台建设应该是一个自上而下的顶层设计与驱动过程。”


但中台并不是仅仅解决了一把手的焦虑。对于普通研发人员而言,很难站在一定的高度去做一个”看十年、做一年“的规划,特别是当一件事和眼前的 KPI 难以达成平衡时。但是,当团队成员发现无论如何加班都很难满足业务团队的诉求,一旦团队发生人员流动就很难进行维护时,就需要思考是不是需要将日常能力沉淀下来,而不是简单的从一套代码 copy 出另一套代码来支撑新的产品。


虽然,公司可以砍掉部分产品来缓解研发团队的焦虑,但其实真正困难的不是决定做什么,而是决定不做什么, 这种决策其实比做中台更加困难。此外,作为一家成熟的公司,一定是需要有能够形成合力的产品矩阵来支撑整个公司战略推进的,所以多产品并行是公司发展到一定阶段的必然选择,而做中台也绝不是站在其中某一个产品的角度来解决问题,而是站在多产品协同的角度来看公司的战略发展。


当研发人员出现上述问题时,中台就不单单是为了解决一把手对于企业未来生存和发展的焦虑,而确实是可以解决企业现阶段发展过程中所遇到的问题的,中台建设的必要性也就凸显出来了。

中台建设方法论

很早之前,ThoughtWorks 就开始研究并落地中台建设的方法论,王健调侃道:“那个时候,我们是被客户推着走的,可以理解为是以客户为中心,因为市场需要才做的这件事情。我也不觉得在众多方法论中一定要分出优劣,最终可以更好地解决客户的实际问题就可以了。”


在 ThoughtWorks,这套中台建设的方法论弥补了传统企业架构方法对于创新和平台化的一些相关问题。王健解释道,一是创新的问题,传统的 EA 架构更多是基于现有架构流程的梳理,但中台更多是支撑业务创新,为以后的业务发展做支撑,这就是创新的问题;二是平台化的问题,就是传统的企业架构方法更多是解决信息化时代如何通过应用架构和技术架构的设计来适应企业的业务架构的问题,但是对于如何做平台化,并没有足够的方法支撑。



如果一家企业从零开始建设中台,ThoughtWorks 给出了如上的中台规划实施路径。在实施之前,需要进行大量的前提调研分析,比如企业战略分析、行业趋势分析、客户研究、业务线调研与分析、IT 资产盘点、领域分析。在前期后台完成的情况下,可以开始进行企业架构设计,这时就需要定义企业新的业务架构,新的以中台为基础的分层应用架构和新的企业级技术架构体系标准。


在产品设计阶段,企业需要排列项目优先级,定义第一优先级的项目范围与工作计划,设定项目的价值交付目标并进行路线图规划。如果企业希望先突破单个业务,也可以先梳理该单个业务的逻辑,并将该业务先迁移至中台试运行。


在开发运营阶段,企业就需要建设中台的基础设施,设定中台的技术规范和中台化、服务化的产品研发流程,并配合敏捷软件开发与产品重构来开展。最后,检查架构守护机制、审计架构实现现状,并提出架构改进建议。



王健表示,ThoughtWorks 会将这套方法论进行持续不断地打磨,在这个过程中融入其他好的方法,再进行优化。上述是一家企业进行中台建设比较完整的过程,如果企业希望从其中的每一个步骤开始,也是可以的。对于目标行业,王健提到了两点考虑因素:一是整个行业真正在向前发展,而不是炒概念;二是持续聚焦在某几个行业可以对业务具备充分的了解,可以让企业在业务积累上不断产生优势。

结束语

总结下来,王健认为,中台的本质是面向用户与创新的新兴平台型企业架构;中台战略是一个战略问题,需要战略决心与战略耐心并存;中台建设从企业战略出发, 自上而下结合全盘考虑;中台建设需要技术升级与组织升级配合,需要顶层设计与驱动,也要达成全员共识;最后,中台建设依附于成熟的技术支撑和方法论引导,才可以少走弯路,实现弯道超车。


2019-10-25 10:044101
用户头像
赵钰莹 极客邦科技 总编辑

发布了 893 篇内容, 共 668.7 次阅读, 收获喜欢 2690 次。

关注

评论 1 条评论

发布
用户头像
"如果 SaaS 能比较好的解决问题,那还是可以优先选择 SaaS。因为 SaaS 对于业务的封装会更加的成型,但缺点也是对于业务的支持过于固话" 这里应该是“固化”?
2019-10-25 16:44
回复
没有更多了
发现更多内容

第三方测评:GaussDB(for Redis)稳定性与扩容表现

华为云开发者联盟

redis 华为云 GaussDB(for Redis) NoSQL数据库 云原生NoSQL数据库

☕【Java深层系列】「并发编程系列」让我们一起探索一下CompletionService的技术原理和使用指南

码界西柚

Java 线程池 CompletionService 异步执行 1月日更

直播回顾:准确性提升到 5 秒级,ssar 独创的 load5s 指标有多硬核?| 龙蜥技术

OpenAnolis小助手

Linux 开源

SparkSQL的入门实践教程

华为云开发者联盟

sql spark 编程 Sparksql 结构化数据

行业先锋畅聊 Flink 未来 —— FFA 2021 圆桌会议(北京)

Apache Flink

大数据 flink 编程 后端 实时计算

Linux之wc命令

入门小站

Linux

恒源云(GPUSHARE)_AdderSR: Towards Energy Efficient Image Super-Resolution学习笔记

恒源云

人工智能 深度学习 计算机视觉

征文投稿丨在轻量应用服务器上部署SpringBoot项目

阿里云弹性计算

阿里云 用户投稿 轻量应用

在线YAML转TOML工具

入门小站

工具

异步调用如何使用是最好的方式?

CRMEB

自动驾驶浪潮下,如何给技术迭代插上数据的“翅膀”?

澳鹏Appen

人工智能 自动驾驶 智能汽车 智能驾驶 数据标注

SAST 为什么会成为网络安全领域的下一件大事?

旋极智能

静态分析 静态测试工具 代码静态分析

携程DBA负责人俞榕刚:OceanBase在携程的落地和实践

OceanBase 数据库

数据库 分布式 OceanBase 开源 携程 客户实践

Flutter启动流程分析之插件化升级探索

得物技术

flutter Weex Google 框架 原生

“以终为始”的正确使用方式

石云升

思维模型 1月月更

手把手教你丨小熊派移植华为 LiteOS-M

华为云开发者联盟

华为 鸿蒙 LiteOS 小熊派 移植

Hive企业级性能优化

五分钟学大数据

hive 1月月更

高并发环境下,6个构建缓存服务需要注意的问题

华为云开发者联盟

缓存 高并发 开发 并发 缓存服务

从智能汽车到智慧出行,区块链能打通车联网的任督二脉吗?

CECBC

Mybatis中的VFS是个啥

尹昶胜

mybatis

鉴释加入龙蜥社区,助力开源生态建设

OpenAnolis小助手

Linux 开源

“在线设计”网络资源管理的源头活水

鲸品堂

通信运营商 在线设计平台

恒源云(GPUSHARE)_attention decoder效果不佳时如何应对

恒源云

深度学习 计算机视觉

农业掀起“上链”潮 区块链等数字技术正成为乡村振兴新动力

CECBC

亚信科技AntDB数据库荣获“2021金融科技应用创新突出贡献奖”

亚信AntDB数据库

AntDB 金融行业 亚信科技

Hive 数据倾斜问题定位排查及解决

五分钟学大数据

hive 1月月更

微信业务架构图及学生管理系统架构设计实践

IT屠狗辈

系统架构 架构实战营 微信业务架构图

用 docker 快速搭建 kafka(qbit)

qbit

kafka zookeeper docker image

必读!如何有效的进行沟通

观测观测

一款基于Java语言开发的,开源商业应用的模块化开发框架和智能管理平台-Axelor

马农驾驾驾

Java 系统开发 BPM 开发框架 智能管理

作业帮基于 Flink 的实时计算平台实践

Apache Flink

大数据 flink 编程 实时计算 IT

没有中台,但有微服务和PaaS,一样吗?_文化 & 方法_赵钰莹_InfoQ精选文章