SaaS架构实现理论（四）可伸缩多租户

《互联网时代的软件革命-SaaS架构》学习笔记四

1.伸缩性（Scalable）的概念

伸缩性强调的时性能、容量等方面的可扩展。最理想的情况时，随着用户数的增大，系统架构不用做调整，而仅需要增加/增强相应的硬件设备（服务器、数据库服务器）即可。

实现可伸缩的最简单方式就是垂直扩展或向上扩展，即增强硬件设备。这种方式几乎是任何应用架构普遍适用的，但通常面临高成本的问题。
通常强调的应用架构具有可伸缩性，一般是指水平扩展或向外扩展。

2.应用服务器层的水平扩展

实现应用服务器层的负载均衡，是实现应用服务器层水平扩展的最主要手段。具体实现负载均衡的策略有两种：

• 基于硬件负载均衡设备实现负载均衡，这个方式更好但是贵
• 基于软件的方式实现负载均衡，例如通过配置Apache Http Server，下面介绍

Apache可以实现负载均衡，根据服务器的压力情况，将每个用户请求分布到不同的应用服务器上。但是，大部分应用的用户请求可能是有状态的（一般使用Session记录用户状态）。这种情况下，如何能够在多台应用服务器之间保持用户状态，将是实现应用服务器层水平扩展的关键。在处理这个问题上，通常策略有三种：

• Session复制
• Session Sticky
• 基于Cache的集中式Session

2.1基于Session复制的水平扩展方式

很多应用服务器都强调支持强大的集群功能，Session复制就是强大的集群功能特征之一。
通过Session复制，大部分应用都可以实现应用服务器集群。通过增加应用服务器集群中的服务器数量，应用就可以达到水平扩展的目的。

以Apache+JBoss为例，配置Load Balance和Session复制。

2.2基于Session Sticky的水平扩展方式

为了避免Session复制带来的性能影响，可以使用Session sticky，这种方式将同一用户请求转发到特定的JBoss服务器上，避免集群中的session复制。

上面方式基础上，在Apache配置worker.properties中的worker.loadbalancer.sticky_session由0调整为1，JBoss不变。

2.3基于Cache的集中式Session实现水平扩展

session复制方式性能差，Session Sticky方式无法保证fail-over。使用集中式Cache来代替Session。
应用服务器层基本实现了完全的水平扩展，应用服务器层的压力基本上可以完全通过增加服务器进行扩展。集中式Session服务器采用MenCached，其本身也具备水平扩展能力。当Session数量大到一台Cache服务器都无法承担的程度时，我们也只需要增加相应的Cache服务器即可。

2.4三种水平扩展方式的比较

3.数据库的水平扩展

• 数据库的垂直切分：将不同的功能模块所涉及的表划分到不同的物理数据库中，从而将对这些表的访问压力分担到多个不同的物理数据库中。
• 数据库的读写分离：同一个数据库在多个物理服务器上具有多份copy，彼此同步。然后将对于数据库的写操作都统一到一个主服务器上，而读操作则分摊到多台从服务器上。通过读写分离，实现数据库访问压力的分担。
• 数据库的水平切分：将原来存储在一个数据表中的数据，按照一定的规则，切分到多个不同的物理数据库中。每个数据库的数据结构完全相同，但是数据各不相同。最终对于业务的访问，会根据其数据所在的数据库，定位到某一个数据库中查询。

3.1数据库的垂直切分

对于论坛这样的于其他模块没有紧密耦合的功能模块，其涉及的数据库表就首先可以垂直切分。
对于大部分应用而言，除非模块间的关联很少，否则实现垂直切分不容易：

• 原本可能存在的表链接，需要想办法去除
• 原本同一个数据库的事务操作，可能会变成跨数据库的事务

3.2数据库的读写分离技术

对于读多写少的互联网应用，会广泛采用读写分离技术。例如MySQL的Replication技术就是被广泛使用的读写分离技术。

3.3数据库的水平切分

SaaS应用的不同租户之间在业务上没有任何关联，租户之间的数据是完全隔离的。只有很少部分的共享数据（整个系统全局性的一些配置信息），但它们通常都是只读的，是不允许任何一个租户更改的。

架构改造：
首先，租户和用户数据必须位于一个集中式的数据中。原因是在用户登录之前，系统是无法预知其属于哪一个租户的。
租户对应到那个物理数据库的映射，通常有两种处理方式（采用Hash算法；将租户对应到哪个物理数据库也做关系表存储在集中式的租户数据库中）

3.4三种数据库的睡哦扩展方案对比