写点什么

没有中台,但有微服务和 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:044189
用户头像
赵钰莹 极客邦科技 总编辑

发布了 897 篇内容, 共 690.6 次阅读, 收获喜欢 2699 次。

关注

评论 1 条评论

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

敏捷开发:想要快速交付就必须舍弃产品质量?

敏捷开发

项目管理 Scrum 敏捷开发 产品研发 研发

实战代码静态分析工具:利用语法树数据工具提升代码质量

测吧(北京)科技有限公司

测试

互联网公司裁员现象调查:探寻背后原因与应对策略

小魏写代码

OLAP性能再获突破!火山引擎ByteHouse性能白皮书发布

极客天地

日立公司采用元太科技电子纸实现了无纸化营运

财见

中国 10 亿参数规模以上大模型数量已超 100 个;GitHub 推出代码自动修复工具丨 RTE 开发者日报 Vol.172

声网

深入理解精准测试理论与技术:揭秘测试技术的核心原理

测吧(北京)科技有限公司

测试

亚马逊云科技携手埃森哲、Anthropic助力企业打造负责任的AI

财见

更轻松地部署和升级 NGINX Service Mesh

NGINX开源社区

nginx Kubernetes Helm Service Mesh 服务网格 mTLS

搭建Elasticsearch、Kibana和Logstash环境:构建强大的数据分析平台

测吧(北京)科技有限公司

测试

比 MyBatis 效率快 100 倍...

Java技术精选

深度解析代码变更对业务的影响范围:业务影响范围关联分析

测吧(北京)科技有限公司

测试

码上时刻|通过逻辑视图 Logic View 快速实现批流一体

Kyligence

解锁TikTok直播专线,提高使用体验

Ogcloud

海外直播专线 海外直播 tiktok直播 tiktok直播专线 tiktok直播网络

同城双活:交易链路的稳定性与可靠性探索

得物技术

Java 后端 中间件 双活

新版Redis不再“开源”,对使用者都有哪些影响?

华为云开发者联盟

数据库 redis 华为云 华为云开发者联盟 华为云GeminiDB

软件测试学习笔记丨Allure2 报告中添加附件(视频)

测试人

软件测试

代码覆盖率提升策略:利用静态分析工具优化测试覆盖率

测吧(北京)科技有限公司

测试

如何轻松管理你的海外主机?实用技巧大公开!

一只扑棱蛾子

海外主机

聊聊我做测试开发的十年心路历程

阿里技术

测试 开发

阿里云实时计算Flink的产品化思考与实践【上】

Apache Flink

大数据 flink 实时计算

分享一些大数据处理算法

Chris Zhang

大数据

ECS公网连接指南:精明选择公网IP计费策略

极客天地

“专业敏捷教练课程” 6月1-2日 · CSP-SM认证周末班【晋升高阶享多重福利】

ShineScrum

云端简易指南:快速启动与管理您的ECS实例

极客天地

深入了解一下http和https的区别

秃头小帅oi

TikTok直播专线是什么?有什么用?

Ogcloud

海外直播专线 海外直播 tiktok直播 tiktok直播专线 海外直播网络

软件测试学习笔记丨Allure2报告中添加附件-日志

测试人

软件测试 测试开发

JVM字节码分析与修改:探索代码覆盖率底层实现框架

测吧(北京)科技有限公司

测试

利用Shell二次封装Elasticsearch客户端:简化数据检索与操作

测吧(北京)科技有限公司

测试

SpringBoot集成ElasticSearch,实现模糊查询,批量CRUD,排序,分页,高亮...

Java技术精选

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