编辑导语：云时代 SaaS 产品创业有着大学问，想要学会就更是不容易，这篇文章是O2O 生鲜 SaaS 创业记中的系统篇，从系统这个层面进行讲解，一起看看吧。

一、系列简介

这是一部云时代 SaaS 产品创业记，讲述一位技术创业者如何从零开始系统完整建设满足行业客户产品，从战略到战术，从产品到技术到组织，从定位到定价到盈利，从云到中台到 SaaS，共计八个篇章内容涵盖行业/客户/友商、市场/增长、产品/中台、云服务/微服务/系统、组织/协同，力求全面清晰讲透云时代下 SaaS 产品建设。

二、系统篇序

系统架构从来都是顶层设计，自上而下进行分而治之，本质是领域逻辑和业务逻辑的分类。云时代架构关注复用和弹性，简单说是中台和 SaaS 化。

三、云系统架构

在云时代中如何设计和落地符合时代和行业需要的系统架构，如何匹配业务模式更好的支撑业务发展和响应市场变化以及指导组织架构，是业务系统架构师首要思考的问题。

这里业务系统是指支撑业务运营并赚钱或省钱的系统，可以是我们讲的外卖平台管理系统，也可以是滴滴出行那样打车服务系统，这些都是业务系统，应用云计算特性，做到复用和弹性则是业务系统首要考虑事情。

高性能/高可用/可扩展架构是面向具体系统稳定性的解决方案，是解决大流量、高并发、稳定性问题，采取策略是读写分离、分库分表、高性能缓存、服务集群等。我们需要先架构业务系统，再针对具体业务流量进行高性能/高可用/可扩展架构。

业务系统架构最直接产出是中台和 SaaS 化系统，中台解决业务运营能力复用，大致分为技术中台、业务中台、数据中台，SaaS 化系统解决客户分层和弹性服务。

云时代架构首先要理解什么是云计算，根据 NIST（美国国家标准与技术研究院）以及微软、IBM、阿里云等对云计算定义为三种服务模式，LaaS（Infrastructure as a Service 基础设施即服务）、PaaS（Platform as a Service 平台即服务）、SaaS（Software as a Service 软件即服务）。

LaaS 是云计算基础服务层，基础服务包括云主机、虚拟机、黑金物理计等，主要提供 CPU/内存等计算资源，国内供应商阿里云/华为云/腾讯云，是所有云计算基础能力，业务架构中了解基础知识即可无需特别深入。

PaaS 是云计算平台组建服务层（可以理解为技术中台），以 docker、kubernets 为代表容器化技术提供容器集群计算，用于建设技术中台，通过容器编排服务，可以快速建立满足高性能、高可用、可扩展的数据库、缓存、mq、logs、网关等，需要重点关注和理解。

SaaS 是云计算业务服务层（可以理解为具体实现业务逻辑层，包含业务中台/数据中台），以建设业务中台、数据中台等业务系统为核心，包括第三方供应商系统和后台系统。同样是由 docker、kubernets 容器技术提供应用运行环境，做到服务隔离和服务弹性。

所有的业务系统都是部署在服务器上，需要 CPU 和内存运行业务应用，需要接入互联网对外服务，需要 VPN 虚拟内网隔离服务，需要保存数据/图片/视频等资源，LaaS 提供的计算、网络、存储资源满足这些需求。

为保存具体的业务数据需要数据库，为应对大流量需要缓存和负载均衡，为应对高并发需要 mq 和容错等，为快速发布版本需要 devops，为排查 bug 需要 logs，为保证应用正常运行需要监控，PaaS 提供通用的技术平台组建，不论是什么业务都会用到这些组件做到复用平台组建，通过容器化技术可以快速建立满足高性能、高可用、可扩展的数据库、缓存、logs、网关等等。

用微服务框架实现的业务逻辑，具体有用户管理、商品管理、订单管理、财务管理、售后管理等。有客户端代码、有 API 接口代码、有宏流程模型代码。SaaS 就是具体实现业务逻辑地方。

四、业务中台架构

我们在 SaaS 层实现具体业务逻辑，有客户端、API、前台业务、中台 API、第三方供应商、后台系统（财务审核、OA 审批、客户管理）等。

客户端是 vue、react 为主 pc/h5 页面和小程序客户端、安卓、ios 客户端，以及开放给第三方 open API SDK。

网关是所有服务的统一和唯一 API 请求入口，拥有负载均衡、验证权限、分流请求、熔断请求、监控请求、公共服务统一逻辑处理等，网关组件往往会搭配 oauth2 作为登录授权验证，用户权限验证，搭配 erueka 作为 API 接口服务注册和发现，搭配 apollo 作为配置中心。可以发现下图中蓝色部分都是 PaaS 层定义平台组件部分，这些组件承担系统中公用和部分非业务逻辑事情。

