伸缩性强调的时性能、容量等方面的可扩展。最理想的情况时，随着用户数的增大，系统架构不用做调整，而仅需要增加/增强相应的硬件设备（服务器、数据库服务器）即可。
实现可伸缩的最简单方式就是垂直扩展或向上扩展，即增强硬件设备。这种方式几乎是任何应用架构普遍适用的，但通常面临高成本的问题。
通常强调的应用架构具有可伸缩性，一般是指水平扩展或向外扩展。
实现应用服务器层的负载均衡，是实现应用服务器层水平扩展的最主要手段。具体实现负载均衡的策略有两种：
Apache可以实现负载均衡，根据服务器的压力情况，将每个用户请求分布到不同的应用服务器上。但是，大部分应用的用户请求可能是有状态的（一般使用Session记录用户状态）。这种情况下，如何能够在多台应用服务器之间保持用户状态，将是实现应用服务器层水平扩展的关键。在处理这个问题上，通常策略有三种：
很多应用服务器都强调支持强大的集群功能，Session复制就是强大的集群功能特征之一。
通过Session复制，大部分应用都可以实现应用服务器集群。通过增加应用服务器集群中的服务器数量，应用就可以达到水平扩展的目的。
以Apache+JBoss为例，配置Load Balance和Session复制。
为了避免Session复制带来的性能影响，可以使用Session sticky，这种方式将同一用户请求转发到特定的JBoss服务器上，避免集群中的session复制。
上面方式基础上，在Apache配置worker.properties中的worker.loadbalancer.sticky_session由0调整为1，JBoss不变。
session复制方式性能差，Session Sticky方式无法保证fail-over。使用集中式Cache来代替Session。
应用服务器层基本实现了完全的水平扩展，应用服务器层的压力基本上可以完全通过增加服务器进行扩展。集中式Session服务器采用MenCached，其本身也具备水平扩展能力。当Session数量大到一台Cache服务器都无法承担的程度时，我们也只需要增加相应的Cache服务器即可。
对于论坛这样的于其他模块没有紧密耦合的功能模块，其涉及的数据库表就首先可以垂直切分。
对于大部分应用而言，除非模块间的关联很少，否则实现垂直切分不容易：
对于读多写少的互联网应用，会广泛采用读写分离技术。例如MySQL的Replication技术就是被广泛使用的读写分离技术。
SaaS应用的不同租户之间在业务上没有任何关联，租户之间的数据是完全隔离的。只有很少部分的共享数据（整个系统全局性的一些配置信息），但它们通常都是只读的，是不允许任何一个租户更改的。
架构改造：
首先，租户和用户数据必须位于一个集中式的数据中。原因是在用户登录之前，系统是无法预知其属于哪一个租户的。
租户对应到那个物理数据库的映射，通常有两种处理方式（采用Hash算法；将租户对应到哪个物理数据库也做关系表存储在集中式的租户数据库中）
