从项目开发到云端架构(16)

5      PaaS DIY

       PaaS是一个软件层，通常连接网络资源包括操作系统实例、数据库服务器实例、网络服务器实例，甚至负载均衡，并连成一个单一的，共享的逻辑承载层，提供按需硬件和操作系统服务，而且还提供应用程序平台和解决方案堆栈。

       PaaS 服务可将与应用程序部署关联的大多数 IT 管理方面自动化，包括资源配置、分段和测试、负载平衡、数据库访问以及访问平台库。PaaS 的关键功能是多组织体系结构：即多个不相关的应用程序可运行在相同的硬件和软件基础设施上，从而节约成本以及更有效地利用计算资源。开发人员只需关注应用程序本身，而不需要关注部署和 IT 问题。

      

       那在本章节里面，我们自己根据对PaaS的理解和体会，自己动手拔一拔paas系统里面的这些东西，正如“幸福要靠自己勤劳的双手”一样，要感知或者实践paas平台对业务系统的支撑和帮助，就要对Paas内部也要需要深入的了解，打开黑匣子，搜集一些相关的工具和零件，搭建自己的Paas平台。个人认为paas平台其实不算复杂，只是比10年前搭建SSH框架要稍微复杂一些，呵呵，这样吧，现在旮场。

 

       我们假设几个场景，分布针对不同规模的业务场景。正如前文所述：传统的web应用的架构，在用户期望移动设备和桌面有更佳体验的要求下已经不堪重负，新的架构呼之欲出。也就是说Paas平台帮我们解决部署上的麻烦：简单的部署 + 应用的管理 + 简单的扩展；并提供一些基础平台服务：WEB应用服务器 + SQL数据库 + NoSQL数据库 + 内存服务器 + 消息服务器；但我们自己的web应用需要实现：在应用层面的可水平扩展的服务器 + 模块化的组件，可被拆分和扩展 + 异步的架构，在数据层面的复制 + 分片 +多存储（关系数据库，nosql，内存等），这样应用的业务架构示意图如下：

 

 

 

图50-01 推荐模式

 

       在这个通用的业务架构中，其特点为模块松耦合+请求无状态+通讯异步化。业务架构和paas平台各司其职，相互分工协作。从cloudfoundry到cloudify再到Jelastic，部署越是简单的，它的业务扩展能力其实就是越弱，到了Jelastic，虽然部署非常的简单，简单到只有传个war包即可，但性能的伸缩完全依赖于paas的route（这里是nginx）来实现，扩展有限。所以好的paas平台，不单单是看其提供服务的多寡，支持的语言丰富，还要看是否为部署的应用架构提供了高可用，可水平扩展的业务架构模式。

       前文阐述了paas的功能，假设我们需要为自己手头上一堆运行着web和db的服务器实例进行管理和部署，如果按照paas的能力强弱进行等级划分，自己DIY一把，看看能提供什么，需要什么，我们自己又能做些什么。

5.1  DIY before

       在diy之前，还有些准备工作需要去做，一些基础知识需要了解。PaaS平台中堆砌了大量的开源软件，它的运行机制其实不会超出我们平时的理解范畴之外，只是选择了某种分布式模式，进行了合理的搭配以及作了自动化处理，有些组合和彼的衔接，所以了解常用的开源软件以及它们的工作方式与应用特点，对于我们的diy大有裨益。这些知识点大致的梳理了一下，我分为如下的内容：

知识点	说明	备注
11.web应用	互联网常用和web相关的应用，包括： apache，tomcat，warnish，squid ，memcached，redis
12.备份恢复
13.网络存储
14.运维监控	Nagios，caicti以及日志管理等，对系统进行监控
15.性能优化	针对架构层面的对系统的优化
16.应用集群	包括了tomcat，nginx，lvs的集群方式
17.数据集群	数据库的集群方式，在互联网中一般采取mysq，借助drbd和heartbeat的能力
18.通用服务	在互联网应用中常用的，包括： 防火墙，dns，vpn，邮件服务器等
19.部署架构	业界通用的集群部署架构模式，通常有 Lvs+keepalived / nginx+keepalied Drbd+heartbeat+nfs/mysql 的混合模式 其中会涉及到几种session的管理方式，paas平台的负载均衡能力也是之前所述方式的一种	通用的模式在这里说明，大中小项目中再举具体的范例
20.持续交付	对于营运类型的项目，会持续的更新和部署，需要采用合适的脚本和持续集成来进行 典型的包括puppet/chef+svn+jenkins	主要在diy after章节阐述

