充分发挥服务器的各项资源

在当前的网站架构中,经常会有较多的角色分工,如:缓存服务(文件型)、缓存加速服务(内存型)、PHP/Java 计算服务和数据库服务等等。每种服务对服务器的资源占用各有不同,例如:缓存加速服务就需要大量的内存,而 PHP/Java 计算服务则需要占用大量的 CPU 资源。如何充分发挥单机的资源利用,往往是运维的同学负责规划。认为的来进行分配,必然会有所疏漏,也正因此现在发展出 VMware 类虚拟服务器的云计算,可以实现一定的自动分配资源,达到节省成本的效果。

但使用 VMware 类方案并不太适合单个企业选用,原因一:架设一套自主的虚拟机集群,会产生软硬件成本,二:虚拟服务器系统本身要消耗掉一小部分性能。或者我们可以考虑以下方案 :) 可在原有的业务基础上进行简单的梳理,以达到需要的效果。

我们把服务器抽象出,磁盘、内存和 CPU 三项资源。服务角色可把 PHP/Java 归为计算类型,而 Memcached/Redis 等归为内存类型,对文件/页面缓存归为磁盘类,数据库较为特殊,它对三类资源的需求都比较高,将其定位特殊的全需求类型。

现在资源和服务类型都很清晰了,那么我们就可以针对服务器的三项资源进行网络化,抽象出三小块分布式服务。PHP/Java 计算类型,可在Web Server层加入分布式逻辑,使得业务可自动均衡的分配到服务器群;对于 Memcached/Redis 这些缓存加速服务基本都带有分布式支持能力;而磁盘类型的业务则需要找到一个适合业务所需要的解决方案(如业务本身对文件名没要求,那可考虑 FastDFS 类分布式存储系统,否则可考虑 MongoFS 类存储系统)以此我们可以构建出下图所绘的架构:

此架构不仅能让服务器的各项资源得到充分发挥,还具备分布式计算的热备能力,并且单台服务器的软件、配置环境标准化,可减少运维的工作量,日常维护也更加方便。是一举几得的好事!以下为我们某个业务的服务器组状态:

上面这组服务器,我们部署有 PHP/Memcached/MySQL 和一个分布式文件系统。

题外话:这素云计算的基础形态麽?嗯,有点云的意思,当然未能达到这个高度。主要因这个方案是非常基础的,仅适合单网站(公司)使用,如果非要说云,那只能说私有云。而要做公有云,我们还需要在此架构基础上,加入安全隔离、资源租赁和统计等很多子系统。

此文撰写于昨晚国航灰机晚点的几个小时里~晚上10点的票居然凌晨3点才到家~故留此印记。

使用 Nginx 构建一个“高”可用的 PHP 集群

  跳过没必要的介绍,直接进入主题。目前建立一个高可用集群的方案不少,可以使用硬件或软件 LVS 类构建,现在我说的方案是只用 Nginx 来进行构建。

  这个集群的架构如下图:

  上面我们共部署了5个节点,每个节点上配有 Nginx + PHP。这个架构的重点就在于,Nginx 不只是与本机的 PHP 通信,整个集群应该把 Nginx 部分抽象到面向业务的第一层,而 PHP 则在第二层。每层都为多节点均衡架构。

  其中 Nginx 层面使用 DNS 均衡实现,DNS 负载均衡是一个很传统的方案,在单个域名下绑定多个 IP 进行轮循,可有效的把业务请求分发到多个节点上,但某节点故障时则需要有相应的解析处理,把故障的节点从 DNS 记录中删除。目前推荐使用 DNSPOD 的解析服务,可支持 API 操作。这样我们就可以自己建立一个服务器状态管理的程序,自动切换 DNS 解析。(注意:域名解析的切换需要 5~10 分钟,当然这是由域名解析记录的 TTL 值决定,为避免大量的 DNS 解析影响请求打开速度,建议 10 分钟或以上为佳)

  第二层 PHP 则由 Nginx 使用 upstream 实现均衡,Nginx 本身的 upstream 就已支持节点健康维护的功能,可以放心的交给 Nginx 来做。而如果 PHP 业务层带缓存功能,则要考虑使用一致性哈希模块来实现 upstream 的均衡策略,否则节点故障对整个 PHP 集群的缓存造成大幅度的震荡。根据我们测试的数据,在普通哈希策略下,一个节点故障会导致 90% 的缓存失效,而使用一致性哈希则可降低到 50% 。并且我们的 Nginx 一致性哈希模块,还可以把故障节点的请求分发到邻近的节点,可以再提高部分缓存命中率,使得整体提升到 70% 的样子。

  这样一个架构方案给我们实现了一个“高”可用的 PHP 集群,并且没有单点故障的隐患存在。DNS 解析服务是多节点,Nginx 层是多节点,PHP 层更是多节点的模式。如使用 LVS 方案,LVS 服务本身也要做一套热备,才能避免单点问题,且增加了架构复杂性。

  应该选择那套架构方案还由业务决定,这里我只是提供一个新思路罢了 ;)

  Nginx 一致性哈希模块:ngx_consistent_hash-1.0.tar

             ngx_consistent_hash-1.1.tar.gz (Fix nginx reload bug)

  使用方法:

