2        项目架构

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

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

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

2.1 架构模板

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

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

2.1.1            数据表现

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

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

• 表驱动：

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

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

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

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

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

• 页面驱动：

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

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

• 领域驱动

       领域模型是对领域内的概念类或现实世界中对象的可视化表示，属于从中间往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个层面来支持流程化的应用，webflow，apiflow，workflow

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