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

3.1.2            演进的抽象

       淘宝这套体系，经历多年的发展，已经很成熟，按照抽象和分层的思想，我们拆解一下，看如何来处理类似的工作。这个抽象和分层是老外的强项，把一些东西排列组合，按照一定的规则和模式，又可以整合出一些新的东西出来，然后到处去忽悠。

       我们模仿老外的思想，来对系统进行拆分：拆解为系统部分，软件部署部分，软件设计部分。中心思想是如何为各种不同类型的项目（分解为大中小类型项目）提供快捷的支撑和部署。

• 系统部分：网络的划分，主机的上架，操作系统的安装
• 软件部署：提供缺省的web容器，支持通用类型的请求路由，提供通用服务（数据库，消息等），提供部署方式（代码上传），提供部署模式（大中小项目模式），提供服务和应用绑定方式，监控预警和自动处理机能
• 软件设计：根据业务的需求，项目设计，编码，测试等工作。

 

       这样开发人员只需要按照一定的模式和规则处理业务逻辑，剩下的事情有软件部署和系统管理人员来搞定，分工协作，关注好自己的事情。这里对项目的规模做个假设，统一术语：

• 微小项目：1web容器，1个数据库实例。部署上可利用前端route作集群模式，多个web。
• 普通项目：功能分层，业务分模块，在部署上需要多应用服务器，业务在部署上被拆分为前端模式（打成war包）和后端模式（打成zip包），使用1个数据库实例（数据库也许是集群模式，类似oracle的RAC，但不是多库模式）
• 大型项目：需要考虑系统的水平扩展，以及业务的扩展能力。特点是多展现模式（web/wap/手机客户端），多web服务器，多数据库实例，表拆分

 

	特点	软件人员	架构师	部署人员	系统人员
微小项目	1 web 1 db	整个业务由一个war形成，一个数据库实例	架构师只需要对业务上进行把控，边界进行定义，不需要对部署模型进行处理	拿到war包进行部署，在数据库中初始化数据。对于web容器/数据库的管理和优化。 需要集群的应用，利用前端的route粘性分发，部署多台web容器，对程序开发没有约束	安装系统，安装数据库，划分ip，并执行物理的备份和处理
普通项目	M web 1 db	业务由多个war包形成，包括zip形式，多个包有关联关系，共享一个数据库实例	功能分层分块，从逻辑上的拆分变成物理的拆分 关注性能，确定模块的边界，数据的一致性，	需要根据war包的约束，先后不同的次序来部署，执行特定的脚本，启动不同的服务
大型项目	M web N db	多个war，多个zip，多个数据库，不同的war应用连接不同的数据库	业务的分区分域拆分，关注性能，保证一定时间间隔的数据一致性 关注业务的分离和扩展性	多库的设定，多数据库之间的数据备份，同步等
抽象			提供通用的业务设计模式，分别针对大中小项目类型。 提供可用业务组件简化开发	提供通用的route模式，服务的模板（tomcat,mysql ,mq,redis,mongodb） 服务管理（池化，生命周期，访问，以及绑定） 部署的命令，脚本，方式	主机的划分 虚拟机的生命周期 网络的管理 虚拟机的模板管理

表 31-1：项目的类型

 

3.1.2.1    架构的规范

       架构师需要设定通用的架构模式，为开发人员提供技术指导，并提供相应的组件，和配置文件模板，简化程序员的开发。

 

 

 

图31-02： 系统架构的通用方式

 

       上图为业务的通用架构方式，主要特点是前后端分离，采取异步模式处理业务调用，前端采用route进行请求分发，应对一般的业务场景和并发要求是没有问题的。特点如下：

1. 业务是物理拆分的，分为前端系统和后端系统，前后端用异步模式关联，后端系统需要被设计成无状态模式（对于无htt session来说，很容易实现）。
2. 前端web通过Route进行请求的分发，至于route采取什么策略（客户端，服务端，粘性处理）需要和架构师进行确定，不同的模式会影响部署的模式。如果采用粘性会话的路由模式，对程序无影响，但对性能扩展有影响。
3. 前端系统允许再拆分，在html+js和servcie+dao是允许分离部署，部署模式考虑第一条。
4. 整个系统是柔性可伸缩，上图展现的是伸展部分，在小规模系统中，后台逻辑是可以和前端系统合在同一个war，摒弃metis和mq，逻辑上分离，物理上部署在一起。
5. 根据前端后端的划分不同，系统是允许多层物理拆分，看系统架构的需要
6. 前端系统的数据来源，不仅仅依赖关系数据库，还能来自缓存服务和nosql服务器，因为数据的多处存储，需要进行处理数据一致性的问题。
7. 事务是不能从前端到后端通过网络传递，需要架构师在设计的时候考虑数据一致性的问题，并采取相应的设计技巧。

 

