设计Web应用程序时要注意可伸缩性

Max Indelicato是一位软件开发主管和前首席软件架构师，他最近发表了一篇关于如何设计具备可伸缩性的web应用程序 的文章。他提出要选择正确的部署和存储解决方案，选择可伸缩的数据存储和模式，并且使用抽象层。

适合工作的工具

Indelicato的第一个建议是“为工作选择正确的工具”，想要达到这个目的，就要选择下列架构解决方案中的一种：

• 使用云部署解决方案
• 使用可伸缩的数据存储解决方案，像MongoDB、CouchDB、Cassandra或者Redis。
• 添加高速缓存层，像Memcached。

他认为在开始开发应用程序的时候，这些解决方案并不是必须的，但是在开始时就选择可伸缩的数据存储解决方案是很明智的，因为那会避免之后再进行切 换。将应用程序部署到云中会为我们带来一些好处，特别是对于创业公司来说，因为他们无法准确地确定他们的应用程序在启用之后会有多少人使用。将应用程序部 署到云中之后，当需求增加时，就可以让应用程序以优雅的方式进行伸缩。很多软件架构师都讲述了他们不得不对应用程序进行扩展的事件，其中他们会引入高速缓 存层，那会解决大部分问题。但是我们应该在设计阶段就考虑相应的解决方案。 这样在之后就很容易实现了。

可伸缩的数据存储

接下来，Indelicato建议选择支持分区、复制并且有弹性的数据存储，包括以下几种： MongoDB、Cassandra、Redis、Tokyo Cabinet、Project Voldemort，或者选择MySQL作为关系型数据库。这是很必要的，因为不管怎样，在应用程序的生命周期中，分区都是必要的。对于可伸缩性来说，分 区并不是必需的，但是对于“确保高可用性”就是必需的。灵活性可以让我们快速地增加更多的节点，这可能是出现流量峰值的时候，也可能是“由于硬件故障或升 级、大型的伸缩模式的变更或者任何需要让节点下线的情况下，需要对节点进行维护的时候。”

可伸缩的数据模式

Indelicato建议创建一种模式，从而让我们可以很容易地进行数据sharding，他还给出了下面的临时组件的例子，User和UserFeedEntry：

Collection (or Table, or Entries, etc) User
{
    UserId : guid, unique, key
    Username : string
    PasswordHash : string
    LastModified : timestamp
    Created : timestamp
}

Collection (or Table, or Entries, etc) UserFeedEntry
{
    UserFeedEntryId : guid, unique, key
    UserId : guid, unique, foreign key
    Body : string
    LastModified : timestamp
    Created : timestamp
}

然后他建议根据UserId进行分区：

通过根据UserId字段对User集合和UserFeedEntry集合分区，我们会将两种相关的数据块放在同一个节点上。所有UserId为 xxx-xxx-xxx-xxx的UserFeedEntry数据和UserId为xxx-xxx-xxx-xxx的User数据会被包含在同一数据片段 中。

为什么这是可伸缩的呢？ 因为我们对于这个应用程序的需求完全是针对数据的分发的。当每个访问者访问User的信息页面时，系统会向数据片段发出请求以获取User栏显示用户的详 细信息，然后再向同一个数据片段发出请求以获得用户的UserFeedEntries。这两个请求中，一个会获得一条数据，而另一个会获得多条数据，而这 些数据都包含在同一数据片段中。 假设在一天之中对大多数用户的信息都有相同次数的访问，那么我们已经设计了可伸缩的模式，它会支持我们的web应用程序的需求。

使用抽象层

Indelicato的最后一条建议是使用下述抽象层中的一种，但不仅限于这些： 元数据库（Repository）、缓存和服务。当创建元数据库层的时候，他建议：

不要以针对你所抽象的数据存储特有的方式来为方法命名。 例如，如果你抽象的是关系型的数据库，一般我们会为了执行SQL查询和命令而定义Select()、Insert()、Delete()、 Update()函数。不要这么做。 相反，应该让你的函数名不那么专门化，可以使用Fetch()、Put()、Delete()和Replace()。这会确保你更好地遵循元数据库模式， 并且当你需要切换底层数据库的时候，工作会更简单。

如果可能的话使用接口（或者抽象类等等） 将这些接口传递给应用程序中更高的层，这样你永远不会直接引用元数据库的特定的固有实现。这对于构建和单元测试也是非常棒的，因为你可以编写其他固有实现，它们会预先带有与测试案例相关的数据。

将所有针对存储的特殊代码封装到一个类（或者模块等等）中，真正的元数据库会引用或者继承它。只在每个函数中放置针对存取函数所必需的细节（查询语句等等）。

时刻要牢记，并非所有元数据库都需要抽象相同的数据存储解决方案。只要你愿意，你可以将User存储在MySQL中，而将 UserFeedEntries存储在MongoDB中，元数据库要以这样的方式实现，它们支持这么做而不需要付出太多代价。之前的三点建议也间接地有助 于我们做到这一点。

Indelicato说，对于高速缓存层，在开始时他经常会使用“简单的页面（或者视图等等）级别的缓存或者服务层的缓存，因为这是两个不会经常发生状态变更的区域。”

Indelicato认为需要对服务层进行足够的抽象，这样当需求增加时，我们可以很容易地从服务的内部实现切换到进程之外的实现。

有些人认为在构建应用程序的时候不需要考虑可伸缩性问题，因为那会在必要的时候得到强调。 但是如果我们想要从开始就考虑可伸缩性，你还有什么好的建议呢？