大型web程序架构阶段（The 7 Stages of Scaling Web Apps）

原文地址：http://highscalability.com/7-stages-scaling-web-apps
标题：The 7 Stages of Scaling Web Apps
翻译：大型web程序架构阶段
* Stage 1 - The Beginning: Simple architecture, low complexity. no redundancy. Firewall, load balancer, a pair of web servers, database server, and internal storage.
第一个阶段：开始，架构简单，低复杂度，防火墙，负载均衡，一些web服务器，数据 库服务器，内部存储服务器。
* Stage 2 - More of the same, just bigger.
第二个阶段：更多的上面的系统设置。
* Stage 3 - The Pain Begins: publicity hits. Use reverse proxy, cache static content, load balancers, more databases, re-coding.
第三个阶段：痛苦开始，使用反向代理，缓存 静态内容，负载均衡，更多数据 库，代码重构。
* Stage 4 - The Pain Intensifies: caching with memcached , writes overload and replication takes too long, start database partitioning, shared storage makes sense for content, significant re-architecting for DB.
第四个阶段：痛苦继续，使用memcached 缓存 数据 库，数据 写以及发布占用时间长，开始数据 库分区，重新架构数据 库。
* Stage 5 - This Really Hurts!: rethink entire application, partition on geography user ID, etc, create user clusters, using hashing scheme for locating which user belongs to which cluster.
第五个阶段：要害处。重新思考整个项目，按照全局用户ID分区，创建用户集群，使用Hash确定用户属于哪个Cluster.
* Stage 6 - Getting a little less painful: scalable application and database architecture, acceptable performance, starting to add ne features again, optimizing some code, still growing but manageable.
第六个阶段：痛苦略微。大型应用程序以及数据 库架构，可接受的性能，开始添加新的特性，优化代码。
* Stage 7 - Entering the unknown: where are the remaining bottlenecks (power, space, bandwidth, CDN, firewall, load balancer, storage, people, process, database), all eggs in one basked (single datacenter, single instance of data).
第七个阶段：进入未知状态。哪里是瓶颈？（电力，空间，带宽，CDN，防火墙，负载均衡，存储，员工，处理，数据 库）。（简单数据 中心）。

 

===============================================================

===============================================================

• The 7 Stages of Scaling Web Apps (1286)

<!-- google_ad_section_start -->

By John Engales CTO, Rackspace. Good presentation of the stages a typical successful website goes through:
* Stage 1 - The Beginning: Simple architecture, low complexity. no redundancy. Firewall, load balancer, a pair of web servers, database server, and internal storage.
* Stage 2 - More of the same, just bigger.
* Stage 3 - The Pain Begins: publicity hits. Use reverse proxy, cache static content, load balancers, more databases, re-coding.
* Stage 4 - The Pain Intensifies: caching with memcached, writes overload and replication takes too long, start database partitioning, shared storage makes sense for content, significant re-architecting for DB.
* Stage 5 - This Really Hurts!: rethink entire application, partition on geography user ID, etc, create user clusters, using hashing scheme for locating which user belongs to which cluster.
* Stage 6 - Getting a little less painful: scalable application and database architecture, acceptable performance, starting to add ne features again, optimizing some code, still growing but manageable.
* Stage 7 - Entering the unknown: where are the remaining bottlenecks (power, space, bandwidth, CDN , firewall, load balancer, storage, people, process, database), all eggs in one basked (single datacenter, single instance of data).