互联网系统架构演进.docVIP

互联网系统架构的演进 发表于2013-08-29 09:27| 14048次阅读| 来源《程序员》| 60 条评论| 作者杨光辉 《程序员》杂志2013年9月刊特别策划互联网系统架构技术架构性能系统 摘要：多终端接入、开放平台给互联网带来了前所未有的用户数量和访问规模，信息之多、传播速度之快，是传统网站难以想象的。本文将从发展演进的角度，解读高性能互联网系统架构。 多终端接入、开放平台给互联网带来了前所未有的用户量级和访问规模，SNS网站产生了海量的UGC（用户产生内容），而且这些内容依托关 系链扩散速度之快、传播范围之广是传统网站难以想象的，海量数据的计算存储也一直是近年互联网领域的热点。本文将从发展演进的层面探讨互联网的系统架构。 天下武功唯快不破 网站初期的架构一般采用“短平快”的架构思路，架构以简单清晰、容易开发为第一衡量指标。 互联网架构选型首先包括开发语言的选择，目前PHP、Java是主力语言。开发语言的选择一般从团队人员的知识储备、社区活跃度、商业应用的成熟度、招聘人才的人力成本等方面考量。 选择语言之后，一般会选择该语言的流行框架辅助研发，例如Java的SSH、Python的Django等。但这些框架并不是通常意义上的架构，架构一般可 分为物理架构、运行架构、逻辑架构、开发架构、数据架构等多个维度，框架往往只是代码架构的一部分。代码架构是指代码的组织形式、规范、设计模式等，框架 其实是常用设计模式的软件化。例如Struts是MVC模式的实现，Hibernate、iBATIS是ORM模式的实现。 在架构视图中，早期关注的主要是开发视图和数据视图，一般数据存储采用DB，初期数据的关注点主要是安全和备份，MySQL的Master-Slave模式可以满足该需求。 鸡蛋不要放在一个篮子里 采用“短平快”三板斧将网站开发出来之后，急需解决的是网站的可用性问题。可用性最基本的要求是不能有单点，对程序节点而言，前端可采用LVS、HAProxy、Nginx等负载均衡/反向代理设备。 DB的可用性就复杂了很多，数据库天然是有状态的，状态就是其中的数据，新增一个数据节点一般伴随着大量的数据复制和迁移。对金融行业而言，昂贵的商用存储是 解决之道，“IBM+Oracle+EMC”是该类系统的标配。互联网企业则一般采用较为廉价的方案，例如开源的DRDB+Heartbeat技术组合可 以在MySQL主库宕机时实现备机接管，接管时间可以控制在30秒内。 程序节点其实也可能存在状态，例如Web服务中常用的Session 就是保存在容器中的状态，这种状态保持要求所有相同用户的请求都在同一台机器上处理，无状态的程序节点才能水平扩展。无状态一般有两种设计思路，还以 Session为例，一种思路是把用户的状态保存在客户端Cookie，每次请求都把客户端的用户信息带到服务器端，淘宝的分布式Session就是该思 路的一种实现；另一种思路是状态保留在另外一个服务中，例如有些公司将Session放在分布式缓存中。 性能是生命线 去除单点之后的系统就可以水平扩展，架构如图1所示。但随着网站的推广运营，系统的规模开始扩大，此时可能会出现服务访问缓慢，甚至不可用的状况，如何提升系统性能就成了架构师的当务之急。 图1 去除单点之后进行水平扩展 存储架构和性能 互联网系统所有的性能瓶颈中，数据存储和访问速度往往是最重要也是最难解决的，选择合适的存储是系统的关键。存储的选择一般需要从多个方面考量，如成本、内容、用途和模型。目前主流的存储介质包括硬盘和内存两种。 对机械硬盘来说，1秒可以完成150次左右的随机I/O。而结合设计优良的Hash算法，内存查找可以每秒执行40万次左右。硬盘的随机读写能力决定了其读 写的最差性能，但操作系统在实现文件系统时会把最近读写过的数据缓存在内存中。由于磁盘访问和内存访问性能量级的差距，从操作系统的Cache命中率就可 以简单计算文件存储的性能，如果内存命中率可以达到80%，系统的I/O能力相较完全随机I/O将有5倍提升。 对于数据层服务器，大内存已成为标配（一般为100GB左右），如果DB中存储200GB的数据，根据8/2原则，Cache命中率应为87.5%，因此对MySQL而言，一般读写可以达到每秒1千次以上。 对于读写频率都很高、且可容忍数据丢失的场景，可以采用内存作为数据存储的介质。可靠的内存存储需要每次操作都记录Biglog，即使数据丢失也可以恢复，同时内存中的数据一般定期持久化到硬盘。 从功能角度考量，还可以分为持久化存储和Cache。持久化存储也可称为可靠存储，Cache是为了提升系统性能，在可靠存储的基础上建立的访问性能更加高效的数据读取节点，通常是内存存储，其架构一般如图2所示。 图2 持久化存储和Cache 存储的数据模