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

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个重要的组件：

 

•  
  • 服务框架：包括了metis框架和metis-reg注册服务器2个组件。服务框架是一个面向服务的体系结构，分为三点式架构。
    • Provider 暴露服务方称之为“服务提供者”（图中为服务框架－提供者），是一个服务实现的实体，它接受和执行来自服务消费者的请求。它将自己的服务和接口描叙注册到服务注册中心，以便服务使用者可以发现和访问该服务。
    • Consumer 调用远程服务方称之为“服务消费者”（图中为服务框架－消费者）,是一个应用程序、一个软件模块或需要一个服务的另一个服务。它发起对服务注册中心的服务订阅，通过传输绑定服务，并且执行服务功能。服务使用者根据接口契约来执行服务。
    • Registry 服务注册与发现的中心目录服务称之为“服务注册中心”（图中注册服务），是“服务提供者”，“服务消费者”的支持者。它包含一个可用服务的存储库，保存“服务提供者”的服务注册信息，并允许感兴趣的“服务消费者”对服务进行订阅。 实际注册中心实际也扮演了服务提供者的角色，因为它提供的是对服务 
  • 缓存服务：（图中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，分库处理，读写分离。

 

 

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

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

 

评论

1 楼 iilover 2014-01-29  

你好，写得很好，学习了，请问能将《云端平台的设计和实现》《云端平台的运营和管理》《云端平台的资源虚拟化》这三篇分享一下吗？发到我的邮箱：[e-mail],大家多多交流，谢谢！