Saas化产品和项目型交付产品能统一吗？

最新推荐文章于 2024-10-01 10:00:00 发布

置顶技道两进

最新推荐文章于 2024-10-01 10:00:00 发布

阅读量2.3k

点赞数 1

分类专栏： Saas软件文章标签： Saas 项目微服务前后端分离工业互联网平台

本文链接：https://blog.csdn.net/lzwdlut/article/details/106974743

版权

Saas软件专栏收录该内容

1 篇文章 0 订阅

订阅专栏

目前，在业务推进方面，产品和项目之争越来越多。归根结底，还是因为既有的Saas化产品如何应付传统企业项目交付的问题。本文从项目型产品和Saas化产品的关系，架构等方面尝试给出答案。

1. 前言

如果说为单个企业实施定制化项目是IT服务商的婴孩时期，通过产品积累以较低成本为多个企业实施定制化项目就是IT服务商的少年时期，通过产品SAAS化为所有企业提供满足个性化的服务就是IT服务商的青年时期，最终，通过产品的平台化为所有企业提供一体化的服务就是IT服务商的壮年时期。成长的过程是不可避免的，因为身边很多年少时期的客户，而花费很多精力去迎合他们，降低了自己的成长速度，并不是一个好的方法。
较好的办法就是通过开动脑筋，保持现有成长速度不变的情况下，满足年少客户的需求。
个人认为，SAAS化产品路线和项目化实施并不矛盾，是一个不断演进的过程，是同一事物的不同成长阶段。任何的SAAS化产品都是从项目型产品进化而来的。

2. 项目型和SaaS化产品

2.1 Saas化产品长什么样？

指标	SAAS化产品	项目型产品
云部署	√	×
多租户	√	×
可配置	√	√
可扩展	√	√
数据隔离	√	×
高可用	√	√
热部署	√	×
独立升级	×	√
数据可控	×	√
自助注册	√	×
可监控	√	×
浅色风格	√	√
新手导航	√	√
客户互动	√	×

从各项指标对比来看，项目型产品和Saas化产品确实不同。并且，从商业模式上也是不同的。但是否意味着为了项目需求和Saas需求，要走两条不同路线呢？个人认为，从商业模式上确实要走两条路，但在技术实现上是相同的。

2.2 技术实现的演进关系

Saas软件并不是天生存在的，是一步步演进形成的。公认的，按照成熟度等级可分为：

level 1:定制开发

最初级的Saas应用成熟度在应用架构上，跟传统的项目型软件应用架构几乎没有差别。在这种模式下，软件服务提供商为每个客户定制一套软件，并为其部署。每个客户使用一个独立的数据库实例和应用服务器实例。数据库中的数据结构和应用的代码可能都根据客户需求做过定制化修改。

有些 SaaS 软件公司专门为单一企业提供软件服务，也就是一对一的软件交付模式，客户可以要求将软件安装到自己公司内部，也可托管到服务商那里。定制能力是衡量企业管理软件好坏的最重要指标之一，这也是为什么有些软件开发商在 SaaS 早期坚持采用单重租赁的软件设计方案。

level 2: 可配置

第二级成熟度模型相对于最初级的成熟度模型，增加了可配置性。希望通过不同的配置来满足不同客户的需求，而不需要为每个客户进行特定定制，以降低定制开发成本。这是目前成熟的传统软件可以达到的程度。

但是，在第二季成熟度模型中，软件的部属架构并没有发生太大的变化，依然是为每个客户独立部属一个运行实例。只是每个运行实例运行的是同一份代码，通过配置的不同来满足不同客户的个性化需求。
多重租赁架构下的自定制或自定义功能是 SaaS 软件的另一核心技术，领先厂商的产品已经将自定制做到出神入化的地步。客户可以根据自己公司的业务流程，自定义字段、菜单、报表、公式、权限、视图、工作流和审批流等，做到 S a a S软件的量身定制，而且不需要编程
知识。

level 3:高性能多租户架构

多租户单实例的应用架构才是通常真正意义上的Saas应用架构。多租户单实例的应用架构可以有效的降低Saas应用的硬件及运行维护成本，最大化的发挥Saas应用的规模效应。不过，与传统的企业应用不同，Saas应用更具备互联网应用的许多特征。与传统单实例的企业应用相比，其数据量和并发量都会有明显的增加。因此，对于基于传统应用改造的多租户应用，还面临着大量的性能方面的挑战。

level 4: 可伸缩性的多租户架构

在实现了多租户单实例的应用架构后，随着租户数量的逐渐增加，集中式部属会成为性能瓶颈。需要通过一定策略实现水平扩展。随着租户数量的进一步增大，该架构可以保证仅通过再多部属几个实例来满足更多租户的使用。

