从项目开发到云端架构 4
1.1.1 扩展系统
2.2.2.1 特点
当单一的部署模式即便通过集群部署后仍达不到期盼的高并发能力,那对系统的拆分就不可避免,通过拆分把负载分布在各个节点。系统的拆分包括了架构拆分和数据库拆分。架构拆分后需要考虑层次和模块的划分和部署,之间的调用模式,以及考虑事务处理问题;数据库拆分后需要考虑采取哪种模式,以及如果保证数据一致性问题。
2.2.2.2 架构
图22-08:扩展系统架构
在扩展系统中着重考虑整体性能的伸缩性,所谓伸缩性就是在系统负荷大的时候,能够通过增加服务器/虚拟机来缓解压力;同样的,当不需要多台机器的时候,可以减少服务器的数量来。而这些改变,最终用户是透明的。系统的伸缩性需要在前端,后端,以及数据端都需要考虑。
可伸缩性-前端
Nginx+keepalived能很好的实现高可用、可扩展以及负载均衡的要求。Nginx提供负载均衡的能力,keepalived提供健康检查,故障转移,提高系统的可用性。采用这样的架构以后很容易对现有系统进行扩展,只要在后端添加或者减少realserver,只要更改配置文件,并能实现无缝配置变更。在本项目中建议采用由Nginx充当LoadBalancer的职责,Keepalived实现Nginx的HA的架构模式,通过暴露虚拟IP(配置DNS绑定域名)的形式对内容网站进行访问。
对session的管理,在集群服务器不多(小于4台)时,可使用Session复制的水平扩展方式,因为广播式复制到其他服务器有一定延时,会带来一定网络开销;在服务器数据较多,追求稳定与可控的情况下,则采用集中式session管理的水平扩展方式(代码需要做点修改)。
伸缩性-应用层
应用层采用无状态分布式模式,本身应用层能分解多个模块,通过封装的nio模式(metis组件)把调用分解到各个服务器上,从而分解前端的调用压力。至于前端如何感知到后端的服务器个数,以及服务器的业务类型(计费服务器,商品管理服务器,内容分发服务器)则可以通过统一的配置管理模块来处理,下面给一个示意图。(在线影城的范例)
图 22-08:分布式部署方式(前后端分离)
这里展现的是一种前后端分离模式的部署,前端是多台web,后端是后台应用,通过metis封装对外提供统一的api,有2个重要的组件:
Provider 暴露服务方称之为“服务提供者”(图中为服务框架-提供者),是一个服务实现的实体,它接受和执行来自服务消费者的请求。它将自己的服务和接口描叙注册到服务注册中心,以便服务使用者可以发现和访问该服务。
Consumer 调用远程服务方称之为“服务消费者”(图中为服务框架-消费者),是一个应用程序、一个软件模块或需要一个服务的另一个服务。它发起对服务注册中心的服务订阅,通过传输绑定服务,并且执行服务功能。服务使用者根据接口契约来执行服务。
Registry 服务注册与发现的中心目录服务称之为“服务注册中心”(图中注册服务),是“服务提供者”,“服务消费者”的支持者。它包含一个可用服务的存储库,保存“服务提供者”的服务注册信息,并允许感兴趣的“服务消费者”对服务进行订阅。 实际注册中心实际也扮演了服务提供者的角色,因为它提供的是对服务
服务框架:包括了metis框架和metis-reg注册服务器2个组件。服务框架是一个面向服务的体系结构,分为三点式架构。
缓存服务:(图中memcached),这里缓存存放的是根据业务查询出来的数据副本,其实缓存在整个应用里面还可以作为session集中缓存的地方,也可以作为热点资源的缓存(图片,流媒体,文字等),通过缓存,极大的提升系统的响应速度,减少后端服务器的配备。
伸缩性-数据库层
数据库的伸缩有几种方式,还可以组合使用,一般来说有读写分离,垂直分库,水平分库等。从可实施步骤可以遵循如下步骤:db + cache à db + 读写分离 + cache à db + 垂直分库 + cache。
因为水平分库的拆分因子一旦确定,就几乎不可能在重新作扩展,所以除非有特定业务,一般不考虑水平分库。下面稍微阐述一下读写分离的模式。
“读写分离”实际上是利用到了MySQL的主从复制(master-slave)功能。所谓“读写分离”就是把应用中“非readonly”或者事务性、实时性要求高的操作会定位到master上去,其他的“readonly”操作则定位到多台slave上,多台slave之间也可以使用Amoeba实现负载均衡机制保障。当然,为了保证master的可靠性,我们需要对master所在机器做HA。
垂直/水平分库:当针对单个数据库的物理部署优化无法满足性能要求的情况下,需进一步考虑数据库分库方案。一方面,数据库分库增加了开发、维护和调优各个方面的难度。另一方面分库也有一些优势:从底层数据库的分离,支持各个功能域的业务组件的独立,可以单独的替换与改造某个功能域的内部实现,不影响其他功能,增加了应用的灵活性和可复用性;可以把庞大的数据库化整为零,避免单一数据库过于庞大,增强了数据库的可维护性。
从经验上讲述,建议使用垂直分库,因为水平分库的根据拆分因子拆开后,日后需要再行扩展非常困难;另外增删改查,需要跨多数据源中处理,还要作数据的合并,也许还有排序功能,代价较大,而且数据一致性难以保证。
使用垂直分库的问题在于关联查询的时候需要跨库查询,性能降低,这可以在采取缓存策略进行部分的优化。当系统进一步扩大,建议是垂直分库+读写分离+缓存模式。
2.2.2.3 开发
2.2.2.4 部署
软件部署,即把软件放置到相应的地方,并且进行相应的配置,让软件能够正常运行起来。下图有个软件项目的部署方式,每个大框为一个JVM容器,即为在物理上依赖一个具体的WEB容器,WEB容器可以存着于一台物理机器上,或者性能良好的虚拟机上。(注:前端保障模块除外,这里体现的是功能的汇聚和整合,实际情况可能包括多个JVM,但在这里被合并成一个概念)这里阐述一种基本的部署模式,在基于电子消费平台的应用中,整个系统被分解为4层5大模块的格局:
图 22-09 软件部署图
1、 总体系统分为4层:
Web展现:提供用户的web展现,包括静态html和图片等,并充分利用静态化,页面缓存,反向代理等技术加快静态资源的读取和后端系统的轮询调用。
前端业务:web动态资源的调用。
后端业务:基础能力的提供,并以api的方式提供前端调用。
数据库:提供业务系统的持久保留。
2、 总体系统分为5个部分:
Web展现系统:基于apache或者是ngnix的web展现,提供2个能力:1、静态资源的读取;2、对后端的轮询调用。
前端业务系统:基于tomcat系统,采用europa轻量级web框架,提供动态资源的展现,实现对后端系统的调用。在本系统中,根据功能的划分,定为4个层次:
动态页面展现:特指基于europa框架开发的页面展现
业务功能模块:基于europa开发的业务功能,典型场景:mvc+service+dao+orm。。
通用业务支撑:对业务系统的通用支撑的功能统称,提供了不限于上图展示的“xml处理”,“规则处理”,“流程处理”,“缓存”等基础业务功能。
后端业务调用:包括2种能力,数据的持久保存(不限定是数据库,文件系统,网络系统均可),以及分布式系统的远程调用。
前端保障系统:归属于前端业务系统,提供前端业务系统需要的常备功能,诸如定时调度,ftp,文件系统等,根据业务的提供的方式不同,也许多个JVM的形式。一般来说前端保障系统包括但不限定以下:
定时调度:基于quartz的封装,在每个项目内部做成唯一的实例节点,后台业务的调度任务均该定时调度来触发。采用基于数据库持久模式。
用户鉴权:第三方模块建立对鉴权中心的的信任关系,用户只要通过鉴权中心的认证,即可自由地访问本系统其他模块的服务,而不需要重复登录,通过与鉴权中心和各个模块之间的通讯,各个模块系统也可以确保该用户是合法用户,从而为之提供服务。
文件系统:提供文件的透明存储和读取的功能。
基础平台系统:即本文档所指的电子消费平台。
从狭义来说,电子消费平台包括统一用户,统一订单,统一支付,统一商户,以及对外暴露的open api,根据具体的需求,有些api会被人工编排成一个具有更大的业务逻辑抽象;所有这些被metis封装对外暴露api。
从广义来说,基础平台还依赖具体不同省份不同实现的业务领域逻辑代码。
数据库系统:作为业务系统的持久设施,相对独立。在互联网系统中常规做法是采用mysql,分库处理,读写分离。
来源:timeson http://timeson.iteye.com/blog
矽控电子®分别获“科技型中小企业”、“江苏省民营科技企业”、“创新型中小企业”认定,核心团队拥有十余年的硬件正向研发,生产制程,测试手法,品质控制经验。尤其擅长嵌入式ARM平台的人工智能与工控物联网产品,以及瑞芯微(Rockchip)、海思、NXP、新唐等平台的机器视觉类AIoT模组开发,为您的产品从创意到落地、批量市场化助力。
公司可提供从硬件设计(原理开发及PCB Layout),Linux驱动开发,PCB制板,SMT及接插件焊接,产品测试,产品老化全流程外包服务,收费合理,品质可靠。
定制开发找矽控,品质可靠省费用
垂询电话:0510-83488567-1 业务邮箱:wxdianzi#foxmail.com (#更换为@)