从项目开发到云端架构 16

2017-11-27 14:54:12 181

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平台各司其职,相互分工协作。从cloudfoundrycloudify再到Jelastic,部署越是简单的,它的业务扩展能力其实就是越弱,到了Jelastic,虽然部署非常的简单,简单到只有传个war包即可,但性能的伸缩完全依赖于paasroute(这里是nginx)来实现,扩展有限。所以好的paas平台,不单单是看其提供服务的多寡,支持的语言丰富,还要看是否为部署的应用架构提供了高可用,可水平扩展的业务架构模式。

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

5.1  DIY before

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

知识点

说明

备注

11.web应用

互联网常用和web相关的应用,包括:

apachetomcatwarnishsquid memcachedredis


12.备份恢复



13.网络存储



14.运维监控

Nagioscaicti以及日志管理等,对系统进行监控


15.性能优化

针对架构层面的对系统的优化


16.应用集群

包括了tomcatnginxlvs的集群方式


17.数据集群

数据库的集群方式,在互联网中一般采取mysq,借助drbdheartbeat的能力


18.通用服务

在互联网应用中常用的,包括:

防火墙,dnsvpn,邮件服务器等


19.部署架构

业界通用的集群部署架构模式,通常有

Lvs+keepalived / nginx+keepalied

Drbd+heartbeat+nfs/mysql 的混合模式

其中会涉及到几种session的管理方式,paas平台的负载均衡能力也是之前所述方式的一种

通用的模式在这里说明,大中小项目中再举具体的范例

20.持续交付

对于营运类型的项目,会持续的更新和部署,需要采用合适的脚本和持续集成来进行

典型的包括puppet/chef+svn+jenkins

主要在diy after章节阐述

 51-1diy知识点

 

       这里和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/netvs/tunvs/dr),特点是:

    • 在负载均衡软件里的性能最强;因为在网络4层之上仅作分发之用,没有流量产生。

    • 配置性比较低,所以并不需要太多接触,减少人为出错的几率。

    • 工作稳定,自身有完整的双机热备方案,如LVS+Keepalived(推荐)和LVS+Heartbeat

    • 无流量,保证了均衡器IO的性能不会收到大流量的影响。

    • 应用范围比较广,可以对所有应用做负载均衡。

    • 软件本身不支持正则处理,不能做动静分离,可以结合nginx/HAProxy+Keepalived

  • HAProxyHAProxy是一款提供高可用性、负载均衡以及基于TCP4层)和HTTP7层)应用的代理软件。

    • 免费开源,稳定性也是非常好,稳定性可以与硬件级的F5相媲美。

    • HAProxy 支持连接拒绝,这个优点也是其它负载均衡器没有的。

    • HAProxy 支持全透明代理(已具备硬件防火墙的典型特点)。

    • HAProxy现多于线上的Mysql集群环境,我们常用于它作为MySQL(读)负载均衡;

    • 带强大的监控服务器状态的页面,实际环境中可结合Nagios进行邮件或短信报警。

    • HAProxy支持虚拟主机。

  • Nginx:基于第7层的负载均衡,支持httpmail的均衡,特点:

    • 承担高的负载压力且稳定,一般能支撑超过几万次的并发量;

    • 工作在网络的7层之上,提供的正则处理比HAProxy更为强大,轻松实现动静分离。

    •  对网络的依赖非常小,能ping通就就能进行负载功能。

    • 可通过端口检测到服务器内部的故障。

    • 仅能支持httpEmail

    • 作为中间代理层,对于大型网站可能的架构为F5/LVSàNginx(多台)àweb集群。

 

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

  • Keepalived:运行在lvs之上,主要功能是实现真实机的故障隔离和负载均衡器之间的失败切换(failover),工作在第3/4/5层。keepalived产生的虚拟vip就是整个系统对外的ip,如果最外端的防火墙采取的是路由模式,那就映射此内网ip为公网ip

  • Heartbeat:和drdb一起应用于在线的高可用文件系统;也是mysql官方推荐的实现mysql高可用的一种手段。

  • DRBD:分布式复制块设备,支持3种复制协议:异步复制协议,内存同步,同步复制。在线项目可以采用协议3drbd+heartbeat+nfsdrbd+heartbeat+mysql

 

