从项目开发到云端架构(09)
?????? 淘宝这套体系，经历多年的发展，已经很成熟，按照抽象和分层的思想，我们拆解一下，看如何来处理类似的工作。这个抽象和分层是老外的强项，把一些东西排列组合，按照一定的规则和模式，又可以整合出一些新的东西出来，然后到处去忽悠。
?????? 我们模仿老外的思想，来对系统进行拆分：拆解为系统部分，软件部署部分，软件设计部分。中心思想是如何为各种不同类型的项目（分解为大中小类型项目）提供快捷的支撑和部署。
?
?????? 这样开发人员只需要按照一定的模式和规则处理业务逻辑，剩下的事情有软件部署和系统管理人员来搞定，分工协作，关注好自己的事情。这里对项目的规模做个假设，统一术语：
?
?
特点
软件人员
架构师
部署人员
系统人员
微小项目
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：项目的类型
?
?????? 架构师需要设定通用的架构模式，为开发人员提供技术指导，并提供相应的组件，和配置文件模板，简化程序员的开发。
?
?
?
图31-02： 系统架构的通用方式
?
?????? 上图为业务的通用架构方式，主要特点是前后端分离，采取异步模式处理业务调用，前端采用route进行请求分发，应对一般的业务场景和并发要求是没有问题的。特点如下：
?
?????? 对于每个业务系统来说，都要重复创建服务，部署应用是重复简单的劳动，如果这块能抽象和剥离，对于系统的快速部署，简化系统的管理则大有裨益。根据上图的分析，只有程序员的代码是区分项目的，其他的部分都是可以重复利用，加以规范处理。
?
?
?
图31-03： 部署管理的模型
?
?????? 部署管理的模型可以分解为7个部分，其中“发布订阅”属于底层支撑的，用以把其他6大模块解藕，并通过异步的方式关联。
?
?????? 到目前为止，业界能看到的所谓健壮和可扩展系统，无不是利用系统拆分和异步通讯来构建的。归纳总结为6个字：分派，拆分，异步。
?????? 这里的资源是指主机，网络，操作系统的层面。
?????? 根据前文所述，该层需要解决的问题是存储的管理，网络的管理，虚拟机的生命周期管理，镜像盘的管理。从大的方面来看，可以分解为3大部分，核心管理：虚拟机的生命周期管理以及网络管理，认证，调度等；存储部分：存储用户的虚拟机的主场；镜像管理：存储虚拟机的镜像盘。
?
?
?
图31-04： 资源管理的模型
?
?
?
?????? 通过这边如此的抽象和分层，我们用拍脑袋的方式得到了一个典型的大型系统设计，部署，运营的整体解决方案。在这套整体解决方案中，大型网站被分解为3个层次，每个层次分工明确，各司其职，但有彼此关联，相连相依。也就是说，任何大型系统的成功运行，不是某个层能独立解决的，它一定是3个层面的综合解决方案。
?
?
上一篇 从项目开发到云端架构(08)? ：http://timeson.iteye.com/blog/1686284
下一篇 从项目开发到云端架构(10)? ：http://timeson.iteye.com/blog/1687979
?
