SaaS架构设计

 对于SaaS应用的可伸缩，最理想的情况：随着用户数的增大，系统架构不用做调整，而仅需要增加/增强相应的硬件设备（应用服务器、数据库服务器）即可。而通常强调的应用架构具有 可伸缩性，一般指的是可以实现”Scale out”，即水平扩展或者向外扩展。而”Scale up”通常为垂直扩展或者向上扩展，也就是增强硬件设备，这种方式几乎是任何应用架构普遍适用的，但是通常都会面临高成本的问题。

      1、应用服务器层的水平扩展。实现应用服务器层的负载均衡，是实现应用服务器水平扩展的最主要手段，具体实现负载均衡的策略有以下两种：
      a.基于硬件负载均衡设备实现负载均衡，如F5设备。
      b.基于软件的方式实现负载均衡，例如通过配置Apache Http Server。

      Apache可以实现负载均衡，根据服务器的压力情况，将每个用户请求分布到不同的应用服务器上。但大部分应用的用户请教是有状态的（一般使用Session记录用户状态）。这种情况下，如何能够在多台应用服务器之间保持用户状态，将是实现应用服务器层水平扩展的关键。
      a.Session复制。Session复制的技术实现非常复杂，在大规模集群中实用性并不强，服务器之间大量的Session复制会严重影响这些服务器的性能。而随着服务器数量的增加，这种性能影响会显得更加突出，甚至不可接受。在大部分互联网应用中，Session复制技术应该是很少采用的。
      b.Session Sticky。为了避免Session复制所带来的性能影响，更简单、也是更高效的一种做法是Session Sticky。这种方式将同一用户的请求转发到特定的JBoss服务器上，避免了集群中Session的复制。Session Sticky的实现非常简单，但是这种方式不能满足fail-over的需求。即当一台应用服务器down的时候，这台服务器上正在访问的所有用户的Session都失效了，所有用户不得不再次重新登录。而且这种方式还容易导致负载不够均衡。
      c.基于Cache的集中式Session。这种方案通常使用集中式的Cache来代替本地Session。集中式的Session服务器采用的是MemCached，其本身也具备水平扩展能力。当Session数量大到一台Cache服务器都不能承受的程度时，我们也仅需要增加相应的Cache服务器即可。

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

实现方式	优势	劣势
Session复制	服务器负载可以得到较好的均衡，也可以确保fail-over的支持	Session复制会对服务器网络环境带来巨大的压力，尤其在应用服务器数量较大的时候，基本不适用于大型互联网，而且需要相应的应用服务器支持
Session Sticky	实现比较简单，在Load Balance层做相应的配置即可，不会带来Session复制引起的网络环境压力	不能实现完全的负载均衡，部分情况下负载会极端失衡，无法实现fail-over
基于Cache的集中式Session	应用服务器层无状态，可以实现完全的负载均衡，不会带来Session复制引起的网络环境压力	实现相对复杂一些，Cache本身可靠性不能绝对保证，可能会造成部分Session的丢失

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

      2.1、数据库的垂直切分。尽管数据库的垂直切分是最容易想到的，但对于大部分应用而言，除非模块间的关联很少，否则要实现垂直切分也不容易：
      a.原本可能存在的表连接，需要想办法去除。
      b.原本同一个数据库的事务操作，可能会变成跨库事务。可见数据库的垂直切分是一个可以适当采用，但很难广泛采用的数据库层扩展技术。

      2.2、数据库的读/写分离技术。对于读多写少的互联网应用，会广泛采用读/写分离技术。尽管Slave Database Server数量是可以线性扩展的，但是基于以下两个原因，Slave Database Server也不是越多越好。
      a.如果应用读/写比例不是很悬殊，单纯增加Slave Database Server对于应用性能提升并且没有特别的作用，通常情况下，Slave Server的数量与读/写比例对应。
      b.Slave Database Server过多可能造成Master-Slave之间的同步性能降低。

      2.3、数据库的水平切分。无论数据库的垂直切分还是读/写分离，对于实现数据库层的水平扩展，适用范围都比较狭窄。数据库的水平切分，通常有两种处理方式：
      a.一种是采用Hash算法。采用Hash算法实现更为简单，性能也高，但是扩展性略差。因为Hash算法一开始就确定，如果后面变更的话，会涉及数据的迁移。
      b.另一种是将对应到哪个物理数据库也作为关系表存储在集中式的租户数据库中。这种方式更为常见。在用户登录时，通过查询相应的关系表，即可以确定其对应租房的业务数据存储在具体的哪个物理数据库中。

      三种数据库层的水平扩展方案对比：

实现方式	优点	不足
垂直切分	实现简单	扩展能力有限，强关联的应用不容易垂直切分
读/写分离	可有效分担读的压力，主要在数据库层扩展，应用修改较小	对于读的比例不高的应用，扩展能力有限。依赖于数据库本身的同步能力
水平切分	SaaS应用中普遍适用，扩展性强，基本无限扩展	实现比较复杂，应用一般需要做较大改造。需要预先做好负载规划，后期数据迁移比较困难