研发团队的总体架构设计方案 (2).docx

《研发团队的总体架构设计方案 (2).docx》由会员分享，可在线阅读，更多相关《研发团队的总体架构设计方案 (2).docx（16页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、研发团队的总体架构设计方案研发团队的总体架构设计方案写在前面企业总体架构是什么，有什么用，详细怎么做呢？以我曾任职的公司为案例，一起来讨论这个问题。这家公司当时有200位研发人员和200多台服务器，我刚进这家公司时，他们的系统就已经玩不下去了，总是出现各种问题，例如日常发布系统时或访问量略微过大时，系统就会出现很多故障，而且找不到故障发生的根本原因。我进这家公司后的主要任务就是对这个系统进行升级改造，花了一个半月的时间写了那份企业总体架构文档，文档共有124页，直接指导了之后的技术改造，下列图是那份文档的目录。一、企业商务模型企业商务模型的内容主要包括主营业务、商务形式、商务主体、竞品分析、组

2、织架构、商务运作模型和业务流程等。主营业务即公司做什么业务，商业形式即公司怎么赚钱，商务主体即哪几个人在一起做这门生意，竞品分析即了解竞争对手的情况，组织架构即公司部门是怎么划分的。组织架构图中标出人数，根据系统与业务之间对应关系，能够了解系统中哪些模块使用频率高，以及业务与其对应模块的复杂度。商务运作模型即公司是怎样运作的，售前做计划，找供给商把东西买进来后，经过服务和结算，再卖给我们的经销商和采购商，使我们获得利润，售后进行大数据分析最后又指导着我们的售前，整个经过构成良性循环。能够把一家公司想象成一台机器，输进去的是钱，转一转后，又能够生出更多的钱出来。最后是业务流程和更多业务资料下载，

3、业务流程包括预订流程、订单处理流程、产品供给流程、财务结算流程、账户管理流程。企业商务模型的建立，指导着整个应用系统模型的建立，毕竟系统是为业务服务的。二、架构现状架构现状的内容主要包括：功能架构、应用架构、数据设计和物理架构。功能架构功能架构主要包括功能、角色和权限三部分。功能是企业服务，用户使用的每一个功能，就是企业的每一个服务。角色是用户操作的归类，功能与角色的对应关系即权限。了解系统架构的现状，从功能架构开场。应用架构应用就是处理器，应用架构的内容包括现有架构图、Web应用现状、作业小应用Job现状和接口架构。其中，接口是应用层面的关键，它是一个程序与另外一个程序交互的部分。应用架构图

4、表列出了哪些业务逻辑没有被重用，换句话讲业务逻辑被多少个应用调用，就需要被重复开发多少次，一旦改了一个地方，就要同时改多个地方，导致系统开发效率非常低下。各业务逻辑如预订逻辑，固然被多个应用调用，但它们与应用是没有关系的，业务逻辑能够独立的存在，可以以寄宿于多个应用。业务逻辑是一个业务操作的抽象，而业务应用与业务部门共同完成了业务操作。数据设计100多个数据库，一万多张表，能否使用一张E-R图来表示呢？它是能够的。*数据设计依靠于企业的数据，而不是数据库的设计，对企业数据适当做归类，会直接导致数据设计，最终画出E-R图，数据设计完成后，数据库设计就自然而然出来了。超越库、超越表去看这张E-R图

5、，能够看出它包括产品、订单、结算、用户、基础设施这五类数据。低层的E-R图能够变，但是高层的E-R图一般不会变化，由于它是根据你的业务模型而定，业务模型稳定，高层E-R图也是稳定的。数据库只要早期设计得好，是能够做到易伸缩、易拆分的。下列图从内往外看，一个框既能够是一个库，可以以是一个模块，还能够是一个表。在业务发展的早期它能够是一个库，里面有5个模块，中期能够分为5个库，后期以更低级别可以分为更多的库，这与业务阶段及系统复杂度相关。在数据的设计完成后，数据库的设计也就很容易规划和调整。以上是数据库、数据表之间的静态关系，接下来我们介绍数据的流转状态即状态图。通过数据状态图去了解现有数据流转变

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

7、导致物理构造复杂，通讯也很复杂。技改前故障不断，其主要的一个原因就是物理架构不合理，运维要占60%、70%的责任，当时却把责任归咎为应用架构，这是个错误的方向。物理架构的不合理，应用架构是很难合理的，由于物理架构是我们的基础设施，位于最底层，下层为上层服务，运维要为应用服务，应用要为业务服务，业务要为客人服务。三、领域模型领域模型关注概念，关注职责、关注边界、关注交互，只要先确定职责和边界，交互才会很明晰。领域模型是针对现有问题域提出一个系统解决方案，然后在图表上建立完好的模型，好像用AutoCAD画的施工图纸一样。领域模型属于概要设计阶段，对于单个应用架构设计，首先需要了解业务和功能需求、用

8、例图、用例活动图，然后才是领域模型。业务流程图是对业务操作的抽象，领域图是对业务逻辑代码的抽象。建立领域词汇是建立领域模型的第一步，它能统一词汇明确概念，以减少一词多义、一义多词的情况。概念一旦确定，再扩展属性和行为，然后把它当作一个单元与其它事物构建在一起，就会很容易构成模型，领域模型与企业商务模型中的业务流程图有参考对应关系。领域模型在实现时可大可小，在业务的早期，在系统比拟小的情况下，它有可能是一个类。当系统做大了以后，它可能是个DLL库。再做更大一点的时候，它可能是一个服务，给不同的应用去调用。每一个方法都有成为服务的潜质，十分是在系统中后期。领域模型是业务逻辑代码的施工图纸，它不仅有利于对如今系统业务逻辑的了解，同时也指导将来的架构改造。