表 51-1：diy知识点

 

       这里和paas diy比较紧密关系的是部署架构，顺带会穿插阐述应用集群和数据库集群以及web的服务相关的内容，所以在diy before的章节中说明；持续交付和运维监控，则是运营和管理的内容了，自然在diy after的章节中阐述。

 

5.1.1            基础介绍

 

       负载均衡：在现有网络结构上提供廉价方式来扩大服务器带宽，增加吞吐量以及数据处理能力。常用负载均衡的硬/软件如下，按照均衡能力排列：

• F5 big-ip ：可以作 4-7 层的负载均衡，因为是硬件，自然均衡能力是最好的，并提供 12 种均衡能力的算法、会话保持功能以及自动检测故障机器等功能。
• LVS ：是一个负载均衡 / 高可用集群，具有 3 层结构（ load balancer/server pool/shared storage ），提供 3 种实现虚拟机实现方式（ vs/net ； vs/tun ； vs/dr ），特点是：
  • 在负载均衡软件里的性能最强；因为在网络 4 层之上仅作分发之用，没有流量产生。
  • 配置性比较低，所以并不需要太多接触，减少人为出错的几率。
  • 工作稳定，自身有完整的双机热备方案，如 LVS+Keepalived （推荐） 和 LVS+Heartbeat 。
  • 无流量，保证了均衡器 IO 的性能不会收到大流量的影响。
  • 应用范围比较广，可以对所有应用做负载均衡。
  • 软件本身不支持正则处理，不能做动静分离 ，可以结合 nginx/HAProxy+Keepalived 。
• HAProxy ： HAProxy 是一款提供高可用性、负载均衡以及基于 TCP （ 4 层）和 HTTP （ 7 层）应用的代理软件。
  • 免费开源，稳定性也是非常好，稳定性可以与硬件级的 F5 相媲美。
  • HAProxy 支持连接拒绝，这个优点也是其它负载均衡器没有的。
  • HAProxy 支持全透明代理（已具备硬件防火墙的典型特点）。
  • HAProxy 现多于线上的 Mysql 集群环境，我们常用于它作为 MySQL （读）负载均衡；
  • 带强大的监控服务器状态的页面，实际环境中可结合 Nagios 进行邮件或短信报警。
  • HAProxy 支持虚拟主机。
• Nginx ：基于第 7 层的负载均衡，支持 http 和 mail 的均衡，特点：
  • 承担高的负载压力且稳定，一般能支撑超过几万次的并发量 ;
  • 工作在网络的 7 层之上，提供的正则处理比 HAProxy 更为强大，轻松实现动静分离。
  •   对网络的依赖非常小，能 ping 通就就能进行负载功能。
  • 可通过端口检测到服务器内部的故障。
  • 仅能支持 http 和 Email 。
  • 作为中间代理层，对于大型网站可能的架构为 F5/LVS à Nginx( 多台 ) à web 集群。

 

       高可用：狭义说是主机的冗余接管，广义说是整个系统高可用的能力，并和lvs/haproxy/nginx结合起来，形成负载均衡/高并发的生成解决方案。

• Keepalived ：运行在 lvs 之上，主要功能是实现真实机的故障隔离和负载均衡器之间的失败切换（ failover ），工作在第 3/4/5 层。 keepalived 产生的虚拟 vip 就是整个系统对外的 ip ，如果最外端的防火墙采取的是路由模式，那就映射此内网 ip 为公网 ip 。
• Heartbeat ：和 drdb 一起应用于在线的高可用文件系统；也是 mysql 官方推荐的实现 mysql 高可用的一种手段。
• DRBD ：分布式复制块设备，支持 3 种复制协议：异步复制协议，内存同步，同步复制。在线项目可以采用协议 3 ， drbd+heartbeat+nfs ， drbd+heartbeat+mysql 。

 

