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

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

从项目开发到云端架构 2

2017-11-27 15:00:02 无锡矽控电子科技有限公司 阅读

2        项目架构

       要实现大并发高访问的web系统,不仅只是paas平台事情,业务系统的架构才是关键作用。在本篇章中尝试讨论一种比较通用的业务架构模式,并且该模式和paas提供的能力较为匹配,在部署和管理上能相得益彰。

       首先会先阐述一下架构师在面对普通的业务系统(普通的围绕数据库的增删改查应用以及一些外延扩展)的通用处理,然后是阐述在不同的业务规模中的架构的不同,架构被人为的分解为普通和扩展的模式,另外会说明一下多租户的概念,因为这是系统扩展后的一种发展趋势。一般来说小项目的部署和维护比大项目要简单得多,很多开源的paas(包括去年湖南移动演示的paas系统)对这种web系统有较好的支撑,但对大型web系统的支撑才是paas的真正能力体现。

       首先我们对系统进行架构上的分析,然后在高并发大访问的情况下如何设计和部署我们的应用,阐述系统在通用情况下的解决方案,为后续把系统映射到云端平台,以及如何利用云端平台如何实现高并发的机制作好铺垫。

 

2.1 架构模板

       每个项目在开发之前都会进行设计和架构的阶段,这也是我们架构师要重点关注的地方,这里会提供一个架构范例文档,可以借鉴和参考。

       我认为架构无非关注几点:1、数据的载体和共享方式、2、模块和层次之间的接口、3、业务流程以及部署模式。

2.1.1            数据表现

       系统都是围绕数据来运行的,尤其是我们的项目,基本都是围绕数据做的增删改查,所以总是被人认为没有什么技术含量,也的确如此,所以把这些没有技术含量的东西归并整理,做的尽可能的规范化和流程化。

       系统数据的设计,其实已经涉及到设计的方法,是从前往后,还是从后往前。有几种设计的方式,总结起来有:1、表驱动;2、页面驱动;3、领域驱动;4POJO驱动,这么几种方式,在不同的场景都有适用的场景。

 

 

  • 表驱动:

 

       表驱动是从后往前的设计方式,数据库的表结构一般来说比业务系统的生命周期更加长久,也更加稳定,获取了业务模型就设计表结构,也就相对获取了相对稳定的业务系统的数据结构信息,所有的业务处理都是围绕表结构来运行,理解业务关系就是理解表和表之间的关联关系。

       典型的联创移动事业部的开发方式代表了这种模式,提倡了表驱动的设计理念和前后端分离的开发体系,前端是使用tapestry实现的web展现,中间层应用逻辑搭建在tuxedo服务器之上,使用joit或者wtc进行前后端的关联,并能多台部署,后端是OracleWeb只能通过调用中间层的服务访问数据,不能直接访问数据库,这样有几个特点:

 

    • 中间服务器层可均衡访问,并通过tuxedo把并发访问削峰填谷,提高系统的健壮性,并利用tuxedo的事务传播性,实现数据的一致性。

    • 前端开发和后端开发分离,开发速度快,行业经验能有效固化。在特定的行业应用中,后台服务大体是稳定的,变化的只是前端展现,通过后端服务的编排/编制(提供了可视化工具),能快速提供前端展现所需要的服务,前端人员不需要了解后端逻辑,只需要知道是哪个Api。在boss1.5升级中,每个省boss系统在3个月左右即可上线,效率极大的提升。

    • 数据的安全,所有的数据访问,被限定在有限的通道中,非后台人员无法知道后端表结构和数据。

 

 

 

  • 页面驱动:

 

    页面驱动是从前往后的模式,比较的敏捷和贴切互联网的应用,强调快速开发,简略一些中间过程,推崇界面(界面原型)即需求,并有此来生成表结构的信息。很多的互联网公司催推崇这种方式,但这样主要有点,生成的表结构不是很稳定,随着界面的调整和迭代改进,总是要对后端表结构作修改。

       有的工具还能提供界面生成工具,通过代码自动生成工具生成部分逻辑,并提供一些管理工具和管理途径。在2010年的项目中中尝试用页面驱动模式,使用到了动量(ODE)和天翎(teamlinkmyApps)。

 

 

  • 领域驱动

 

       领域模型是对领域内的概念类或现实世界中对象的可视化表示,属于从中间往2头发展的模式,往下从而生成表结构信息,往上能生成页面的数据表现方式。

       领域驱动简单的说根据领域建模的类中,有属性和行为,按照面向对象的模式来说是最匹配的,也是《POJO in action》作者推荐的,但是我们在实际的项目中应用的不多,原因如下:

 

    • 数据库采用的是关系数据库

    • 持久采取的是类jdbc的模式

    • Spring推荐service+dao+orm是贫血模式,自身提供了基于多线程的良好支撑。

    • 领域见面对程序员要求较高

 

 

       组件级别的开发,如果是从设计到开发是自己或者同一个团队来设计,用领域模式是很合适的,只是一点,需要和总体service+dao+orm模式来匹配,就是组件内部中贫血/充血的相互转换,在后续的章节,阐述组件开发的时候,会有讨论。