3.1.2.2   部署的规范

       对于每个业务系统来说，都要重复创建服务，部署应用是重复简单的劳动，如果这块能抽象和剥离，对于系统的快速部署，简化系统的管理则大有裨益。根据上图的分析，只有程序员的代码是区分项目的，其他的部分都是可以重复利用，加以规范处理。

1. 常用的服务加以规划，池化，id识别。针对mysql，rabbitMQ，redis，mencache，mongodb，tomcat，jetty作为标准服务，服务的参数可以允许配置；所谓池化就是把一类型服务对外统一提供，当然需要特定的id进行标示，以备应用（程序员上传的war，zip）绑定，服务本身有生命周期加以管理。
2. 提供通用的程序模式，上图已经阐述，前端用route作请求分发，前后台用异步机制关联，指导程序员的部署工作。
3. 提供上传程序的通道和途径，提供脚本描述语言的解析，允许程序员在部署复杂应用的时候，依次有序的进行部署。
4. 提供web的控制台，方便管理和查看我们部署的应用，以及参数配置，系统状态。
5. 提供监控和预警处理，并能和服务的生命周期关联，在负载波动的情况下，对特定服务进行控制。

 

 

 

图31-03： 部署管理的模型

 

       部署管理的模型可以分解为7个部分，其中“发布订阅”属于底层支撑的，用以把其他6大模块解藕，并通过异步的方式关联。

1. Route：分发前端的请求
2. apps管理：包括用户的war/zip的上传管理，部署管理（单一war/多个war，彼此关联依赖等），脚本的执行，自动检测等处理，以及通知服务管理
3. apps池：是装载程序员上传的war/zip的场地，如果是启动1个实例，就创建一个vm丢在池里；如果是启动10个实例，就创建10vm，分别放在池里，分别部署。不依赖具体的实现，即支持多种格式的虚拟机也支持物理机。
4. 服务管理：用来控制服务的生命周期，内部对服务有个模板管理，可以进行参数设定，根据apps管理来的指令，来启动1~m个服务实例，并对外提供id，由“apps管理”进行服务和apps的绑定。
5. 服务实例化：实例化后的服务场地
6. 监控：获取各个模块的当前参数信息，反馈给管理者，可以和一些自动脚本关联，比如对服务的自动管理，对route的自动管理等
7. 发布订阅：把6大系统结构，通过异步处理又关联起来，6大系统都是可以扩展的，只需要在“发布订阅”模块中声明，作为支撑大规模高并发的应用来说，本身的部署管理系统也要是健壮和可扩展的。

 

       到目前为止，业界能看到的所谓健壮和可扩展系统，无不是利用系统拆分和异步通讯来构建的。归纳总结为6个字：分派，拆分，异步。

3.1.2.3  资源的规范

       这里的资源是指主机，网络，操作系统的层面。

       根据前文所述，该层需要解决的问题是存储的管理，网络的管理，虚拟机的生命周期管理，镜像盘的管理。从大的方面来看，可以分解为3大部分，核心管理：虚拟机的生命周期管理以及网络管理，认证，调度等；存储部分：存储用户的虚拟机的主场；镜像管理：存储虚拟机的镜像盘。

 

 

 

图31-04： 资源管理的模型

 

1. Api：对外暴露的可调用的api，这里的api是各个模块api的汇总，逻辑层面，典型的有计算模块的api，存储管理的api。
2. 认证：对权限进行检查，来进行后续的api调用。
3. 核心：这块是底层管理的重点，包括       创建和终止虚拟机实例；为所有API查询提供端点，初始化部署活动（如运行实例），实施一些策略（如配额检查）等功能。
4. 监控：对系统本身的状态进行监控和反馈
5. 调度：定时任务的处理
6. 网络管理：接收网络操作指令，执行以操控网络，如创建bridging interfaces或改变iptables rules。
7. 存储管理：管理映射到计算机实例的卷的创建、附加和取消。
8. 镜像管理：包含虚拟机镜像数据的存储系统，以及对外暴露的api。
9. 订阅发布：采取发布订阅的机制：把8大系统结构，通过异步处理又关联起来。

 

 

       通过这边如此的抽象和分层，我们用拍脑袋的方式得到了一个典型的大型系统设计，部署，运营的整体解决方案。在这套整体解决方案中，大型网站被分解为3个层次，每个层次分工明确，各司其职，但有彼此关联，相连相依。也就是说，任何大型系统的成功运行，不是某个层能独立解决的，它一定是3个层面的综合解决方案。

 

 

上一篇 从项目开发到云端架构(08)  ：http://timeson.iteye.com/blog/1686284
下一篇 从项目开发到云端架构(10)  ：http://timeson.iteye.com/blog/1687979