业务中台架构设计「微服务架构设计」

今天给大家普及一下业务中台架构设计「微服务架构设计」相关知识，最近很多在问业务中台架构设计「微服务架构设计」，希望能帮助到您。

编辑导语：中台这一概念在前几年引发了大量企业的关注和投注，然而，什么样的中台才能算是好的中台？关于这个问题，也许你可以从功能模块、业务形态等多方面进行解读。本篇文章里，作者发表了他对中台设计的看法，一起来看一下。

从18年起，国内一众大厂都掀起了中台风暴，而做着做着却发现——“嘿，中台也能赚钱！”阿里云/腾讯云/火山引擎等都是大厂业务中台化的产物，算法中台/商业中台/功能中台等拔地而起，在那个时间点下，无论是为了企业降本增效或者是纯粹的模仿，很多互联网企业纷纷跟风跟进中台战略。

大厂做中台战略合情合理，即能满足业务多元性发展的需求，也能降低企业生产成本，最重要的是——通过中台战略内部孵化出来的服务能向其他企业提供，中台是一门生意。

SaaS产品就是从中台概念中脱胎出来，通过SaaS接入的形式实现免开发以及快速介入，这里不妨思考：

SaaS需要怎么样类型的一种中台？SaaS如何通过产品设计快速实现中台？

在回答上述的问题之前，我们要先下个定义——怎样才算是好的中台？

一、什么是好的中台？

首先我们把眼光挪到20世纪60年代的美国，随着汽车工业的计划以及汽车的普及，当时的汽车制造商所面临最大问题是——

造车的成本为什么会这么高？为什么我新造一辆车就需要重新设计底盘/动力传输这些看不见的东西？

于是通用公司就提出了造车平台概念，即不同的车型可以用一个平台上相同的底盘/发动机/变速箱等系统，通过外观/内饰等设计快速实现产品上新以及差异化，我们可以理解这就是汽车行业的“中台”，支撑了通用/大众等汽车厂商旗下众多产品线的快速发展

我们不妨将眼光扩大，不仅汽车行业，其他的行业是否也有类似的中台设计？这里要引入一个传统制造业的概念，叫“柔性制造”。

不同于传统按需生产的刚性生产法（先有需求，再有产品；一条生产线只能生产一种产品），柔性制造最大的区别就是通过组合多个模块化的生产机床以及配置自动运送的生产线搭建，实现单一生产线能生产不同产品，从而实现边际成本的降低和快速面对市场的反馈

柔性制造概念中有一套评判生产是否柔性的标准——

机械柔性：支持加工不同零件；工艺柔性：随着材料变化能变化对应的工艺流程；产品柔性：对老产品能兼容，能快速生产新产品；生产能力柔性：生产量变化时，整体系统能快速做出反应；维护柔性：能快速查询和定位故障，保证生产运行；拓展柔性：支持快速扩展和增加模块，构成更大的制造系统。

柔性是对生产能力、生产工艺以及对应的产品提出了可拓展、可兼容、可变化的需求，是对如何快速面对市场的变化以及用户需求的变化，同时在竞争中保持优势地位，这是企业生存的长期思考命题，“中台”是长期思考中得到的一个标准解

19世纪80年代营销大师迈克尔波特提出了营销三大竞争战略：成本领先/差异化/集中化战略，而“中台”正好契合了竞争战略内的核心因素——如何降低生产成本/如何提升新品生产周期，所以“中台”是一个产业高度工业化和市场化的体现。

基于工业在中台上的建设经验结合互联网生产特性以及商品特性，好的中台有以下的性质——

模块化：通过业务模块化能降低新业务的投入成本；能快速跟随业务的变化而变化，支持快速搭建新产品新业务或者进行业务调整；可扩展：随着业务的发展，中台能容纳更多的能力，为业务承担更多的基建压力或者供应压力；业务方在中台能力的基础上实现自定义能力建设；标准化：标准化的中台产品能降低业务接入成本，常见的标准化形态包含——h5插件/jssdk/sdk/接口/SaaS等；可兼容：能兼容以及支持多类不同业务，实现多类业务的并行使用。

所以，工业化给出了两个解决方案——

“汽车平台式的中台”——大中台；“模块化的中台拼接”——小中台。二、SaaS产品“大小中台”策略

而这两类中台策略分别使用于哪种类型的产品，我们需要从SaaS产品的架构以及商业模式进行分析。

目前市面上看到的SaaS通常会有以下3类：

业务型SaaS：为客户的赚钱业务提供工具以及服务的SaaS，直面的是用户的生意，例如有赞微盟等电商SaaS以及销售CRM工具，为B2B2C企业；效率型SaaS：为客户效率提升工具的SaaS，如项目管理工具、Zoom等会议工具，提升办公或者生产效率，为B2B企业；混合型SaaS：即兼顾企业业务和效率效用SaaS，例如近几年在私域流量上大做文章的企业微信，其本身就是一个办公协同工具，但为企业提供了一整套的私域管理能力，实现业务的提升，同时也支持第三方服务。1. 业务型SaaS的架构以及商业模式

纵观业务SaaS产品的发展方向，在产品的成长期阶段，为了扩充业务规模和体量，业务SaaS产品会拓展为“多场景 多行业”的产品模式，为不同行业或者不同场景提供适应的解决方案，例如做电商独立站的有赞，后期发展为“商城、零售、美业、教育”多行业的解决方案进行售卖。

我们纵观有赞的产品结构，都是以商城为核心，兼容不同行业的产品需求所构筑而成，像商品体系、计费体系、店铺装修、人员管理、营销功能等通用性强的产品模块对有赞而言就是一个个打包好的积木，在积木的基础上拼接新的积木就能得到新业务新解决方案。