中台 API 可以理解为宏流程模型具体实现代码，关注的整个宏流程模型的具体实现，例如中台 API 中有一个【外卖平台商品管理 API】接口，这个 API 做了外卖平台接口封装，调用这个接口就可以完成三个平台的商品管理。因为这个接口实现宏流程模型，除了基本的商品管理新增、修改、删除外不包含其他的业务逻辑。

这个时候有一个需求需要在客户添加商品成功后推荐类似商品给客户继续添加，这个具体的业务逻辑应该写在【前台业务】中，而不是中台 API 中。因为这个业务逻辑不是宏流程模型中的逻辑，不符合通用业务标准，同时也无法直接复用，因为推荐选项可能是商品类目推荐、也可能是商品名称相似推荐。

如果这个推荐业务上线后受到客户欢迎，是可以考虑纳入中台 API 中的。但是不应该修改宏流程模型，因为推荐不属于外卖平台管理的行业标准，准确来说这个属于数据中台的推荐能力，应该纳入数据中台中实现推荐 API。如果没有建设数据中台，那可以考虑新增一个中台推荐 API 模块，再修改【前台业务】把原有逻辑改为调用中台推荐 API 逻辑即可完成，这样中台推荐 API 成为可复用的能力。

通过前台业务和中台 API，即业务和领域模型逻辑分离，做到中台 API 的稳定性、复用性大大提高，前台业务具备快速响应市场变化和低成本试错能力。

五、微服务技术栈

技术栈没有最好只有最适合，根据技术团队对技术栈了解程度选择市面上成熟可靠有大厂在生产环境中使用过最好，中小企业微服务选型上以阿里、Google 成熟组建为主，我们以 Java 为例。

dubbo 是阿里开源微服务框架，提供一揽子微服务组件，包括 nacos、dubbo admin、dubbo rpc 等。

spring cloud 是 spring 家族中微服务框架，spring boot 算是 Java 开发应用标准框架，国内应用广泛。

kubernetes 是 Google 开源容器集群管理服务，具备服务发现、API 网关、配置中心组件功能，可以替代微服务框架来使用，云架构中 PaaS 和 SaaS 都可以用容器构建应用服务，做到服务弹性和隔离，降低业务运营成本，是当前市场上容器技术应用标准框架。

技术栈选择应该根据团队能力和人力资源成本考虑，优先选择技术上成熟稳定和资料丰富的，这样基本上不会遇到技术上难题，选择团队成员都能上手的，否则培训成本太高容易踩执行不规范的明坑，最后选择市场面广的好招聘人员。

六、SaaS 化的弹性服务

市场变化会直接影响系统的稳定性/可用性，首先是流量变化，当某一模块面对高涨流量时通过容器技术很容易建立多节点应对，例如美团外卖订单量这天指数级增加带来超出现有订单系统能承受最大峰值，我们可以通过 kubernets kubectl 快速新增一个订单中台模块 pod 节点，通过网关动态调整应对峰值流量，当流量下降后我们可以删除掉新增这个 pod 节点，做到需要时实例化，不需要就删除，不会浪费资源和成本。

其次是创新业务低成本试错，很多时候我们会尝试进入其他行业或热门市场中，需要产品研发团队能快速响应需求开发和上线，项目需要控制整个投入成本，例如是对业务基础上进行微创新，只需要多启动一个 pod 节点做前台业务实现，剩下复用中台接口 API。如果是全新项目没有可复用的，我们同样是启动 pod 节点，部署需要的平台组件和前台业务实现，成为一个独立的系统环境，后期就算失败也可以快速注销掉，不会影响其他系统。

七、产品研发成本

产品研发团队一直是企业成本中心，如何有效提高效率和降低成本，是所有互联网企业一直追求的命题，最直观的要求就是投入少、产出多、质量高，特别是创业公司在资源有限情况下，市场雄心很大，需求特别多，投入产品研发资源非常少，这种情况下也很难招聘符合要求和满意人才去实现业务中台、技术中台、数据中台，更别说云系统架构做到整个系统的复用和弹性。

在资源有限情况下更应该保证每个决策和动作都是有效的，每一个动作都应该计算单项成本，计算阶段性总成本，区分哪些动作是有效动作能带来收益，那些不是应该剔除。

云计算三种模式带来产品研发成本降低，LaaS 为我们带来一个月五百元的四核云主机，早期项目流量不多情况下， 可以暂时放弃用作高性能/高可用双节点和双备份，等流量上来需要稳定性时，通过 PaaS 可以几分钟内搭建起多节点和主从备份等，通过宏流程模型可以获得稳定业务中台 API，当需要快速响应需求和试错时候，可以实例化模型，生产具体前台业务逻辑满足市场需求。

八、系统篇总结

充分应用云计算特性发挥三种模式架构特点，构建复用能力的中台服务和弹性的 SaaS 化服务是云时代产品优势也是市场竞争利器。

九、组织篇预告

康为定律告诉我们组织架构会影响系统架构和业务架构，如何在云时代进行逆康威定律，做到业务架构指导系统架构进而指导组织架构。

本文由 @徐小威 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Pexels，基于CC0协议