5.1.2          部署层次

       典型的互联网系统架构一般分成负载均衡层、网页缓存层、 WEB层和数据库层和文件服务器层。这里在了解每一层在网站设计中的作用和重要性，找出网站瓶颈加以优化，将网站打造成高可用高可扩展性的网站。下面从和5个层面依次讨论

 

1、负载均衡层

• Lvs+ Keepalived 模式 : 现在 linux 系统已经内置了 lvs 功能，为了避免 lvs 的单点故障的出现，采取主备模式，有 2 种高可用软件，这里采取 keepalived ，本身 keepalived 就是为 lvs 设计的，监控集群系统种各个服务节点的状态。 LVS 在性能方面是最好的，尤其是后面的节点 ( 如 Web 或 MySQL 数据库服务器 ) 超过 10 台时，它的性能是最优异的。
• HAproxy+Keepalived 模式  
• Nginx+Keepalived 模式 : 负载均衡层采取 nginx ，用 keepalived 作 HA 。因为 nginx 在正则处理以及分发和动静分离效果好，在 backup 机实现 cacti+nagios 实现实时监控。如果不在 web 层处理 session 问题，那就在负载均衡层处理，采用粘性会话能力，启用 ip_hash 功能。不过因为自身限制，只能支持 web 集群和 mail 集群。
• Lvs + Keepalived + nginx 模式   Nginx 作为最前端的负载均衡并不是一个非常理想的选择，一个大型的网站或系统的 话，可以存在多级代理，最前端可用 F5 或 LVS 来作为网站或系统的入口，让它们来顶外部的高并发流量，而 Nginx 由于其强大的正则处理能力，可以作为中层代理，一来可以作为 F5/LVS 的补 充，节约大量成本，形成 F5/LVS -->Nginx( 多台 )-->web 集群的模式：
  • Nginx 负载均衡不存在单点；
  • Nginx 作为 F5 的补充，利用 upstream 模块和正则，实现动静分离；
  • 压缩可以通过 nginx 做，后端应用服务器可以不用考虑压缩，提供通用解决方式。
  • 方便的运维管理，在各种情况下可以灵活制订方案；
  •   即使没有 squid 群组， Nginx 现在可以做为优秀的反向代理加速软件了。

  

2、网页缓存层

       网页存储，通常使用squid/Varnish来架设。如果没有独立的web缓存服务器，可使用nginx本身的功能。varnihs是一款比squid更好的产品，网聚的同事已经在使用。

 

3．WEB层

       WEB层这块压力比较大的网站现在都换成了Nginx作为WEB应用服务器，事实上，它的抗并发能力确实超过了预期，高峰期时Nginx并发达到了一万以上，这个是很可观的数字了。

Session管理

•   粘性会话（）
• session 共享（基于 cookie ，基于数据库，基于缓存）

 

会话保持：识别客户和服务器交付过程的关联性，在负载均衡的同时，保证一系列相关联的访问请求被分配在同一台服务器上。

• F5 big-ip ：简单会话保持，基于 cookie 会话保持， ssl session id 会话保持。
• Lvs ： persistence 机制
• Nginx ： upsteam 模块的 ip_hash 机制。
• Haproxy ： balance source 机制（默认是轮询）

 

 

 

 

图 51-01：网站部署

 

       这里包括http加速服务器，数据缓存服务器以及共享式文件存储。这里用tomcat/jetty泛指web应用层，在具体架构的时候，也许这里会被拆分为业务拆分或者前后端拆分，这里用简单框图来表述。整个负载均衡层和Web层的工作流程为LVS_DR/nginx+Keeaplived→Nginx反向代理（动静分离）→Tomcat集群，可以保证整个网站不会因为某一台LVS/nginx或Nginx+tomcat机器挂掉而影响网站的运营。如果采取的是lvs+keepalived，tomcat之前一定需要nginx，因为部署的网站一般都会有动静分离、正则分发的需求。

       web服务器由nginx+tomcat来处理，提供反向代理，动态静态资源分离和静态文件压缩。

       Web缓存层被独立层单独的一层，使用varnihs或squid。如果没有独立的web缓存服务器，可使用nginx本身的功能。如果有独立的web缓存服务器，varnihs是一款比squid更好的产品，网聚的同事已经在使用。

       缓存服务器是针对业务系统的数据的缓存，用于减轻业务系统对数据库的IO压力。

       文件存储层被独立成单独一层。在下面部分讨论。

 

 

