研发团队的总体架构设计方案

研发团队的总体架构设计方案

ID:47494762

大小:400.44 KB

页数:18页

时间:2020-01-12

研发团队的总体架构设计方案_第1页
研发团队的总体架构设计方案_第2页
研发团队的总体架构设计方案_第3页
研发团队的总体架构设计方案_第4页
研发团队的总体架构设计方案_第5页
资源描述:

《研发团队的总体架构设计方案》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库

1、....研发团队的总体架构设计方案InfoQ微信号infoqchina功能介绍有内容的技术社区媒体写在前面企业总体架构是什么,有什么用,具体怎么做呢?以我曾任职的公司为案例,一起来探讨这个问题。这家公司当时有200位研发人员和200多台服务器,我刚进这家公司时,他们的系统就已经玩不下去了,总是出现各种问题,例如日常发布系统时或访问量稍微过大时,系统就会出现很多故障,而且找不到故障发生的根本原因。专业....我进这家公司后的主要任务就是对这个系统进行升级改造,花了一个半月的时间写了那份企业总体架构文档,文档共有124页

2、,直接指导了之后的技术改造,下图是那份文档的目录。一、企业商务模型企业商务模型的内容主要包括主营业务、商务模式、商务主体、竞品分析、组织架构、商务运作模型和业务流程等。主营业务即公司做什么业务,商业模式即公司怎么赚钱,商务主体即哪几个人在一起做这门生意,竞品分析即了解竞争对手的情况,组织架构即公司部门是怎么划分的。组织架构图中标出人数,根据系统与业务之间对应关系,可以了解系统中哪些模块使用频率高,以及业务与其对应模块的复杂度。商务运作模型即公司是如何运作的,售前做计划,找供应商把东西买进来后,经过服务和结算,再卖给我

3、们的经销商和采购商,使我们获得利润,售后进行大数据分析最后又指导着我们的售前,整个过程形成良性循环。可以把一家公司想象成一台机器,输进去的是钱,转一转后,又能够生出更多的钱出来。专业....最后是业务流程和更多业务资料下载,业务流程包括预订流程、订单处理流程、产品供应流程、财务结算流程、账户管理流程。企业商务模型的建立,指导着整个应用系统模型的建立,毕竟系统是为业务服务的。二、架构现状架构现状的内容主要包括:功能架构、应用架构、数据设计和物理架构。功能架构专业....功能架构主要包括功能、角色和权限三部分。功能是企业

4、服务,用户使用的每一个功能,就是企业的每一个服务。角色是用户操作的归类,功能与角色的对应关系即权限。了解系统架构的现状,从功能架构开始。应用架构应用就是处理器,应用架构的内容包括现有架构图、Web应用现状、作业小应用(Job)现状和接口架构。其中,接口是应用层面的关键,它是一个程序与另外一个程序交互的部分。专业....应用架构图表列出了哪些业务逻辑没有被重用,换句话说业务逻辑被多少个应用调用,就需要被重复开发多少次,一旦改了一个地方,就要同时改多个地方,导致系统开发效率非常低下。各业务逻辑如预订逻辑,虽然被多个应用调

5、用,但它们与应用是没有关系的,业务逻辑可以独立的存在,也可以寄宿于多个应用。业务逻辑是一个业务操作的抽象,而业务应用与业务部门共同完成了业务操作。数据设计100多个数据库,一万多张表,能否使用一张E-R图来表示呢?它是可以的。**数据设计依赖于企业的数据,而不是数据库的设计,对企业数据适当做归类,会直接导致数据设计,最终画出E-R图,数据设计完成后,数据库设计就自然而然出来了。超越库、超越表去看这张E-R图,可以看出它包括产品、订单、结算、用户、基础设施这五类数据。低层的E-R图可以变,但是高层的E-R图一般不会变化

6、,因为它是根据你的业务模型而定,业务模型稳定,高层E-R专业....图也是稳定的。数据库只要早期设计得好,是可以做到易伸缩、易拆分的。下图从内往外看,一个框既可以是一个库,也可以是一个模块,还可以是一个表。在业务发展的早期它可以是一个库,里面有5个模块,中期可以分为5个库,后期以更低级别可以分为更多的库,这与业务阶段及系统复杂度相关。在数据的设计完成后,数据库的设计也就很容易规划和调整。以上是数据库、数据表之间的静态关系,接下来我们介绍数据的流转状态即状态图。通过数据状态图去了解现有数据流转变迁,如国内订单状态变迁图

7、,这种图的价值不仅在于数据库层,还在于服务化。图中的从等待支付到支付成功,中间有个支付行为,通过这个支付行为把数据状态变更为支付成功,否则继续等待,直到超时关闭订单。这个支付行为可以做成一个微服务,然后由不同的应用去调用。专业....物理架构物理架构的内容主要包括IDC机房、机房之间访问关系、机房内服务器物理部署图、机房与业务分布、网站架构、数据库架构、集群清单和域名清单。将这些内容以列表和图形方式整理出来,就会很容易了解和发现问题,只有发现问题才能解决问题,特别是在全局体系架构方面,这也是表和图的价值所在。当时这家

8、公司共有5个地区、8个机房,虽然只有200多台服务器,但分布很散,导致物理结构复杂,通讯也很复杂。技改前故障不断,其主要的一个原因就是物理架构不合理,运维要占60%、70%专业....的责任,当时却把责任归咎为应用架构,这是个错误的方向。物理架构的不合理,应用架构是很难合理的,因为物理架构是我们的基础设施,位于最底层,下层为上层服务,运维要为应

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。