最近的疫情极大的促进了云计算的应用，推动了企业SaaS化应用浪潮，这篇文章发表于2015年，先做些修改重新发布。
最近做SaaS应用的很多，这种模式是未来的一种趋势，这种模式的最大好处就是云计算的好处--节约资源。网上有很多人觉得SaaS很简单，就是一个多用户租赁模式。这种认识也不能说不对，因为SaaS确实一般都采用多用户租赁模式。但这种说法非常的不全面，是一种盲人摸象。而且很多人认为SaaS模式的架构非常简单，那就只能说他没有真正做过SaaS模式或者他们做的SaaS应用是一种非常低级的模式，根本谈不上是云计算的范畴，就是一个把局域网的东西放到了公网而已。
首先作为一种云计算模型，一个典型的SaaS模式需要以下三种计算模型支撑：
1）分布式计算模型
这是基本的模型，也是后两种模型的基础；现在非常火的Hadoop其实只是分布式计算模型中一种，而且并不是特别的复杂；由于物联网的实际落地，本质上边缘计算也是分布式计算的一种。
2）分布式数据存储和访问模型
这种模型很多，GFS，HFS，TFS都属于这类，当然一些分布式数据库包括阿里的Ocean数据库都属于这一类；分布式数据库访问和存取模型是SaaS企业应用的基础，对于企业级的应用底层数据节点不采用数据库当然是可以的，但如果采用数据库，好处也是非常多的，至少要简单很多。现有的分布式数据库对于SaaS应用，特别是SaaS企业应用来说采用GreenPlum这类数据库并不是不可以，但需要根据你的SaaS应用的业务本身进行权衡（主要是数据分离方式和效率的问题）。特别是牵扯到关联查询的时候，对于一个按用户分离和隔离的企业应用，如果数据节点采用关系数据库，那么80%的企业应用的关联查询都会落到一个节点中，查询的效率会比较高。如果采用分布式数据库，一般都很难做到这点，因为分布式数据库处理这类查询的时候，都需要把数据集中到一个节点进行处理，虽然可以采用一些策略来减少无效数据的传输，但往往效果不大。（分布式数据库中的A表和B表并不一定在一个数据节点的），这也是我一直以来的观点：对于分布式计算，通用往往代表着效率更低。我比较认同Google的GFS设计理念：面向应用设计接口。根据实际的系统目标选择适合的分布式模式非常重要，因地制宜。
3）分布式部署与运维模型
作为云计算下的SaaS应用，必须是可以支撑横向扩展（Scala out)的,而这些节点（包括应用节点和数据节点）的增加和管理完全靠人力去完成，基本是不可能的事情，因此只要是云计算模型下的SaaS应用，分布式部署与运维支撑模型就是必须的：应用程序节点的实时监控，管理和部署，数据节点的实时监控和部署，缓存节点的监控，管理和部署，文件服务器的监控，管理和部署等等。
以上三种模型就构成了SaaS应用的基础，但SaaS应用又有自己的特殊性，因为牵扯到商务逻辑、事务处理（高一致性和准确性）以及数据的整理和分离等，SaaS应用的分布式数据存储和访问往往不能简单的采用已有的一些开源分布式系统，或者一些开源的分布式数据库系统，因为在大型的SaaS应用中，数据的分割（分布的基础）往往也不能做到单一，而数据的分割又会影响数据访问的路由策略。这就导致通用型的做法不太适合具体的需求。
SaaS的这种基础实际上就已经非常具有技术含量了，而SaaS业务应用本身，在逻辑上就更难了，并不是访问数据库加上一个隔离字段那么简单。一般SaaS系统除了基本的多用户租赁（注意，设计SaaS的时候一定要以软隔离为基础，这样可以做到最大化的自由，而且不会影响数据库隔离和数据库实例隔离的需求 ）还会牵扯到在线许可，多时区，多语言，以及功能、页面、流程的可配置。特别是更深层次的应用更会涉及到在线跨企业资源共享和流程协作的问题，处理这类问题会非常棘手。特别是SaaS在线企业级应用，你需要面对的问题会更加复杂（业务规则的分与合）。如果在做架构的时候，如果没有考虑到这些问题，后面的噩梦会很多。甚至你可能玩不转。
SaaS应用其实并不简单，哪怕就是一个CRM在线应用，也是非常具有业务和技术含量的。根据我的分析，纷享销客和销售易虽然融了不少的资，但他们的系统架构还算不上真正意义下的云计算模式下的SaaS。金蝶，用友，速达的在线应用虽然没有深入研究，但通过他们用户的一些反馈，我感觉60%的可能性是伪云计算SaaS应用。当然，如果知道内幕的，可以告诉我。
SaaS企业应用涉及的点非常多，而且很多点之间是有关联的，因此你必须在这些问题点的处理中不断地进行平衡，进行取舍。比如，采用面向服务(SOA)的架构，在一定程度上是可以减少一些复杂性，但这样一来也降低了应用系统的整体性，SOA的粒度和边界的划分就是非常重要的权衡点。
在进行企业SaaS应用架构的时候，最好先弄清以下几个点：
1) 数据隔离和数据分布的路由策略；
2) 需要做哪些业务，是否需要做用户间进行资源共享和流程协作；
3) 如果需要资源共享和协作，那么这个过程中的用户数据归属问题；
4) 企业数据的规范性和统一性问题（这会涉及到参照，统计等后续一系列问题点);
另外在业务上，需要做到很多方面的平衡：“
1）通用化和定制化之间的平衡;
2）具体化和模板化之间的平衡;
3）易用性和业务性之间的平衡；
4）标准化和个性化之间的平衡；
5）结构化和非结构化之间的平衡；
6）固化流程和灵活流程之间的平衡;
7）易用性和可控性之间的平衡;
8）用户和权限的复杂度平衡；
9）单企业或多企业平台之间的可分析性平衡；
10）ToB管理软件中的管理和被管理之间的平衡;
。。。。。。
需要思考的问题其实很多，SaaS开发需要做的事情还是非常多。
SaaS的开发确实和原来单用户应用来说，难度大很多，但很多原来单用户应用或者早起多用户租赁系统的经验也还是值得借鉴。
补记：现在比较流行微服务模式，但SaaS模式其实不太适合采用微服务模式，特别是企业服务方面的应用。原因非常简单，微服务对事务处理不是很友好，另外就是业务系统业务之间的关系比较复杂的时候，微服务的调用关系就会非常复杂，从而变得非常难以维护。同时微服务下的某个服务数据量太大的时候，同样面临着横向切割的问题。但对于中台这种服务性的应用集合，做微服务还是没什么问题。
