《互联网时代的软件革命 SaaS架构设计》学习笔记
1、背景
云计算提供的强大软硬件环境和基础服务，将逐渐成为支撑SaaS应用的基础设施。各个云计算平台所包含的大量具有自身特色的公共服务，将为SaaS应用的开发提供了丰富的资源。而统一整合各个云计算平台的公共服务，也成为了SaaS服务集成平台SIP的发展目标。未来的SaaS应用将架构在又SIP整合的多个云计算平台上。
2、SaaS商业模式
2.1、什么是SaaS
ASP是Application Service Provider“应用服务提供商”，这种模式将用于需要的软件统一部署在应用提供商的软硬件环境中，软件运行所需的人力、物力资源都有提供商维持，而用户只需要在自己办公室使用这些软件即可。------重点在于提供有软硬件环境这样的服务，且网络带宽和软件技术上有限制，ASP用户体验不好，用户无法接受自己软件和数据交由第三方托管。
SaaS是Software as Service“软件即服务”，用户对软件的需求实际上是对应用服务的需求，而用户使用软件实际是在消费应用服务。软件的用户是服务的需求者和消费者，而软件的提供商是服务的提供者和生产者。----对于软件来说，离开软件提供商的支持和维护，很难真正用起来。
| ASP | SaaS | ||
|---|---|---|---|
| 不同点 | 看问题角度 | 站在软件开发商角度看问题，希望以一种新的新式向用户提供软件 | 站在用户角度看问题，考虑用户需要什么，搞清楚提供软件的本质是未来提供服务 |
| 不同点 | 关注目标 | 开发商只是为了解决用户硬件环境的持续维护问题，应用服务的统一托管 | 关注软件本身，是否能为用户提供有效的服务 |
| 相同点 | SaaS和ASP之间形似而神不似 |
2.2、SaaS软件的优势：
2.3、SaaS劣势：
- 对互联网的依赖，已经不是问题
- 数据安全性：传统软件用户数据存放在自己的电脑商或企业自己的服务器中，用户自己维护数据的安全性；-SaaS软件的数据库一般配备有双机热备分系统，实时备份用户数据。
- 数据保密性:传统软件数据由用户自己保管；SaaS软件商自身信用建设。
3.SaaS应用架构
3.1、SaaS成熟度模型
SaaS相对传统软件，将原本由软件使用者所承担的软硬件、网络、系统维护的费用，转成支付给SaaS服务提供商的租用费用；
对SaaS服务提供商，依然需要承担相应的软硬件、网络、系统维护等费用。除了降低软件使用者的第一次一次性投入成本呢，将一次性的投入转变为时间、需求的逐步投入。
| 比较项 | 传统软件200个客户的综合成本 | SaaS软件200个客户的综合成本 |
|---|---|---|
| 软件开发成本 | 取决与客户需求的异同，以及软件可配置性的强弱 | 1个软件开发成本 |
| 服务器成本 | 200台服务器 | 10台服务器 |
| 网络设备成本 | 200套 | 5-10套 |
| IT维护人员成本 | 200人 | 2-3人 |
3.2、SaaS成熟模型分级
SaaS软件要降低企业综合使用成本最主要的手段是发挥SaaS的规模效应。
规模效应是商业模式和应用架构，一般采用多个租户共享一个运行实例的架构（Multi-Tenant，多租户架构），高性能，可配置，伸缩性。
| 可配置 | 高性能 | 可伸缩 | |
|---|---|---|---|
| Level1 | × | × | × |
| Level2 | √ | × | × |
| Level3 | √ | √ | × |
| Level4 | √ | √ | √ |
Level1：设备托管
Level2：设备共享、可配置化
Level3：多租户、数据隔离、高性能
Level4：多租户、可配置、可伸缩
3.2.1、Level1 定制开发
软件服务提供商为每一个客户定制一套软件，并为其部署。独立数据库实例和应用服务器实例，数据库中的数据结构和应用的代码可跟进客户需求做定制化修改。
3.2.2、Level2 可配置
开发通用型产品，为满足不同客户的不同需求，通用性产品具有配置性，客户通过简单的配置满足自己的个性化需求。为每个客户独立部署一个运行实例，每个运行实例运行同一份代码，通过配置的不同需求满足客户的个性化需求。
3.2.3、Level3 高性能的多租户架构
多租户实例的应用架构可以有效降低SaaS应用的硬件即运行维护成本，最大化的发挥SaaS规模效应。
实现Multi-Tenant架构的关键是通过一定的策略保证不同租户间的数据隔离，确保不同租户既能共享一个应用的运行实例，又能为用户提供独立的应用体验和数据空间。
独立数据库、共享数据库独立数据结构、共享数据结构。
实现方式：
- 在传统企业应用的数据模型基础商，增加一个Tenant表，用于描述租户信息。
- 在大部分与租户有关的业务数据表中添加TENANT_ID 字段。
- 数据模型改造完成后，还需要改造登录逻辑，在会话记录用户属性的TENANT_ID。
- 在业务数据查询过滤时，都加上TENANT_ID =?过滤条件。
3.2.4、Level4 可伸缩的多租户架构
随着租户数量的逐渐增加，集中式的数据库性能就将成为整个SaaS应用的性能瓶颈，如果不进一步考虑数据库的分区设计，就只能依赖更强大的硬件设备来向上扩展。单一设备极限，导致SaaS架构无法满足低成本运营需求。
水平扩展在用户数大量增加的情况下，无需修改应用架构，仅简单增加硬件设备的数量，就可以支撑应用规模增长。
从Multi-Tenant SingleInstance系统扩展为Multi-Tenant MultiInstance。用户首先通过接入Tenant Load Balance层，再被分配到不同的Instance上，通过多个Instance来分担用户访问，实现水平扩展。
数据库实现方式：
Tenant Load Balance层会存放用户、租户、对应的Instance的映射关系，用户登录后即可通过映射关系，将用户重定向到相应的Instance。
3.3、如何选择合适的SaaS架构
考虑因素包括：
- 你的产品所面向的客户群的特征与需求；
客户是否原因接受共享应用的模型、个性化需求是否强烈 - 你的产品的租户数量级别；
成熟度高的SaaS产品开发成本（开发维护成本）更高，租户数量决定选择的成熟程度。
租户小于10个，多租户架构带来的收益并不大；大于50之后，多租户架构是SaaS的必然选择。
租户数量在10000以下时，可伸缩性无需考虑；租户在50000~100000甚至更高时需要重点考虑伸缩性 - 你的团队的开发能力与你们愿意付出的开发/改造成本
下一篇就多租户-高性能多租户-可配置多租户-可伸缩多租户具体实现解释
文章来源：https://www.toymoban.com/news/detail-786969.html
侵权请联系删除文章来源地址https://www.toymoban.com/news/detail-786969.html
到了这里，关于SaaS 架构基础理论（一）的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
