企业整体架构是什么，有什么用，具体怎么作呢？以我曾任职的公司为案例，一块儿来探讨这个问题。这家公司当时有200位研发人员和200多台服务器，我刚进这家公司时，他们的系统就已经玩不下去了，老是出现各类问题，例如平常发布系统时或访问量稍微过大时，系统就会出现不少故障，并且找不到故障发生的根本缘由。我进公司后主要任务就是对这个系统进行升级改造，花了一个半月的时间写了那份企业整体架构文档，文档共有124页，直接指导了以后的技术改造，下图是那份文档的目录。
1、企业商务模型
企业商务模型的内容主要包括主营业务、商务模式、商务主体、竞品分析、组织架构、商务运做模型和业务流程等。
主营业务即公司作什么业务，商业模式即公司怎么赚钱，商务主体即哪几我的在一块儿作这门生意，竞品分析即了解竞争对手的状况，组织架构即公司部门是怎么划分的。组织架构图中标出人数，根据系统与业务之间对应关系，能够了解系统中哪些模块使用频率高，以及业务与其对应模块的复杂度。商务运做模型即公司是如何运做的，售前作计划，找供应商把东西买进来后，通过服务和结算，再卖给咱们的经销商和采购商，使咱们得到利润，售后进行大数据分析最后又指导着咱们的售前，整个过程造成良性循环。能够把一家公司想象成一台机器，输进去的是钱，转一转后，又可以生出更多的钱出来。
最后是业务流程和附档资料，业务流程包括预订流程、订单处理流程、产品供应流程、财务结算流程、帐户管理流程。企业商务模型的创建，指导着整个应用系统模型的创建，它是整个应用系统建设的基础和前提，毕竟应用系统是为业务服务的。
2、架构现状
架构现状的内容主要包括：功能架构、应用架构、数据设计和物理架构。
2.一、功能架构
功能架构主要包括功能、角色和权限三部分。功能是企业服务，用户使用的每个功能，就是企业的每个服务。角色是用户操做的归类，功能与角色的对应关系即权限。了解系统架构的现状，从功能架构开始。
2.二、应用架构
应用就是处理器，应用架构的内容包括现有架构图、Web应用现状、做业小应用（Job）现状和接口架构。其中，接口是应用层面的关键，它是一个程序与另一个程序交互的部分。
应用架构图表列出了哪些业务逻辑没有被重用，换句话说业务逻辑被多少个应用调用，就须要被重复开发多少次，一旦改了一个地方，就要同时改多个地方，致使系统开发效率很是低下。各业务逻辑如预订逻辑，虽然被多个应用调用，但它们与应用是没有关系的，业务逻辑能够独立的存在，也能够寄宿于多个应用。业务逻辑是一个业务操做的抽象，而业务应用与业务部门共同完成了业务操做。
2.三、数据设计
100多个数据库，一万多张表，可否使用一张E-R图来表示呢？它是能够的。数据设计依赖于企业的数据，而不是数据库的设计，对企业数据适当作归类，会直接致使数据设计，最终画出E-R图，数据设计完成后，数据库设计就天然而然出来了。超越库、超越表去看这张E-R图，能够看出它包括产品、订单、结算、用户、基础设施这五类数据。低层的E-R图能够变，可是高层的E-R图通常不会变化，由于它是根据你的业务模型而定，业务模型稳定，高层E-R图也是稳定的。数据库只要早期设计得好，是能够作到易伸缩、易拆分的。下图从内往外看，一个框既能够是一个库，也能够是一个模块，还能够是一个表。在业务发展的早期它能够是一个库，里面有5个模块，中期能够分为5个库，后期以更低级别能够分为更多的库，这与业务阶段及系统复杂度相关。在数据的设计完成后，数据库的设计也就很容易规划和调整。
以上是数据库、数据表之间的静态关系，接下来咱们介绍数据的流转状态即状态图。经过数据状态图去了解现有数据流转变迁，如国内订单状态变迁图，这种图的价值不只在于数据库层，还在于服务化。图中的从等待支付到支付成功，中间有个支付行为，经过这个支付行为把数据状态变动为支付成功，不然继续等待，直到超时关闭订单。这个支付行为能够作成一个微服务，而后由不一样的应用去调用。
2.四、物理架构
物理架构的内容主要包括IDC机房、机房之间访问关系、机房内服务器物理部署图、机房与业务分布、网站架构、数据库架构、集群清单和域名清单。将这些内容以列表和图形方式整理出来，就会很容易了解和发现问题，只有发现问题才能解决问题，特别是在全局体系架构方面，这也是表和图的价值所在。当时这家公司共有5个地区、8个机房，虽然只有200多台服务器，但分布很散，致使物理结构复杂，通信也很复杂。技改前故障不断，其主要的一个缘由就是物理架构不合理，运维要占60%、70%的责任，当时却把责任归咎为应用架构，这是个错误的方向。物理架构的不合理，应用架构是很难合理的，由于物理架构是咱们的基础设施，位于最底层，下层为上层服务，运维要为应用服务，应用要为业务服务，业务要为客人服务。
3、领域模型
领域模型关注概念，关注职责、关注边界、关注交互，只有先肯定职责和边界，交互才会很清晰。领域模型是针对现有问题域提出一个系统解决方案，而后在图表上创建完整的模型，如同用AutoCAD画的施工图纸同样。领域模型属于概要设计阶段，对于单个应用架构设计，首先须要了解业务和功能需求、用例图、用例活动图，而后才是领域模型。业务流程图是对业务操做的抽象，领域图是对业务逻辑代码的抽象。
创建领域词汇是创建领域模型的第一步，它能统一词汇明确概念，以减小一词多义、一义多词的状况。概念一旦肯定，再扩展属性和行为，而后把它看成一个单元与其它事物构建在一块儿，就会很容易造成模型，领域模型与企业商务模型中的业务流程图有参考对应关系。领域模型在实现时可大可小，在业务的早期，在系统比较小的状况下，它有多是一个类。当系统作大了之后，它多是个DLL库。再作更大一点的时候，它多是一个服务，给不一样的应用去调用。每个方法都有成为服务的潜质，特别是在系统中后期。领域模型是业务逻辑代码的施工图纸，它不只有利于对如今系统业务逻辑的了解，同时也指导将来的架构改造。
4、架构规划
当咱们了解了业务、了解了架构的现状，发现现有架构的问题，接下来就能够作中远期架构规划，以及架构的调整和具体实施。架构规划内容包括：顶层架构规划、网站功能规划、应用规划、SOA规划、分层架构规划、数据库规划和物理规划等。
4.一、顶层架构规划
上图是顶层架构的俯视图和侧视图。第一张图是俯视图，坐在飞机上看，整个顶层架构最外层的是功能，中间的是业务操做，内层的是数据。功能对应业务系统的用户界面，操做对应业务系统里的服务，数据对应业务系统的数据存储如数据库。第二张图是剖面图，切一刀来看，上层是应用，中层是服务和框架，下层是基础设施数据中心。从图中的服务层能够看出，服务的归类跟业务流程的归类有很大关系。
4.二、网站功能规划
网站功能规划就是功能的从新划分，对照着架构现状，将来的功能应该如何调整？如案例中的国内网站功能规划，分别画出了全局功能图、采购商功能图、平台商功能图和供应商功能图。其实在作网站功能规划的时候，更多须要考虑现状，而不是将来调整的部分，若是没有很大问题，则不作调整，尊重历史。由于有些东西（如名称）用户已经使用好久了，调整每每比较难，合理大于准确。
4.三、应用规划
系统是什么，系统=元素+关系。应用架构是什么？应用架构=应用+架构。应用就是系统的最小单元，应用分类和应用编号则构成了应用关系即应用的架构。如上图中的案例，应用分类新建了框架FX和公共业务系统CBS，在原有的200多个应用中并无这两个产品线，而是分布在了不一样的业务线中，从而致使重复建设。应用编号是给每一个应用分配一个六位的数字ID，就如同咱们的身份证同样，头两位表示产品线，中间两位表示子系统，最后两位表示应用，如100206。应用编号是应用管理、依赖和追踪的基础，集中式日志和监控框架都有使用到应用编号。
4.四、SOA规划
SOA规划就是接口规划，它的归类与商务模型中的业务流程有参考对应关系。上图案例有五个服务中心：预订服务、订单处理服务、产品供应服务、财务结算服务和公共服务。每一个服务只须要实现一套本身的逻辑，咱们的前台、后台、接口、做业小应用等均可以调用，服务的逻辑跟咱们的业务逻辑是一致的，修改代码的时候只须要改一个地方就能够影响到全部调用到这服务的前端应用。
4.五、分层架构
分层架构看似很简单，但保证整个研发中心都使用统一的分层架构就不容易了。那么如何保证整个研发中心都使用统一的分层架构呢，以达到提升编写代码效率、保证工程统一性的目的？先简单介绍下当前两种比较流行的分层架构体系，一种是领域架构：仓储层Repository Layer、领域层Domain Layer、应用服务层Application Layer、表现层Presentation Layer和基础公共层Infrastructure Layer，请见第一张图；另外一种是相对传统地分为三层：数据层Data Layer、应用逻辑层Business Layer和表现层Presentation Layer，请见第二张图。
领域架构和三层架构之间有什么区别？咱们是这样认为的，在早期咱们作三层架构的时候，大都以表来作驱动的，在作领域架构的时候，大都以业务逻辑来驱动的，二者的区别确实比较明显，但到了如今，若是都以业务逻辑为中心的话，实际上二者并无本质区别。当时，我所在公司采用了第二种分层法，咱们但愿把分层作得极简，也就是说哪怕刚毕业进来的员工，在分层时基本上也不会乱。而相对第一种分层法，第二种分层法简单不少。每一个应用的代码量都不该该很大，一旦工程变得过大，咱们就会把它适当拆分，而不是所有放在一个单块应用里。总之，我认为分层越简单，整个软件结构就越清晰，代码就越容易统一。把工程作得极简，才有利于复制，有利于业务的快速构建，有利于规模化、稳定可靠。
4.六、数据库规划
数据库是整个信息系统中生命周期最长、最难修改的部分，因此要增强规划。数据库的设计至少要提早两步，具体根据高层E-R图和数据设计来新建数据库，早建要比晚建好。数据库调整的代价大、周期长，长时间产生的问题，须要长时间来解决，先在新库里解决新表，再根据当前业务和应用的需求，逐步调整旧表。
4.七、物理规划
物理架构的规划内容包括集群规划和域名规划。首先是集群规划。20 倍规划、5 倍设计和 1.5 倍实施：规划和设计要大一些，但实施时小一些，这样不只便于未来的扩展，也节省了当前的费用；两个逻辑网络：一个内网和一个外网，两个负载均衡，两个防火墙，安全隔离内外网；四条产品线：国际、国内、新业务以及公共业务，单点登陆和企业支付网关等公共业务也属于一条产品线；六个集群：Web 集群、SOA 集群、中间件集群、数据库集群、Job 集群和 ITD 集群。以上横向集群与纵向产品线造成了一个矩阵结构，也基本肯定了网络基础架构。对于域名规划。对内的域名该改的改，该停用的停用，该合并的合并。对外的域名要尽可能少改，要改的话也要有历史继承性（如跳转），要尽可能减少对用户的影响。
4.八、其它
除以上架构规划外，还有一些其它重要项，如源代码管理规划、文档管理规划、技术选型和团队分工。为何还要作这些呢？由于统一了源代码怎么放、每一个部门的文档怎么放、未来要用什么工具版本，才利于团队的协做，基于统一的环境才能有更高层次地提高。对于团队分工，须要逐步对齐组织架构与系统的架构规划。对于技术选型，须要注意中间件的引进，要有节奏性，力量要相对集中，要小规模试点，找非核心项目，试用成功后再进行大规模推广。
5、架构实施
作完架构规划后，就是架构实施落地了。咱们的架构实施总体思路是：树目标、给地图、立榜样、抓重点、造文化、建制度、整环境、组建架构部。架构部内招几名老程序员，外招几个架构师。内部走出去，提升眼界。外部牛人请进来，落地了解历史和业务。技术建议是：SOA服务化、基础设施平台化、公共业务服务化、增强项目概要设计。当研发团队达到200多人、有了几百个应用，且在故障不断的状况下，不能与之前同样没有设计就开始编码，而是作增强项目概要设计及评审。后面的补与前面的防，两手都要抓，两手都要硬。具体计划是：Roadmap分步实施，改造一期、改造二期、改造三期，近细远粗、实事求是、逐步细化、逐步完善。不断立技术改造项目，不断将技改与业务研发项目相结合，技改便是工单、工单便是技改。避免对业务过多地影响，并不断有业务价值输出，这是架构改造得以持续实施的关键！
以上简单地介绍了整体架构的编写方法，咱们的编写思路是先了解业务，创建企业商务模型，主要包括静态的商务主体、组织架构和动态的商务运做模型和业务流程。再了解架构现状，创建现有信息系统模型，主要包括功能架构、应用架构、数据设计和物理架构。一个是商务，一个是电子，二者便是整个公司的电子商务系统。而后在企业商务模型和现有系统模型之上创建领域模型，领域模型它相对稳定，直接指导着接下来的架构规划，最后必定要落地即架构实施。附档是去掉敏感信息后的真实案例，它的价值以下：
- Big Picture，全局蓝图，起到方向性和指导性。
- 对于老员工的价值，了解全局，过程梳理，而后专一于本身的部分。
关于企业整体架构，你能够参考标准TOGAF(开放组体系结构框架)。其实，咱们是在完成那份文档后才知道TOGAF，它们之间有不少类似之处和不一样之处。TOGAF的内容主要包括业务架构、应用架构、数据架构和技术架构，而咱们当时只是以解决公司系统架构问题为导向、以时间为主线，内容有企业商务模型、架构现状、领域模型、架构规划和架构实施。方法论很重要，但看到事物自己的特色，深刻问题以及找到解决办法更为重要。欢迎点赞和拍砖！
案例参考：