upstream backend {
server 192.168.1.101 weight=1;
server 192.168.1.102 weight=2;
server 192.168.1.103 weight=3;
server 192.168.1.104 weight=4;
server 192.168.1.105 weight=5;
consistent_hash $host$request_uri 2;
}

  consistent_hash 支持2个参数,第一个参数为哈希字符串,第二个参数为备份节点数量。当某节点故障时,将把该节点的请求分发到2个备份节点上。当然你可以设置1或更高,建议2为佳 :)

  模块对 nginx 原 upstream 模块的 weight 节点权重功能进行了替换,weight 的功能是配置节点在集群中的位置顺序。(做一致性哈希,这是必须的)

Yo2Lua App Engine 一个全新的应用开发模式

Yo2Lua App Engine 简介:

  Yo2Lua App Engine (简称 YAE)于2009年开始研发,并在2011年5月正式推出第一个Alpha版本的公有云计算平台( http://yo2lua.com )。

  YAE 通过借鉴 PHP 语言的众多功能,来完善 LUA 语言在 Web 开发场景中所需要到的功能,充分模仿 PHP 的函数方法,让开发者可以很简单的从 PHP 语言转入到 LUA 语言开发环境。

  YAE 向用户提供一系列分布式计算、存储服务,包括分布式文件系统、分布式数据库集群、分布式缓存、分布式定时服务等。在这些服务基础上, YAE 更引入多个开放平台功能,以创新的模式提供给开发者使用。如:手机短信接口、网易微博开放接口等丰富多彩的应用。

关于 LUA 语言:

  Lua 是一个小巧的脚本语言。作者是巴西人。该语言的设计目的是为了嵌入应用程序中,从而为应用程序提供灵活的扩展和定制功能。它的主页是 http://www.lua.org

  Lua最著名的应用是在暴雪公司的网络游戏WOW中。

  更多信息请查阅:http://yo2lua.com/wiki/lua/

使用 YAE 进行开放平台的应用开发:

  YAE 已经把开放平台的 API 进行了完整的封装,开发者点下按钮就可以把开放平台的 API 接口集成到你的应用开发环境,形成简单的函数调用。

  如腾讯微博获取首页动态的接口是:weibo.qq.statuses.home_timeline()

  由此开发者在使用 YAE 进行应用开发的门槛和周期都大大降低,并且托管在 YAE 公有云计算平台上,开发者不再需要为架构而折腾,这些由 YAE 提供服务。

  对于应用开发者,YAE 带来的好处有:

  • 硬件成本更低,无需预先购买设备,承担更大的投入风险
  • 开发成本更低,YAE 提供许多服务供开发者使用,开发者无需重复开发,包括队列、数据库、缓存、定时、验证码、计数器,几乎覆盖了Web开发的所有领域。
  • 运维成本更低,在 YAE 上的应用无需关心硬件维护、服务监控、数据容灾等操作,YAE 会通过其高可靠的架构和方便的监控页面为用户将运维成本降到最低扩展性更强,在 YAE 上的服务无需关心服务压力猛增时带来的扩容等操作,YAE 自动支持服务扩展
  • 更加安全可靠,前端防攻击、代码检查等功能,在 YAE 上的所有应用均为多机房容灾部署,比传统的部署模式更加安全可靠,并且 YAE 提供服务的 SLA 来实现对用户服务质量的承诺

  数据库热备?有木有???负载均衡?有木有???

  都有 :) YAE 是云计算平台,你的应用会被分布到多台服务器上执行。并且我们可以确保没有单点故障,而导致你的应用访问受限。

YAE 作为开放平台应用托管服务商,我们到目前已接入的开放平台有:

  • 腾讯微博
  • 网易微博
  • 手机短信接口

  在未来半年我们还会加入更多第三方接口到我们 YAE 平台上。帮助开发者从众多第三方接口 API 中抽身出来,专注于做好自己的应用功能。