5.1.2          部署层次

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

 

1、负载均衡层

  • Lvs+ Keepalived模式:现在linux系统已经内置了lvs功能,为了避免lvs的单点故障的出现,采取主备模式,有2种高可用软件,这里采取keepalived,本身keepalived就是为lvs设计的,监控集群系统种各个服务节点的状态。LVS在性能方面是最好的,尤其是后面的节点(WebMySQL数据库服务器)超过10台时,它的性能是最优异的。

  • HAproxy+Keepalived模式 

  • Nginx+Keepalived模式:负载均衡层采取nginx,用keepalivedHA。因为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更好的产品,网聚的同事已经在使用。

 

3WEB

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

Session管理

  •  粘性会话()

  • session共享(基于cookie,基于数据库,基于缓存)

 

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

  • F5 big-ip:简单会话保持,基于cookie会话保持,ssl session id会话保持。

  • Lvspersistence机制

  • Nginxupsteam模块的ip_hash机制。

  • Haproxybalance source机制(默认是轮询)

 

 

 


矽控物联
 

 51-01:网站部署

 

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

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

       Web缓存层被独立层单独的一层,使用varnihssquid。如果没有独立的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越来越多,文件服务器的压力也越来越大;不过随着moosefsDRDB+Heartbeat+NFS的日趋成熟,压力会随着技术的进步而得到逐步的缓解。

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

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

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

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

 

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

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

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

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

 

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

 

 

 

 

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

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

  • 脚本式CC(奴隶时代):由脚本构筑,没有明确的cloudControl,部署/管理/监控采取的是脚本和自动调度程序,再配合特定的模板和规则。系统处于堆砌方式,需要运维人员的强烈管理意识,依赖众多劳苦的IT民工,所以处于奴隶时代。

  • 独立式CC(封建时代):有独立的cloudcontrol对整个paas云端进行管理,包括部署,发布监控等,cc和部署的应用之间是有状态的,也就是说ccapps的关系是1:n的关系。部署简单,监控有力,因为带有状态,部署的apps的个数有限,如果借助某种定义语言或者模板来说明部署方式,将极大的简化部署工作,可实现noops的能力。因为此时已经有了类似家族管理的作风,CC就是家长,强调规范化调理化,家族内部次序井然,所以处于封建时代。

  • 分离式CC(资本时代):有多个独立的cloudcontrolcc本身是多节点,对外统一暴露,ccapps之间没有状态关联,而是通过某种消息机制建立发布和订阅关系,ccapps的对应关系是n:m,可部署相当多的apps服务。为了整个云端能良好的运行,需要进行良好的维护。整个系统庞大而次序井然,分工明确各司其职,各个组件都是独立而平等,通过发送和订阅的方式,整个系统进行着步骤有序的运转,所以处于资本时代。

 来源:timeson http://timeson.iteye.com/blog




矽控物联

矽控电子®分别获“科技型中小企业”、“江苏省民营科技企业”、“创新型中小企业”认定,核心团队拥有十余年的硬件正向研发,生产制程,测试手法,品质控制经验。尤其擅长嵌入式ARM平台的人工智能与工控物联网产品,以及瑞芯微(Rockchip)、海思、NXP、新唐等平台的机器视觉类AIoT模组开发,为您的产品从创意到落地、批量市场化助力。

公司可提供从硬件设计(原理开发及PCB Layout),Linux驱动开发,PCB制板,SMT及接插件焊接,产品测试,产品老化全流程外包服务,收费合理,品质可靠。

定制开发找矽控,品质可靠省费用

垂询电话:0510-83488567-1     业务邮箱:wxdianzi#foxmail.com (#更换为@)