例如教育需要的线上内容模块、美业需要的线下会员管理方案等等，业务的SaaS更像积木，通过一块一块中台的拼接就可以实现新产品的开发，属于“乐高式”的中台模式。

所以业务性的中台更加适用于“小中台”模式，通过模块组合加速业务发展。

2. 效率型SaaS的架构以及商业模式

效率SaaS从企业需求来说是“对症下药”类型，不同于业务型的SaaS，效率SaaS思考得更多的是企业内存在一个大共性的效率的问题，不同的企业对于CRM销售系统的需求是不一样的，但都需要一个协同办公的产品来提升协作效率。对于效率类SaaS来说，从哪来到哪去是非常清晰的，就是要解决优化或者解决一个流程上的问题。

所以此类初创期的关注点在于产品流程的闭合，产品体验的完善，往往不关注细分行业在相同功能上的差异性，例如针对互联网公司的项目管理软件的SaaS工具，在软件设计前期是不会涉及到交付类型公司以及toC公司的项目管理差异。

而成长期，会在基础产品上增加不同功能以满足不同用户的需求，像知名的设计协作软件蓝湖，就在本身产品的基础上针对教育行业、互联网、金融行业的客户输出了不同的解决方案，不同于业务型SaaS，效率SaaS在中台设计更底层和基础，底子打造完成，换上不同的衣服就考验满足不同用户的需求，属于“换壳式”的中台模式。

效率型的SaaS更加适用于“大中台”模式，通过拼接不同的套件，实现多个行业的切入。

3. 混合SaaS

混合SaaS是业务和效率SaaS的结合体，负责企业业务以及企业管理流程的某类场景上的降本增效；因混合SaaS核心业务的使用场景是清晰且通用的，非核心业务是近似于锦上添花的存在，所以在中台产品架构上更接近为“1 X”组合方式——即1个核心业务 X个非核心功能，两者在产品层级上是属于同一层级的。

所以非核心业务在混合SaaS的商业化中是比较边缘的存在，首先企业难以花费太多精力研究非核心业务，其次是通用的核心业务客群宽泛而非核心业务的客群狭窄，研发成本高昂，所以很多混合SaaS平台均采用开放平台的形式，接入第三方的功能服务，无需自行开发，作为中间商实现盈利变现。

所以从产品架构上而言，混合SaaS与业务SaaS接近，中台结构更贴近业务的形式。

为了实现大小中台的架构，我们在产品设计如何通过中台化来实现中台目标？

三、功能中台化

人活这一世，能耐还在其次。有的成了面子，有的成了里子，都是时势使然。

——宫宝森《一代宗师》

在电影《一代宗师》中，王家卫借剧中人物宫宝森之口，用里子和面子等讨论了拳术、社会和门派的表里关系。

在互联网语境内，面子就是用户所能接触的前端（表现层与框架层），而里子是支撑起这些表皮的后台（架构层和范围层）。

对于SaaS工具而言，中台不仅包含每个业务模块，更重要的是如何通过产品设计实现业务模块的中台化，所以在产品层面会有两个重点的思考方向。

降本——针对新场景/新客群的新产品建设；增效——一个功能如何制定中台策略。

针对这2个思考方向，我们可以得出如下的设计原则。

1. 组件化设计

组件化是对功能进行封装以及接口建设，对于主要服务于中台有2个意义：快速接入以及重复调用。

例如用户能在抖音消费到图文、视频和直播等内容，而抖音的内容创作平台是覆盖了从内容生产→内容呈现→内容分发（算法）→内容变现（支付&广告）→粉丝管理→结算等流程。

组件化在流程中扮演什么角色呢，通过对内容分发以及内容变现模块的组件化，抖音就只需投入成本在内容的生产以及呈现模块上，像内容分发、内容变现等功能通过一个接口或者页面调用就可以快速接入，从而实现新业务新产品的快速建设。

2. 业务性对功能设计的影响

在设计中台产品时，需要对功能的业务性进行评估。

产品的业务性是指某个产品是否可以独立存在，例如一个红包功能，表面上是一个独立的功能模块，但红包在实际的使用中非常依赖前端的场景建设以及支付体验，例如微信红包是社交场景，而支付宝的红包是商家服务的场景，所以红包的业务性比较低。

那像红包此类的业务性低的产品如何进行中台设计？

不封装前端内容：实现前端自定义交互以及页面，更加通用；做接口调用以及数据保存：支持不同业务不同终端对功能的需求，更加兼容。

而对于业务性很强的产品，如一个项目管理功能，可以单独使用也可以与其他场景进行结合，例如搭配工单缺陷系统，就能组成一个面向互联网行业的新产品。所以在业务性很强的业务内，如何实现核心业务对于其他能力的快速支持以及数据流转——

为流程上下游的功能模块提供通用的调用以及创建规则：如一个导航功能——生成最优路线以及计算时间，本身业务性可以与地图功能很好的链接，但其他场景也充斥着大量的导航场景，如打车场景、外卖场景、运动场景等，但导航的算法永远只有一个，所以在导航功能的中台设计上是提供一个创建以及数据同步接口，实现算法优化以及数据沉淀。业务功能与业务功能之间应该相互独立，不耦合：不同业务的数据尽可能通过接口实现，在产品设计上尽量不耦合。

以上就是关于中台产品的设计思考，希望大家可以在评论区留言讨论，谢谢指教。

本文由 @朋克Penk 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Pexels，基于CC0协议。