研发团队的总体架构方案与对策.docxVIP

专业资料 专业资料 研发团队的总体架构设计案 写在前面 企业总体架构是什么，有什么用，具体怎么做呢？以我曾任职的公司为案例，一起来探讨这个问题。这家 公司当时有200位研发人员和200多台服务器，我刚进这家公司时，他们的系统就已经玩不下去了，总 是出现各种问题，例如日常发布系统时或访问量稍微过大时，系统就会出现很多故障，而且找不到故障发 生的根本原因。 我进这家公司后的主要任务就是对这个系统进行升级改造，花了一个半月的时间写了那份企业总体架构文 档，文档共有124页，直接指导了之后的技术改造，下图是那份文档的目录。 2建业曲君锲凰 3彗垸用姿 1- d訥顿 卜计 削了接口钿 ? g昨魄 9,1現巔加 r g.诃炖 t财胡魄 r鼻$整毘麒3 f assre t 10^393 、企业商务模型 企业商务模型的容主要包括主营业务、商务模式、商务主体、竞品分析、组织架构、商务运作模型和业务 流程等。 主营业务即公司做什么业务，商业模式即公司怎么赚，商务主体即哪几个人在一起做这门生意，竞品分析 即了解竞争对手的情况，组织架构即公司部门是怎么划分的。组织架构图中标出人数，根据系统与业务之 间对应关系，可以了解系统中哪些模块使用频率高，以及业务与其对应模块的复杂度。商务运作模型即公 司是如运作的，售前做计划，找供应商把东西买进来后， 经过服务和结算，再卖给我们的经销商和采购商, 使我们获得利润，售后进行大数据分析最后又指导着我们的售前，整个过程形成良性循环。可以把一家公 司想象成一台机器，输进去的是，转一转后，又能够生出更多的出来。 最后是业务流程和更多业务资料下载，业务流程包括预订流程、订单处理流程、产品供应流程、财务结算 流程、账户管理流程。企业商务模型的建立， 指导着整个应用系统模型的建立， 毕竟系统是为业务服务的。 二、架构现状 架构现状的容主要包括：功能架构、应用架构、数据设计和物理架构。 功能架构 ■3.1国内全部功能 urn 4 系纯管理*= 资料信息口 ? 投诉，蚁 1 俺登机牌供应管理户 4 机场眼务? 已礪认订单代换处理z 门 4 换登机牌背理」 W 吗 p血导入创建订車p 4J ■4 航班查询回航“ 4 采购机票管理存 团队票由渝 1 申请改签财出嗣』 4 三字代码童询） 1 4 当日晨新订单夕 r 1 所有订单查询. 采购报袤下载丿 1 4 4 在线订单管理 自由转畛 4 退废票相关音汨- A 申谢亍程单及査询 * 行程单领用及囊理」 保险管理。 卫 短信充值j 短信平台口 矩信岌送口 匸 * 短信发送历史“ 1 甜时理粒 ■ip 4 勒這査询J修改门 扌 常用软件下载」 机票软件下轶』 4 功能架构主要包括功能、角色和权限三部分。 功能是企业服务，用户使用的每一个功能，就是企业的每 个服务。角色是用户操作的归类， 功能与角色的对应关系即权限 。了解系统架构的现状， 从功能架构开始。 应用架构 应用就是处理器，应用架构的容包括现有架构图、 Web应用现状、作业小应用（Job）现状和接口架构。 其中，接口是应用层面的关键，它是一个程序与另外一个程序交互的部分。 业订円/? 口数据坤Kus iness i^wrDM* Lny^rbhlA LiHWDftt n bi/rrDi、 业订円/? 口 数据坤 Kus iness i^wr DM* Lny^r bhlA LiHW Dftt n bi/rr Di、l h InH^r ■■玄BL - g fta. BEM, Mdbrle- 肃台.后台卜柞业小应用.Mobile 曲台.后各榨业目疊期、MoMe^ 曲劳塔jiiysr 闸台i后台丄BEMx作吐小应用i htobde，* 18綽馬脅.PEM.廉业』S罔* 3和 应用架构图表列出了哪些业务逻辑没有被重用，换句话说业务逻辑被多少个应用调用，就需要被重复开发 多少次，一旦改了一个地，就要同时改多个地，导致系统开发效率非常低下。各业务逻辑如预订逻辑，虽 然被多个应用调用，但它们与应用是没有关系的，业务逻辑可以独立的存在，也可以寄宿于多个应用。 务逻辑是一个业务操作的抽象，而业务应用与业务部门共同完成了业务操作 。 数据设计 100多个数据库，一万多表，能否使用一 E-R图来表示呢？它是可以的。**数据设计依赖于企业的数据， 而不是数据库的设计，对企业数据适当做归类，会直接导致数据设计，最终画出 E-R图，数据设计完成 后，数据库设计就自然而然出来了。超越库、超越表去看这 E-R图，可以看出它包括产品、订单、结算、 用户、基础设施这五类数据。低层的 E-R图可以变，但是高层的 E-R图一般不会变化，因为它是根据你 的业务模型而定，业务模型稳定，高层 E-R图也是稳定的。数据库只要早期设计得好，是可以做到易伸 缩、易拆分的。下图从往