为什么重复制造轮子 – aLiLua

其实早在 2010 年我就在 Lua 用于 Web 开发方面做过尝试,当时还以 PaaS 形式对外提供服务的。但工作重点转移到云存储方向,并且服务也没见起色就停止维护了。

而到了 2013 年工作稍微轻松,想搞点小东西玩玩,也尝了把 node.js,但过程中发现基于回调的形式进行 Web 开发还是比较累的,开发效率相对于 PHP 低得多,尤其是业务逻辑多起来的时候。但 node.js 的异步处理效率很高,换用 node.js 是有得也有失啊。这让我再次想起 Lua,这个开发效率跟 PHP 一样快,同步逻辑的思维相对 node.js 来说清晰太多了。但之前做的 yo2lua 项目由于个人对 Lua 的了解不够深入,基于堵塞 IO 实现,可以说性能一败涂地。当时居然还搞什么 PaaS,搞笑了~(个人经验:回头看自己,会发现有很多sb,哈哈)既然这样我就重新搞搞 Lua 吧,aLiLua.com 这个域名在 2010 年做 yo2lua 的时候就注册好了,现在就以此名开展这个开源项目。

设计目的:
1. 开发简单、效率高
2. 运维简单、性能高
3. 稳定性高、资源消耗少
4. 满足 Web 开发中的常用功能需求

Lua 语言跟 PHP 类似的同步逻辑开发模式,满足开发效率要求。而 Lua 语言的运行效率可以说是这么多高级语言当中的佼佼者,满足性能高的要求。并且该语言至今已迎来第 20 个生日,在语言本身而言是非常稳定的。

为了简化运维和提高性能,所以决定采用 epoll 事件来驱动整个系统,而不是基于 nginx 来实现。(在第一版成熟后,会考虑其他平台的支持)当然完全自主实现有各有利弊,好处是可定制性高、相对的业务逻辑少,更纯粹于提供 Web 服务。

aLiLua 第一版所支持的功能列表:
1. cosocket (异步网络IO)
2. connection pool
3. HTTP/1.1 (keepalive)
4. gzip/deflate 压缩
5. session
6. 基于共享内存的 key/value cache (Yac weibo.com 在用)
7. template 模板引擎
8. sandbox (可用于做 PaaS 服务)
9. iconv/字符串处理
10. hooker/filter 钩子和过滤器
11. CLI 支持命令行模式
12. writev/sendfile 高性能的网络操作
13. ssl socket
14. mysql/memcached/redis/http client (由 ngx_lua 提供)

计划功能列表:
1. cron 定时任务
2. queue 任务队列
3. aio 文件异步IO
4. cluster key/value 存储支持集群分布
5. mbstring 字符串处理
6. Web Framework 基于 aLiLua 的 Web 开发框架
7. ssl server
8. msgpack rpc
9. …

在完成第一版时我对 Lua 和 node.js 等做了很多压力测试,性能跟 node.js 差不多,但如用 LuaJit 则高出 30%+。最主要的是 Lua 所消耗的内存和 CPU 都比 node.js 少,且占有率比较稳定。压力测试中使用的业务逻辑会比实际项目少,很可能实际效果比 node.js 更好一些。

aLiLua 是个新生的开发模式,底层兼容 ngx_lua ,大家可以先尝试用 aLiLua 来做些小应用 :) 我们提供免费终生保养服务。更希望大家在使用过程中能提出宝贵意见,以使 aLiLua 更完善

下载地址: https://github.com/yo2oneoo/alilua

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

在当前的网站架构中,经常会有较多的角色分工,如:缓存服务(文件型)、缓存加速服务(内存型)、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 的功能是配置节点在集群中的位置顺序。(做一致性哈希,这是必须的)