在研讨整个业务模式的时候,把领域模型弱化为纯粹POJO,强调属性,弱化行文,按照《POJO in action》作者所述,为transaction script,这也是下个就要阐述的POJO驱动模式。

 

 

  • POJO驱动

 

       POJO相比领域模型而言,很轻薄,也是属于从中间向2端发展的模式。从POJO à 数据库作数据映射很方便,用POJO来规划页面的数据展现也很容易,并且通过POJO的序列化或者转JSON的方式能很方便做到模块的拆分,并且POJO方式吻合基于spring推荐的贫血模式的设计。

       建议项目的数据实体设计采用POJO驱动,之前还有采取map的方式,这其实是一种把设计的工作延后到开发的模式,利用map的特点,把数据作扁平化处理,以期获得一定的数据通用性,但这样本来在设计阶段就要规划的数据模型延后到开发中,而开发的程序员人数多,能力参差不齐,又没有利用Java的强制检查的特性,造出程序在运行时容易报错,得不偿失。

 

2.1.2            接口划分

       模块的接口,在系统中多为service部分,在这个层面上关注出参入参和异常定义。在开发过程中已经在考虑使用单独的工程来作为接口的实现,即openAPI工程。

 

2.1.3            流程设定

       业务的流程,贯穿系统的多个模块。可以有3个层面来支持流程化的应用,webflowapiflowworkflow

2.1.4            部署模式

       这里要分2种基本的程序框架和传统部署和基于云部署的模式来分别讨论,按照各自特点,就有4种基本模式来讨论:

 


矽控电子
 

21-01 部署象限

 

       基于传统模式,都需要对生产环境和网络情况非常的了解,并且需要书写部署文件以及设定参数信息,以及一些脚本的编写,基础的服务也需要自己实现搭建好,并设定好负载均衡方式。

       而基于云端部署的方式,基础服务和负载均衡方式是已经部署好的,只需要上传war/zip即可,有的paas平台能自行产生简单的部署文件,有的则是需要自己去编写,实现自我控制。

      

2.1.5            补充说明

       附加文档中《补充资料_xx项目-总体设计说明书_20120521.doc》是之前生活易项目的整体设计文档,属于普通项目具有一定的代表性,作为通用的架构文档模板,我们的架构师在项目阶段中,会要求出具一份架构文档,此文档具有参考价值。

       因为作为模板,需要架构师在使用的时候,替换部分文字说明和图片,其中如果是红色字体和蓝色字体,则是附加说明,在正式成文的时候需要删除。架构师在文档中

 

  • 需要出具4张图:系统架构图,功能架构图,软件部署图,硬件部署图。其中硬件部署分为软部署和硬部署。

  • 主要的类设计(静态类),关键流程出具时序图(主要模块给一个时序图,用一个demo,走敏捷方式)

  • 主要的POJO

  • 主要的组件说明

来源: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