因此，从项目型产品到Saas化产品是同一产品的不同成熟度等级。显而易见的是，如果实现了高成熟度的产品，则会兼容低成熟度的产品。即，实现了Saas化产品，完全可以满足项目实施对产品的要求。

2.3 关于轻量化的理解

**目前，有些工业化Saas软件给人的感觉就是轻量化——功能不多，只能满足基本的业务需求。那么，轻量化是否就是Saas软件的特征呢？没有那个Saas软件将轻量化作为它的特征。轻量化不是最终目的，满足需求才是最终目的。轻量化可以当作产品由小到大过程中的一个阶段或者是满足特定客户群体的一个产品版本。只要可配置性做好了，我们的产品完全可以做到按需变化，想轻量就轻量，想复杂就复杂。

如果非要说，Saas软件必须是轻量化的，也可以这样理解：依托软件平台，软件本身可以实现轻量化，即部分功能通过平台实现，减少软件本身的开发和维护工作量。这就要求Saas软件是基于平台的软件。平台可以是工业互联网Paas平台等。

2.4 如何兼顾项目实施和Saas化产品？

采用组件化技术，将系统划分成细粒度的模块，将不同模块甚至不同功能拆分成组件；
配置性，通过数据可配置、功能可配置、流程可配置及页面可配置，实现灵活配置；
统一管理，抽取公共业务组件，统一维护。如果组件无法同时满足，则拆分为更细粒度的组件。

2.5 小结

综上所述，采用Saas化架构，是历史前进的趋势。技术上讲，项目型产品是Saas化产品的最低成熟度等级，实现了高等级成熟度，则可以兼容低等级成熟度。商业模式上，项目型实施和Saas化推广是不同的商业模式。Saas化产品不等于轻量化。轻量化只是在产品无法满足各类用户个性化需求的情况下，一种折中的实现方式，是最终Saas化产品的一个阶段。可以采用不同的方式，同时兼顾目前项目实施的需求和未来Saas化需求。

3. SaaS产品实现和微服务架构

Saas化软件模式大约在2003年就出现了。而微服务架构大约在2014年出现。所以说，实现Saas化产品并不一定使用微服务架构。早期的salesForce,八百客，早期的阿里巴巴等的Saas化产品，肯定不是基于微服务的架构。但随着软件设计方法的不断发展，微服务架构也迎合了时代发展的要求。

3.1 软件架构演进历史

软件架构一般划分为应用架构和基础架构。其中应用架构是指构建业务系统本身需要关注的设计内容，而基础架构是指部署业务系统时需要考虑的设计内容。

基础架构演进路线为:

graph TD
  A[大型机] -->B[小型机]
  B[小型机] -->C[PC Server]
  C[PC Server] -->D[云计算]

应用架构的演进路线为：

graph TD
A[面向过程] -->B[对象组件]
B[对象组件] -->C[多层架构]
C[多层架构] -->D[微服务架构]

面对的业务场景为：

graph TD
A[科学计算] -->B[信息服务]
B[信息服务] -->C[企业应用]
C[企业应用] -->D[互联网+]

3.2 为什么选择微服务架构？

微服务的本质：一种更优的分工合作机制，加速分工，促进合作，帮我们成就更大的梦想！

从产品来说，各类自研应用采用微服务架构是是为了能够借助平台的力量，借助云计算的力量，成为有生命力的产品。这就要求我们的架构也最好使用分布式架构，以充分利用云计算提供的各层能力。传统分层架构，如MVVM,SSH框架等，是单体架构，不具备搭建分布式系统的能力，如果要将单体架构改造成分布式架构，还需要借助其他框架，如EJB等，才能实现。将来和工业互联网平台的融合，也只能是集成式的浅融合。

从工业互联网平台来说，工业互联网平台白皮书推荐的技术架构也是分布式微服务架构，也就是说是业内事实上的标准。这样，我们的平台可以将各类应用通用的权限、用户、消息等做成公共组件，统一维护，降低产品维护成本。另外，借助云计算能力，我们的平台可以集成大数据分析平台，智能决策平台，为各类应用提供高价值功能，使应用成为开放的，不断升级的产品。如果走不同的架构，那么需要两个团队来维护，还会有团队协同问题，难于管理。

从团队和研发管理来说，不会像以往的传统软件研发那样，需要依靠那些既懂业务，又懂开发的人员负责从业务到开发一条龙。这大大降低了对人员的要求，每个人只需要是单个领域的专家，促进了人员的分工合作，具备了把产品做大的可能性。

当然，微服务存在缺点，就是管理和维护复杂。当我们的产品规模达到一定程度后，微服务管理和维护会比较复杂，需要专业团队运维。