出处：本文摘录自《中台产品经理》一书
谈到“中台”，我们不得不说的另外两个概念就是“微服务”与“SaaS”，有很多人会把“中台”与这两个概念画上等号。但实际上，中台 ≠产品微服务 ≠ SaaS。这两个概念看似与中台很相似，却有本质上的区别，这一章就让我们着重讨论下这几个概念。
一、产品微服务
“微服务”一词最早是在开发人员的代码实现层面提出的，其目的是解决公司内部业务日趋复杂化后代码量指数上升所带来的高维护成本问题，这些问题具体为如下3点：
- 所有业务实现代码都写在同一个主体内部，任何人在维护时都要忍受“从头看到尾”的痛苦；
- 由于各个模块互相关联，任何一个部分都成为系统崩溃的潜在风险，例如流量激增或系统某一服务停止服务都会导致整个系统无法访问；
- 随着业务增长，系统不断衍生，而各个系统模块之间的交互也越来越繁杂，在对接新业务时需要实现高效的集群间通信方案。
而对于非技术出身的我们来说，可以将“微服务”简单理解成：为了方便代码维护与避免一个模块出故障导致整个系统都无法运行的局面，研发同学将功能按模块进行封装，组成一个个小的独立单元让它们独立运行，如图3-1所示。
图3-1 由“大代码库”划分为多个“小代码库”
这样的化大为小的思路在产品设计层面也是存在的，像公司随着业务线的发展，其产品内部的功能也会出现不同层级复用。因此我们在设计产品时就会将功能进行抽象并剥离出来，使之成为公共模块，以方便整条业务线调用。例如，审批模块、登录注册模块、个人信息编辑模块等。而这种设计理念被称为产品组件化。
在了解微服务出现的背景后，对于微服务的特点，我们就能清晰地勾勒出来了。微服务的特点如下：
- 对业务进行分割、抽象，将整体业务划分为多个子模块；
- 每个子模块自成体系，可独立运行该部分业务的完整流程；
- 每个业务系统的每个服务都有一个通用的标准，输入、输出定义清楚的边界。
看到这几条特点，大家是不是感觉有些许熟悉？这几条特点与我们刚刚学习的中台的实现概念可以说是如出一辙。所以中台与产品微服务的区别概括起来就是：产品微服务只是中台的实现手段之一但不是中台。在第12章我们会继续来讨论如何用微服务实现中台。
二、SaaS
另一个经常与“中台”相提并论的概念就是“SaaS”了，甚至有很多人错误地认为中台就是SaaS，这其实是犯了根本的概念性错误。
首先我们要弄懂什么是SaaS。SaaS的英文全称是“Software as a Service”，中文翻译为“软件即服务”。
怎么理解SaaS呢？这里我们就要先回溯下软件行业的发展史了。在互联网还未诞生之前，软件行业其实也是一个非常传统的行业。它与同时期的其他制造业在商业模式上几乎没有任何的区别，都是通过生产产品再卖向用户来完成一次商业活动，而唯一不同的是软件商每次卖给用户的只是一张罐装好程序代码的光碟，用户在拿到该产品后需要在自己的电脑上进行安装使用。在今天我们依旧能看到这样的软件公司，例如我们平时都会接触到的Windows制造商——微软。
既然软件产品是人类制造出的产品，那么它肯定会有故障的时候，这个时候就需要厂家进行售后维修。但是软件产品有它的特殊性，因为运行它的计算机载体不同，所以它所引发的故障和问题是不可控的，这也给厂家的售后带来了巨大的问题。
而在互联网诞生之后，厂家为了给顾客更好的体验，不再将应用软件以光碟的形式让用户部署在本机上，而是统一部署在自己的服务器上，由厂家自己进行后续的升级维护，此时用户可以通过网页或者特定的客户端进行访问、完成服务，不用再担心软件的安装与售后，常见的钉钉就是一个标准的SaaS服务。
此时每位用户可以根据自己的实际需求，向这些SaaS软件厂商按照计算量与时间进行使用权的购买，用多少买多少。
通过软件服务的发展史，我们不难看出SaaS其实就是一个服务需求方的成熟软件产品，它为顾客提供了完整的计算平台与客户操作终端，当然这里的终端可能是网页也可能是客户端。
对比在前面几章我们已经学习过的中台概念，中台其实是帮助企业自身提高研发效率的工具，中台的目的是企业能快速进行一个产品的搭建，而不是给客户提供直接服务。也就是说，首先中台产品的用户是企业内部的业务人员，同时在形式上，中台为了能更好地为各个项目提供能力支撑，在企业内部提供的服务更多是以接口的形式而不一定有客户端。
因此，我们能看到SaaS与中台其实是有很大的区别的。
出处：本文摘录自《中台产品经理》一书