理解云计算

  现在互联网最热门的关键字“云计算”,大大小小的公司纷纷加入到这块领域。简单来说,目前的“云计算”主要分为:SaaS、PaaS和IaaS三大类。

  其中SaaS云计算,为软件即服务的概念。把传统客户端软件部署在互联网上,用户只需要一个浏览器就可以使用到软件的模式。其实早在2000年就已经有B/S结构的软件服务,与现在所说的SaaS云计算相近,但此前的B/S结构软件服务,数据库等服务端是需要用户自行部署的,而非由软件提供商进行统一部署。SaaS模式则由软件提供商统一部署并提供计算和存储服务。鉴于此特性一方面用户的使用成本降低很多,在软硬件的投入都大大缩小,但由此而衍生新的问题:数据保密和安全性。因为数据都是存放在软件服务商的服务器上,如何保障用户的数据保密性和安全性,将是SaaS模式在推广上的主要门槛。

  PaaS云计算,为平台即服务的概念。这是一种较创新的服务模式,PaaS云计算平台将为用户提供一个标准的、可扩展的应用计算与数据存储服务。用户可以在PaaS平台上开发并部署自己的应用程序,目前已有Google的App Engine(Java、Python语言)、Sina的App Engine(PHP语言)、HeroKu.com的App Engine(Ruby语言)和我们的Yo2lua App Engine(Lua语言)等多个PaaS平台。PaaS云计算要求用户使用平台所支持的开发语言,并以平台开发SDK为基础进行应用程序开发。按业界常规服务都会提供数据库和文件存储服务,其中数据库服务因需要做到云服务支持非常庞大的数据量,一般服务商多为基于key/value非关系型数据库为主,当然有技术实力的云计算平台还在此基础上实现类关系型数据库的特性,以方便开发者使用;而文件存储服务也是一个巨大的系统,可容纳PB级别的文件。

  目前大多数网站因其规模已有较多在使用云存储系统(文件/KeyValue DB),这部分就是我们一般说的私有云服务。这些系统一般只为其网站本身使用,而非公有云计算平台是为计算服务。

  对于PaaS云计算平台的数据保密和安全,同样是平台发展的主要门槛。但相对SaaS平台则要低一些,并且数据服务敏感度也没有SaaS类服务高。PaaS平台的数据存储服务为应用程序服务,平台方并不理会客户的应用存储什么类型的数据和数据结构,但SaaS平台则对于平台方更简单易懂,是由SaaS平台方制定的存储方案,最清楚的也是平台方咯 ;)

  IaaS云计算,为系统计算和存储服务为主。这是由原来虚拟机服务延伸出来的服务,(虚拟机:把一台服务器虚拟成多台服务器使用)就是我们在05年间开始流行的VPS虚拟服务器。但IaaS云计算跟我们此前的虚拟机服务有非常大的区别,老的虚拟机服务只是简单的在一台服务器上虚拟出多台虚拟的服务器,以供多种业务使用,但这些虚拟服务器的计算和存储都将局限在一台物理服务器上,并且要跟其他几个虚拟服务器共同使用这台物理服务器,计算能力和存储能力都无法达到一台物理服务器的效果。而IaaS云计算服务则可按客户需求,购买需要多快的CPU、更大的内存和磁盘空间,通常这些要求可以大于一台物理服务器;比如我可以个购买几个TB的磁盘,并且这个磁盘还会带有Raid备份,不需要担心硬盘损坏而丢失任何数据。

  IaaS云计算服务平台更侧重于提供硬件服务,客户需要在购买到的虚拟机上安装自己需要的操作系统,并部署应用服务。也因此IaaS云计算服务跟传统的应用程序兼容性最好,不需要客户对原应用程序进行修改就可以迁移到IaaS云计算平台上,享用云计算带来的多种好处。虽然IaaS提供的类虚拟服务器服务,看似没有数据保密和安全的问题,但可不要忽略虽然数据是一个虚拟的硬盘空间,但同样是可以被可获取到该磁盘映像的第三方读取。当然这个风险较PaaS平台和SaaS平台都要低。

  目前国外的亚马逊EC2和国内的阿里云、世纪互联和华为等企业都在发展自己的IaaS云计算平台。但目前国内的IaaS云计算平台与亚马逊所提供的云计算服务还有一定差距,国内还未有一个标杆服务,大家仍处于紧张的研发和测试阶段,并未出现国内的亚马逊 :) 但相信未来两年就会有的了。届时国内的IDC服务将被彻底颠覆(当然服务的售价可不能比普通托管服务器的费用还高)如世纪互联的服务,因其机房带宽资源比较优秀,但其云计算服务的销售价格偏高,相信一般网站不会轻易选择他们的服务。毕竟托管物理服务器价格比你低的话,那么IaaS云计算还有哪些优势来吸引客户?

  总结来说,PaaS和IaaS才是严格意义上的云计算平台,而SaaS只是一个云计算的服务场景。而PaaS云计算平台也包括一部分标准的IaaS平台服务,如:文件存储和数据库服务;IaaS云计算平台更容易让客户接受,但虽然客户在使用IaaS云计算服务与传统的服务器计算没什么区别,同样客户也是需要SA(运维工程师)来管理这些虚拟服务器,IaaS只是提供虚拟的服务器而已。

  现在来看,SaaS平台可以构建在PaaS平台或IaaS云平台上,PaaS平台也包括一些IaaS平台所提供的服务,而IaaS平台更接近传统的服务器服务、更容易让客户接受(现阶段是这样)

  依我看:未来云计算必然会是PaaS云计算平台为主,PaaS云计算平台可给客户更廉价、更简单的服务。

Yo2.com 回家了!~

  Yo2,多么熟悉的感觉。不过在我注册yo2域名时,yo2.com 已经被老外给注册了。退而求次购买了yo2.cn域名。04年cn域名还很好注册(但是要公司身份注册,所以有好多短的域名可供选择哦 :P )现在时代不一样了,时间很快就走了7年。.cn域名的注册量已经非常高啦。再想挑到个好点的域名来注册都挺难的~当然.com的域名就更难咯。

  不过近期的政策给我的信息是,.com 稳妥一些。而 yo2.com 域名一直是在荒废,注册者把它挂到域名拍卖的网站好几次,域名也是停靠在这些域名拍卖网站上的。早几年就想过把 yo2.com 买回来的(当然这笔费用肯定不小)苦于是 yo2 的起步阶段,未有这个能力。今年看到 yo2.com 停靠在 sedo.com 这个域名拍卖网站上,恰好又遇到被赶出国门的事情,使我的热火重新燃烧起来了 _-!!

  so~注册一个sedo帐号(居然注册还要签名验证,老外一点不马虎),尝试把 yo2.com 拍一下。经过一个月的拍卖过程(没有第三方加入,嘿好事),终于能跟卖家达成一个合适的价位 :P 。当然还是高,但还是把自己一直以来的心愿完成重要!~哈哈。

  上周四跑银行电汇,周一钱就到sedo公司的帐上了。接着周二开始正式进入域名转移的流程,期间sedo的客服帮了很多忙(居然还有中国人的客服,直接中文沟通联系,方便 :P )今天下午就正式转入到我在 godaddy 的账户上了。

  嗯,就是2010年04月13日,下午15点20分。Yo2.com 正式属于俺的了!~谢谢,谢谢各位乡亲父老。弟达成这个心愿了。当然这个域名肯定是Yo2使用,至于是否使用在博客服务上,或其他项目这还未有决定。(Yo2不只是一个博客服务上唷~我们还有更酷的产品呢:P)

  拭目以待!~Yo2.com 必将给你惊喜!