业务架构、应⽤架构、数据架构和技术架构
企业总体架构是什么？有什么⽤？具体怎么做？以我曾任职的公司为案例，⼀起来探讨这个问题。
这家公司当时有 200 位研发⼈员和 200 多台服务器，我刚进这家公司时，系统已经玩不下去了，总是出现各种问题，例如⽇常发布系统时或访问量稍微过⼤时，系统就会出现很多故障，⽽且不到故障发⽣的根本原因。
我进公司后主要的任务就是对这个系统进⾏升级改造，花了⼀个半⽉的时间写了份企业总体架构⽂档，⽂档共有 124 页，直接指导了之后的技术改造，下图是那份⽂档的⽬录，⽂末有相关资料下载地址。
企业商务模型
企业商务模型的内容主要包括主营业务、商务模式、商务主体、竞品分析、组织架构、商务运作模型和业务流程等。
主营业务即公司做什么业务。
商业模式即公司怎么赚钱。
商务主体即哪⼏个⼈在⼀起做这门⽣意。
竞品分析即了解竞争对⼿的情况。
组织架构即公司部门是怎么划分的，组织架构图中标出⼈数，根据系统与业务之间对应关系，可以了解系统中哪些模块使⽤频率⾼，以及业务与其对应模块的复杂度。
商务运作模型即公司是如何运作的，售前做计划，供应商把东西买进来后，经过服务和结算，再卖给我们的经销商和采购商，使我们获得利润，售后进⾏⼤数据分析最后⼜指导着我们的售前，整个过程形成良性循环。
可以把⼀家公司想象成⼀台机器，输进去的是钱，转⼀转后，⼜能够⽣出更多的钱出来。
最后是业务流程和附档资料，业务流程包括预订流程、订单处理流程、产品供应流程、财务结算流程、账户管理流程。企业商务模型的建⽴，指导着整个应⽤系统模型的建⽴，它是整个应⽤系统建设的基础和前提，毕竟应⽤系统是为业务服务的。
架构现状
架构现状的内容主要包括：功能架构、应⽤架构、数据设计和物理架构。
功能架构
功能架构主要包括功能、⾓⾊和权限三部分。功能是企业服务，⽤户使⽤的每⼀个功能，就是企业的每⼀个服务。⾓⾊是⽤户操作的归类，功能与⾓⾊的对应关系即权限。了解系统架构的现状，从功能架构开始。
应⽤架构
应⽤就是处理器，应⽤架构的内容包括现有架构图、Web 应⽤现状、作业⼩应⽤（Job）现状和接⼝架构。其中，接⼝是应⽤层⾯的关键，它是⼀个程序与另外⼀个程序交互的部分。
应⽤架构图表列出了哪些业务逻辑没有被重⽤，换句话说业务逻辑被多少个应⽤调⽤，就需要被重复开发多少次，⼀旦改了⼀个地⽅，就要同时改多个地⽅，导致系统开发效率⾮常低下。
各业务逻辑如预订逻辑，虽然被多个应⽤调⽤，但它们与应⽤是没有关系的，业务逻辑可以独⽴的存在，也可以寄宿于多个应⽤。业务逻辑是⼀个业务操作的抽象，⽽业务应⽤与业务部门共同完成了业务操作。
数据设计
100 多个数据库，⼀万多张表，能否使⽤⼀张 E-R 图来表⽰呢？它是可以的。
数据设计依赖于企业的数据，⽽不是数据库的设计，对企业数据适当做归类，会直接导致数据设计，最终画出 E-R 图，数据设计完成后，数据库设计就⾃然⽽然出来了。
超越库、超越表去看这张 E-R 图，可以看出它包括产品、订单、结算、⽤户和基础设施这五类数据。低层的 E-R 图可以变，但是⾼层的 E-R 图⼀般不会变化，因为它是根据你的业务模型⽽定，业务模型稳定，⾼层 E-R 图也是稳定的。
数据库只要早期设计得好，是可以做到易伸缩、易拆分的。下图从内往外看，⼀个框既可以是⼀个库，也可以是⼀个模块，还可以是⼀个表。
在业务发展的早期它可以是⼀个库，⾥⾯有 5 个模块，中期可以分为 5 个库，后期以更低级别可以分为更多的库，这与业务阶段及系统复杂度相关。在数据的设计完成后，数据库的设计也就很容易规划和调整。
以上是数据库、数据表之间的静态关系，接下来我们介绍数据的流转状态即状态图。通过数据状态图去了解现有数据流转变迁，如国内订单
状态变迁图，这种图的价值不仅在于数据库层，还在于服务化。
图中的从等待⽀付到⽀付成功，中间有个⽀付⾏为，通过这个⽀付⾏为把数据状态变更为⽀付成功，否
则继续等待，直到超时关闭订单。这个⽀付⾏为可以做成⼀个微服务，然后由不同的应⽤去调⽤。
物理架构
物理架构的内容主要包括 IDC 机房、机房之间访问关系、机房内服务器物理部署图、机房与业务分布、⽹站架构、数据库架构、集清单和域名清单。
将这些内容以列表和图形⽅式整理出来，就会很容易了解和发现问题，只有发现问题才能解决问题，特别是在全局体系架构⽅⾯，这也是表和图的价值所在。
当时这家公司共有 5 个地区、8 个机房，虽然只有 200 多台服务器，但分布很散，导致物理结构复杂，通讯也很复杂。技改前故障不断，其主要的⼀个原因就是物理架构不合理，运维要占 60%、70% 的责任，当时却把责任归咎为应⽤架构，这是个错误的⽅向。
物理架构的不合理，应⽤架构是很难合理的，因为物理架构是我们的基础设施，位于最底层，下层为上层服务，运维要为应⽤服务，应⽤要为业务服务，业务要为客⼈服务。
领域模型
领域模型关注概念，关注职责、关注边界、关注交互，只有先确定职责和边界，交互才会很清晰。领域
模型是针对现有问题域提出⼀个系统解决⽅案，然后在图表上建⽴完整的模型，如同⽤ AutoCAD 画的施⼯图纸⼀样。
领域模型属于概要设计阶段，对于单个应⽤架构设计，⾸先需要了解业务和功能需求、⽤例图、⽤例活动图，然后才是领域模型。业务流程图是对业务操作的抽象，领域图是对业务逻辑代码的抽象。
建⽴领域词汇是建⽴领域模型的第⼀步，它能统⼀词汇明确概念，以减少⼀词多义、⼀义多词的情况。概念⼀旦确定，再扩展属性和⾏为，然后把它当作⼀个单元与其它事物构建在⼀起，就会很容易形成模型，领域模型与企业商务模型中的业务流程图有参考对应关系。
领域模型在实现时可⼤可⼩，在业务的早期，在系统⽐较⼩的情况下，它有可能是⼀个类。当系统做⼤了以后，它可能是个 DLL 库。再做更⼤⼀点的时候，它可能是⼀个服务，给不同的应⽤去调⽤。
每⼀个⽅法都有成为服务的潜质，特别是在系统中后期。领域模型是业务逻辑代码的施⼯图纸，它不仅有利于对现在系统业务逻辑的了解，同时也指导未来的架构改造。
架构规划
当我们了解了业务、了解了架构的现状，发现现有架构的问题，接下来就可以做中远期架构规划，以及架构的调整和具体实施。架构规划内容包括：顶层架构规划、⽹站功能规划、应⽤规划、SOA 规划、分
层架构规划、数据库规划和物理规划等。
顶层架构规划
上图是顶层架构的俯视图和侧视图。第⼀张图是俯视图，坐在飞机上看，整个顶层架构最外层的是功能，中间的是业务操作，内层的是数据。
功能对应业务系统的⽤户界⾯，操作对应业务系统⾥的服务，数据对应业务系统的数据存储如数据库。
第⼆张图是剖⾯图，切⼀⼑来看，上层是应⽤，中层是服务和框架，下层是基础设施数据中⼼。从图中的服务层可以看出，服务的归类跟业务流程的归类有很⼤关系。
⽹站功能规划
⽹站功能规划就是功能的重新划分，对照着架构现状，未来的功能应该如何调整？如案例中的国内⽹站功能规划，分别画出了全局功能图、采购商功能图、平台商功能图和供应商功能图。
其实在做⽹站功能规划的时候，更多需要考虑现状，⽽不是未来调整的部分，如果没有很⼤问题，则不做调整，尊重历史。因为有些东西（如名称）⽤户已经使⽤很久了，调整往往⽐较难，合理⼤于准确。
应⽤规划
系统是什么？系统 = 元素 + 关系。应⽤架构是什么？应⽤架构 = 应⽤ + 架构。应⽤就是系统的最⼩单元，应⽤分类和应⽤编号则构成了应⽤关系即应⽤的架构。
如上图中的案例，应⽤分类新建了框架 FX 和公共业务系统 CBS，在原有的 200 多个应⽤中并没有这两个产品线，⽽是分布在了不同的业务线中，从⽽导致重复建设。
应⽤编号是给每个应⽤分配⼀个六位的数字 ID，就如同我们的⾝份证⼀样，头两位表⽰产品线，中间两位表⽰⼦系统，最后两位表⽰应⽤，如 100206。应⽤编号是应⽤管理、依赖和追踪的基础，集中式⽇志和监控框架都有使⽤到应⽤编号。
SOA 规划
SOA 规划就是接⼝规划，它的归类与商务模型中的业务流程有参考对应关系。上图案例有五个服务中⼼：预订服务、订单处理服务、产品供应服务、财务结算服务和公共服务。
每个服务只需要实现⼀套⾃⼰的逻辑，我们的前台、后台、接⼝、作业⼩应⽤等都可以调⽤，服务的逻辑跟我们的业务逻辑是⼀致的，修改代码的时候只需要改⼀个地⽅就可以影响到所有调⽤到这服务的前端应⽤。
分层架构
分层架构看似很简单，但保证整个研发中⼼都使⽤统⼀的分层架构就不容易了。那么要如何去做，以达到提⾼编写代码效率、保证⼯程统⼀性的⽬的呢？
先简单介绍下当前两种⽐较流⾏的分层架构体系，⼀种是领域架构：仓储层（Repository Layer）、领域层（Domain Layer）、应⽤服务层（Application Layer）、表现层（Presentation Layer）和基础公共层（Infrastructure Layer），见下图。
另⼀种是相对传统地分为三层：数据层（Data Layer）、应⽤逻辑层（Business Layer）和表现层（Presentation Layer），见下图。
领域架构和三层架构之间有什么区别？我们是这样认为的，在早期我们做三层架构的时候，⼤都以表来做驱动的，在做领域架构的时候，⼤都以业务逻辑来驱动的，两者的区别确实⽐较明显。
但到了现在，如果都以业务逻辑为中⼼的话，实际上两者并没有本质区别。当时，我所在公司采⽤了第⼆种分层法，我们希望把分层做得极简，也就是说哪怕刚毕业进来的员⼯，在分层时基本上也不会乱。
⽽相对第⼀种分层法，第⼆种分层法简单很多。每⼀个应⽤的代码量都不应该很⼤，⼀旦⼯程变得过⼤，我们就会把它适当拆分，⽽不是全部放在⼀个单块应⽤⾥。
总之，我认为分层越简单，整个软件结构就越清晰，代码就越容易统⼀。把⼯程做得极简，才有利于复
制，有利于业务的快速构建，有利于规模化、稳定可靠。
数据库规划
数据库是整个信息系统中⽣命周期最长、最难修改的部分，所以要加强规划。数据库的设计⾄少要提前两步，具体根据⾼层 E-R 图和数据设计来新建数据库，早建要⽐晚建好。
数据库调整的代价⼤、周期长，长时间产⽣的问题，需要长时间来解决，先在新库⾥解决新表，再根据当前业务和应⽤的需求，逐步调整旧表。
物理规划
物理架构的规划内容包括集规划和域名规划。⾸先是集规划。
20 倍规划、5 倍设计和 1.5 倍实施：规划和设计要⼤⼀些，但实施时⼩⼀些，这样不仅便于将来的扩展，也节省了当前的费⽤。
两个逻辑⽹络：⼀个内⽹和⼀个外⽹，两个负载均衡，两个防⽕墙，安全隔离内外⽹。
四条产品线：国际、国内、新业务以及公共业务，单点登录和企业⽀付⽹关等公共业务也属于⼀条产品线。
六个集：Web 集、SOA 集、中间件集、数据库集、Job 集和 ITD 集。
以上横向集与纵向产品线形成了⼀个矩阵结构，也基本确定了⽹络基础架构。对于域名规划。对内的域名该改的改，该停⽤的停⽤，该合并的合并。对外的域名要尽量少改，要改的话也要有历史继承性（如跳转），要尽量减⼩对⽤户的影响。
其它
除以上架构规划外，还有⼀些其它重要项，如源代码管理规划、⽂档管理规划、技术选型和团队分⼯。为什么还要做这些呢？因为统⼀了源代码怎么放、每个部门的⽂档怎么放、将来要⽤什么⼯具版本，才利于团队的协作，基于统⼀的环境才能有更⾼层次地提升。
对于团队分⼯，需要逐步对齐组织架构与系统的架构规划。对于技术选型，需要注意中间件的引进，要有节奏性，⼒量要相对集中，要⼩规模试点，⾮核⼼项⽬，试⽤成功后再进⾏⼤规模推⼴。
架构实施
做完架构规划后，就是架构实施落地了。我们的架构实施整体思路是：树⽬标、给地图、⽴榜样、抓重点、造⽂化、建制度、整环境、组建架构部。
架构部内招⼏名⽼程序员，外招⼏个架构师。内部⾛出去，提⾼眼界。外部⽜⼈请进来，落地了解历史和业务。技术建议是：SOA 服务化、基础设施平台化、公共业务服务化、加强项⽬概要设计。
当研发团队达到 200 多⼈、有了⼏百个应⽤，且在故障不断的情况下，不能与以前⼀样没有设计就开始编码，⽽是做加强项⽬概要设计及评审。后⾯的补与前⾯的防，两⼿都要抓，两⼿都要硬。
具体计划是：Roadmap 分步实施，改造⼀期、改造⼆期、改造三期，近细远粗、实事求是、逐步细化、逐步完善。不断⽴技术改造项⽬，不断将技改与业务研发项⽬相结合，技改即是⼯单、⼯单即是技改。避免对业务过多地影响，并不断有业务价值输出，这是架构改造得以持续实施的关键！
以上简单地介绍了总体架构的编写⽅法，我们的编写思路是先了解业务，建⽴企业商务模型，主要包括静态的商务主体、组织架构和动态的商务运作模型和业务流程。
接着了解架构现状，建⽴现有信息系统模型，主要包括功能架构、应⽤架构、数据设计和物理架构。⼀个是商务，⼀个是电⼦，两者即是整个公司的电⼦商务系统。
然后在企业商务模型和现有系统模型之上建⽴领域模型，领域模型它相对稳定，直接指导着接下来的架构规划，最后⼀定要落地即架构实施。
附档是去掉敏感信息后的真实案例，它的价值如下：
Big Picture，全局蓝图，起到⽅向性和指导性。
将隐性知识显性化，⽅便传达、⼴⽽告之。
对于新员⼯的价值，快速⼊门。
对于⽼员⼯的价值，了解全局，过程梳理，然后专注于⾃⼰的部分。
关于企业总体架构，你可以参考标准 TOGAF(开放组体系结构框架)。其实，我们是在完成那份⽂档后才知道 TOGAF，它们之间有很多相似之处和不同之处。
TOGAF 的内容主要包括业务架构、应⽤架构、数据架构和技术架构，⽽我们当时只是以解决公司系统架构问题为导向、以时间为主线，内容有企业商务模型、架构现状、领域模型、架构规划和架构实施。
⽅法论很重要，但看到事物本⾝的特点，深⼊问题以及到解决办法更为重要。欢迎点赞和拍砖！
案例参考：
本系列⽂章涉及内容清单如下（并不按这顺序发布），其中有感兴趣的，欢迎关注：
开篇：
网站架构
缓存 Redis：
消息队列 RabbitMQ：
集中式⽇志 ELK：
任务调度 Job：
应⽤监控 Metrics：
微服务框架 MSA：
⼩⼯具：Dapper.NET/EmitMapper/AutoMapper/Autofac/NuGet
发布⼯具 Jenkins
总体架构设计：电商如何做企业总体架构？
单个项⽬架构设计
统⼀应⽤分层：
调试⼯具 WinDbg
单点登录
企业⽀付⽹关
结篇
作者介绍
张辉清，10 多年的 IT ⽼兵，先后担任携程架构师、古⼤集团⾸席架构、中青易游 CTO 等职务，主导过两家公司的技术架构升级改造⼯作。现关注架构与⼯程效率，技术与业务的匹配与融合，技术价值与创新。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。