4、文件服务器层

       如果没有采取共享存储，每台web服务器都是独立的磁盘，需要本地均存放一份代码，为了保证多台web服务器的代码数据一致性，使用rsync+inotify实现动态同步。

       倘若硬件条件允许的情况下，推荐使用网络文件系统或者分布式文件系统来存储，方案见下；

• 单 NFS+ 备份 NFS 作为文件服务器，但存在着单点故障，需要人为手动干预；
• DRBD+Heartbeat+NFS 高可用文件服务器，维护方便，也不存在着单点故障。
• 采用 EMC 的存储方案
• 分布式文件系统 MFS 等，分布式文件系统是解决文件服务器压力过大的最终途径。
•   开发自己的分布式文件系统了，

  

 

5、数据库层

       互联网应用中一般采用MySQL数据库（但关键核心系统采用oracle，形成mysql+oracle的混合数据库模式）。面对并发的压力，可以采取如下步骤：

• 系统采用 memcached 作为数据缓存，减少对数据库的 IO ，
•   采取读写分离的模式，在生产环境下是一种靠谱的设计方案，从服务的负载均衡推荐使用 LVS ，因为当后面的 MySQL 机器超过十台时， HAProxy 在这方面的性能不如 LVS 。
•   如果业务量过大，接着可采用垂直分库，每一组均采用主从架构，这样可避免了单组数据库压力过大的情况。不建议采用水平分库的模式，原因在前面的章节已经阐述。
• 另外需要 DBA 和开发人员，在数据库参数优化 /SQL 语句优化 / 数据切分上多做功夫。

 

