网站架构的伸缩性设计

xman

　　网站开发初期，我们习惯性把所有代码都写到一个项目中。
　　前台、后台、缓存、数据库、静态资源... 等等。
　　网站系统物理分离
　　慢慢的系统会原来越大，很显然需要面对大量用户的高并发访问和存储海量数据。
　　很多用户的请求，不可能在一台服务器上完成。
　　很多缓存数据，数据库数据，也不可能在一台服务器上完成。
　　这是，网站的伸缩性架构就变得尤为重要。
　　如下图。

　　原理
　　我们通过多台服务器组装一个整体共同提供服务，通过不断地向集群中加入服务器，来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。
　　衡量架构伸缩性的主要标准：
　　是否容易向集群中添加新的服务器。
　　当加入新的服务器，是否可以提供和原来的服务器无差别的服务。
　　集群中可容纳的总的服务器数量是否有限制。
　　应用服务器集群
　　只要服务器上不保存数据，所有的服务器都是对等的，通过负载均衡设备就可以向集群中增加服务器。
　　关系型数据库集群(MYSQL)
　　关系型数据库的集群伸缩性方案必须在数据库之外实现，通过路由分区等手段将部署有多个数据的服务器组成一个集群。
　　例如：Mysql 等。
　　非关系型数据库集群(NOSQL)
　　非关系型数据库先天就是为海量数据库准备的，因此对伸缩性的支持非常好。
　　例如：Redis、Memcache 等等。
　　缓存服务器集群
　　加入新的服务器可能会导致缓存路由失效，进而导致集群中大部分缓存数据都无法访问。
　　部署前需要改进缓存路由算法保证缓存数据的可访问性。
　　静态资源服务器集群
　　比如 CSS，JS，Img 等资源进行部署到服务器集群，降低流量并提高页面呈现速度。
　　网站的纵向分离
　　将业务处理流程上的不同部分进行分离部署，实现系统伸缩性。
　　如下图。

　　网站的横向分离
　　将不同业务模块进行分离部署，实现系统伸缩性。
　　如下图。

　　单一功能通过集群规模进行伸缩。
　　将不同功能分离部署可以实现一定程度的伸缩性，但是随着网站访问量的逐步增加，即使分离到最新粒度的独立部署单一服务器也不能满足业务规模的要求。
　　因此，必须使用服务器集群，即将相同服务部署在多台服务器上构成一个集群整体对外服务。
　　比如：搜索功能。
　　如果一台服务器可以提供每秒1000次的请求服务，如果网站高峰期，每秒搜索访问量为10000次。
　　那么，就需要你部署10台服务器构成一个集群。
　　同理，缓存服务器也会出现这种情况。
　　事实上，计算一个服务的集群规模，需要同时考虑其对可用性、性能的影响及关联服务集群的影响。
　　总结
　　集群伸缩性，可以分为应用服务器集群伸缩性和数据服务器集群伸缩性。
　　这两种集群由于对数据状态管理的不同，技术实现也有很大的区别。
　　大家，可以根据每一种具体的架构设计进行深究。
　　文章借鉴于书籍大型网站技术架构。