无锡矽控电子科技有限公司

网站首页 > 技术支持 > 云平台与边缘计算

从项目开发到云端架构 9

2017-11-27 14:47:21 无锡矽控电子科技有限公司 阅读

3.1.2            演进的抽象

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

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


  • 系统部分:网络的划分,主机的上架,操作系统的安装

  • 软件部署:提供缺省的web容器,支持通用类型的请求路由,提供通用服务(数据库,消息等),提供部署方式(代码上传),提供部署模式(大中小项目模式),提供服务和应用绑定方式,监控预警和自动处理机能

  • 软件设计:根据业务的需求,项目设计,编码,测试等工作。

 

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


  • 微小项目:1web容器,1个数据库实例。部署上可利用前端route作集群模式,多个web

  • 普通项目:功能分层,业务分模块,在部署上需要多应用服务器,业务在部署上被拆分为前端模式(打成war包)和后端模式(打成zip包),使用1个数据库实例(数据库也许是集群模式,类似oracleRAC,但不是多库模式)

  • 大型项目:需要考虑系统的水平扩展,以及业务的扩展能力。特点是多展现模式(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+jsservcie+dao是允许分离部署,部署模式考虑第一条。

  4. 整个系统是柔性可伸缩,上图展现的是伸展部分,在小规模系统中,后台逻辑是可以和前端系统合在同一个war,摒弃metismq,逻辑上分离,物理上部署在一起。

  5. 根据前端后端的划分不同,系统是允许多层物理拆分,看系统架构的需要

  6. 前端系统的数据来源,不仅仅依赖关系数据库,还能来自缓存服务和nosql服务器,因为数据的多处存储,需要进行处理数据一致性的问题。

  7. 事务是不能从前端到后端通过网络传递,需要架构师在设计的时候考虑数据一致性的问题,并采取相应的设计技巧。

 

3.1.2.2   部署的规范

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


  1. 常用的服务加以规划,池化,id识别。针对mysqlrabbitMQredismencachemongodbtomcatjetty作为标准服务,服务的参数可以允许配置;所谓池化就是把一类型服务对外统一提供,当然需要特定的id进行标示,以备应用(程序员上传的warzip)绑定,服务本身有生命周期加以管理。

  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个层面的综合解决方案。

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



矽控电子

矽控电子核心团队拥有十余年的硬件正向研发,生产制程,测试手法,品质控制经验。尤其擅长嵌入式ARM平台的工控物联网产品,以及海思平台的IPC视频类模组开发,为您的产品从创意到落地、批量市场化助力。公司可提供从硬件设计(原理开发及PCB Layout),PCB制板,SMT及接插件焊接,产品测试,产品老化全流程外包服务,收费合理,品质可靠。

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


Powered by ElecKits 5.3.15 ©2008-2018 www.silicontrol.com