5.1.3            部署架构

       网站架构一般分成负载均衡层、web层和数据库层，文件服务器层，随着网站的PV越来越多，文件服务器的压力也越来越大；不过随着moosefs、DRDB+Heartbeat+NFS的日趋成熟，压力会随着技术的进步而得到逐步的缓解。

       网站最前端的负载均衡层称之为Director，起分摊请求的作用，最常见的就是轮询。

       F5是通过硬件的方式来实现负载均衡，它较多应用于CDN系统，用于squid反向加速集群的负载均衡，是专业的硬件负载均衡设备，尤其适用于每秒新建连接数和并发连接数要求高的场景；LVS和Nginx是通过软件的方式来实现的，但稳定性也相当强悍，在处理高并发性能不俗。

       目前较成熟的负载均衡高可用技术有LVS+Keepalived、Nginx+Keepalived，以前 Nginx没有成熟的双机备份方案，但通过shell脚本监控是可以实现的，有兴趣的可具体参考我在51cto上的项目实施方案；另外，如果考虑 Nginx的负载均衡高可用，也可以通过DNS轮询的方式来实现。

       负载均衡高可用中的高可用指的是实现负载均衡器的HA，即一台负载均衡器坏掉后另一台可以在<1s秒内切换，最常用的软件就是Keepalived和Heatbeat，成熟的生产环境下的负载均衡器方案有Lvs+Keepalived、Nginx+Keepalived；如果能保证Heartbeat的心跳线的稳定的话，Heartbeat+DRBD也是成熟的应用，适用于NFS文件服务器或Mysql。

 

       大型网站架构中其实可以结合使用F5、LVS或Nginx，选择它们中的二种或三种全部选择；如果因为预算的原因不选择F5，那么网站最前端的指向应该是LVS，也就是DNS的指向应为lvs均衡器，lvs的优点令它非常适合做这个任务。重要的ip地址，最好交由lvs托管，比如数据库的ip、webservice服务器的ip等等，这些ip地址随着时间推移，使用面会越来越大，如果更换ip则故障会接踵而至。所以将这些重要ip交给lvs托管是最为稳妥的。

       VIP地址是Keepalived虚拟的一个IP，它是一个对外的公开IP，也是DNS指向的IP；所以在设计网站架构时，需要多申请一个对外IP。在项目实施过程中发现，Lvs和Nginx对https的支持都非常好，尤其是LVS，相对而言处理起来更为简便。

       在LVS+Keepalived及Nginx+Keepalived的故障处理中，二者都方便；如果发生了系统故障或服务器相关故障，即可将DNS指向由它们后端的某台真实web，达到短期处理故障的效果。

       另外关于session共享的问题：Nginx可以用ip_hash机制来解决；而F5和LVS都有会话保持机制来解决这个问题，此外，还可以将session写进数据库，或者写入缓存，这就需要架构师进行取舍。

 

       经过对负载均衡层和web层的架构处理，前端层的并发问题解决后，压力就会传递给后端的文件服务器层和数据库层，单NFS不可能胜任目前的工作，可行的方案是moosefs和 DRDB + Heartbeat + NFS；而Mysql服务器，成熟的应用方案还是主从（读写分离）模式。     

 

 

 

 

       前面铺垫了这么多内容，无非想说明大规模网站的设计和部署，其实并不遥远和神秘，它和我们周边开源软件息息相关，借用作者的智慧，以及自己付出一些实践的成果，我们也能在互联网的浪潮中不至于被远远的落下，作为本章节的收尾，后续将开展我们的diy行动，其实可见我们的diy paas平台在部署上和别人的大规模网站的部署何其相似，所以说在互联网时代没有黑箱，只有白盒，借助自己勤劳的双手自行diy，深刻感受一下Pass平台的嬲塞魅力把，所以请大家正襟危坐，全神贯注，目不斜视，现在旮场，进入我们的diy阶段。

       本身Paas平台博大精深，内容庞杂，业界也有很多不同的方案和产品，每个解决方案都有自己的亮点和适用场景，并不没有所谓的好与坏，好与底。能解决自己的问题，提升公司的整体技术能力，就是合适的，所以在这里对Paas平台稍微归类，纯属个人行为，只为了阐述方便，不代表业界通用说法。这里我按照Paas的CloudControl作为类型的区分，可以分为3个时代：

• 脚本式 CC （奴隶时代）：由脚本构筑，没有明确的 cloudControl ，部署 / 管理 / 监控采取的是脚本和自动调度程序，再配合特定的模板和规则。系统处于堆砌方式，需要运维人员的强烈管理意识，依赖众多劳苦的 IT 民工，所以处于奴隶时代。
• 独立式 CC （封建时代）：有独立的 cloudcontrol 对整个 paas 云端进行管理，包括部署，发布监控等， cc 和部署的应用之间是有状态的，也就是说 cc 和 apps 的关系是 1:n 的关系。部署简单，监控有力，因为带有状态，部署的 apps 的个数有限，如果借助某种定义语言或者模板来说明部署方式，将极大的简化部署工作，可实现 noops 的能力。因为此时已经有了类似家族管理的作风， CC 就是家长，强调规范化调理化，家族内部次序井然，所以处于封建时代。
• 分离式 CC （资本时代）：有多个独立的 cloudcontrol ， cc 本身是多节点，对外统一暴露， cc 和 apps 之间没有状态关联，而是通过某种消息机制建立发布和订阅关系， cc 和 apps 的对应关系是 n:m ，可部署相当多的 apps 服务。为了整个云端能良好的运行，需要进行良好的维护。整个系统庞大而次序井然，分工明确各司其职，各个组件都是独立而平等，通过发送和订阅的方式，整个系统进行着步骤有序的运转，所以处于资本时代。

上一篇 从项目开发到云端架构(15)  ：http://timeson.iteye.com/blog/1701957

下一篇 从项目开发到云端架构(17)  ：http://timeson.iteye.com/blog/1707071