课程简介

本课程作为系列教程，目标在于探讨软件研发不同阶段的松耦合方案，包括基础技术框架的组件化、基于模板的快速开发环境；业务架构、开发架构的模块化、组件化；运行架构的模块化、微服务化。

阅读完本文后，可以从不同角度审视松耦合架构，通过统筹考虑产品不同阶段的架构设计，来提升系统架构质量。

作者介绍

刘光瑞，现任窝客研发总监，负责窝客产品研发管理及总体架构设计。拥有十几年企业级大型业务系统研发架构经验，成功带领团队设计并研发基于 Tomcat 的组件化微服务架构。热衷于系统架构、Java 技术栈及应用服务器中间件的学习及研究。著有《Tomcat 架构解析》一书。

课程内容

导读：系统架构分解及松耦合综述

说在前面的几句絮语

说起“架构”一词，想必绝大多数有过项目经验的开发人员都不陌生，很多人也将“架构师”作为自己职业发展的一个方向。可“架构”这个词虽然很多中英文书籍都已经对它下了相对比较准确的定义，但是仍然避免不了它在人们心中一直是一种言之较虚的存在。

无论说它是“组件以及组件之间的关系”又或是“一切不能轻易改变的与系统相关的重要的决策、方案、规则和要素”，都很难具象的告诉人们哪些东西应该包含到架构文档中去。至于像“4+1”视图之类的理论，如果严格按照这种形式来组织架构，就会发现有可能遗漏一些关键决策。当然，出现这种情况，完全可以通过增加更多的视图来解决。不过，有些决策却不是可以通过视图能够直观展示的。

如果说架构是一组决策、方案、规则和要素的集合以不同视图向不同干系人的一种展现，那么我们有理由暂时抛开这些理论定义的约束，去问一下我们在架构阶段需要得到哪些信息？需要将哪些内容固化下来，指导以后的设计及开发？

从这个角度上看就会发现，架构也是分层次的。这也或许是为什么架构师也会有很多名称的原因。

国内部分企业将架构上升为一种方法论的角度，试图通过一套方法来合理的演进架构。不得不说，只有从方法论层面来审视架构设计，才能更宏观的明确它在企业中的位置以及它应该如何正确的发展。

笔者早期了解过 TOGAF、Zachman Framework 等企业架构框架（了解不深，不敢妄谈），暂且不提在企业内部实施这种框架的成本以及所带来的价值，作为系统的承建者，它们却也给我们提供了一种高层的思考及分解架构的方式。

系统架构的分解

我们若要描述软件系统的一切重要的决策、方案、规则和要素，仔细分析会发现，它们是多个方面的，这也与 TOGAF 的描述相符。

首先，是业务层面的内容，我们可以称为“业务架构”。可能很多人会问，“业务”不是属于“软件需求规格”该描述的事情吗？与架构有什么关系？

如果我们开发的是一个独立的小规模的软件系统，通过一份“软件需求规格说明书”足以将其需求描述清楚，并作为系统研发的依据。但如果我们所要描述的是整个企业的业务支撑，此时显然不是通过一套系统来解决的，它可能包含数十个独立的系统，它们需要通过定义清晰的接口相互访问，以支持企业业务的正常运作。

此时，需要结合企业的愿景，以高度抽象的方式（不需要关注具体的功能细节描述，此部分应由软件需求规格说明书描述）描述各个系统的核心业务模型、端到端的业务流程，以及它们之间的业务边界、交互过程。另外，对于业务非常复杂的系统，我们需要对其进行按照不同层级进行业务域/功能、过程进行分解，以供不同的干系人参考。通过这种分解，就会明确在整个系统中，有哪些角色、每个角色需要操作管理哪些系统/模块/功能组件、与哪些角色进行交互、交互过程是如何进行的。

这项业务域/功能、过程的分解结果与软件需求规格说明书相互配合，以准确的描述软件的业务需求。通过这种不同层级分解的方式，需求人员才会明确各系统、子系统、组件的业务范围、交互过程，从而基于此进一步细化各个功能点需求。

我们之所以将其称为“业务架构”，是因为它描述的是业务层面的重要决策、业务组件以及组件间的端到端的业务流程，这些组件是以不同抽象层次展现的。它们不会描述系统有几个页面、每个页面有哪些输入、哪些操作，但这些却需要明确包含到需求规格说明书中，以指导设计、开发、测试。

其次，是数据层面的内容，我们可以称之为“数据架构”。从本质上说，应用系统是不同的角色通过不同的功能对数据进行查看和操作的过程，应用系统是数据的记录和流转。对于数据部分，同样有很多关键的决策需要记录，当然这些决策不是指你在数据库建几张表、每张表有哪些列、每一列是什么类型。

数据架构中的内容更多侧重于对核心数据模型、共享数据，以及数据生命周期的描述。通过数据架构，我们可以明确系统各数据域包含的核心模型、数据域边界、共享数据、数据生命周期等。

再次，是应用层面的内容，我们可以将其视为对“业务架构”和“数据架构”向 IT 架构实现层面的转化，这也是与开发最为密切的一部分。通过对“业务架构”中业务域、业务组件、业务模型、业务过程的拆分、合并，从而形成应用架构层面的系统、子系统、模块以及对象。通过对“数据架构”中的数据域、核心模型、共享数据的转化，形成应用架构层面的数据库表设计、共享数据接口设计等。

应用架构还包括集成架构和技术架构。前者包括与第三方系统的集成方式，如共享数据存储、SOA、RESTful、消息中间件等；后者包括基础技术平台的选型。

最后，是基础设施层面的内容，包括我们的系统最终的部署环境：物理机还是云平台、主备还是大规模分布式集群，部署的操作系统：Linux 还是 Windows，还包括数据库环境的搭建、网络环境拓扑等等。有人称之为“技术架构”，但是为了避免与应用架构中的技术部分混淆，我们暂且称之为“基础设施架构”。

综上可以发现，我们认为构建系统的核心决策是多方面的，既包含业务、数据，又包含应用和基础设施。而每一部分，我们又都可以采用一种分层的方式对其进行有效的分解，以便逐步细化，使其边界清晰，以做到高内聚、低耦合。

因此，我们说的松耦合的系统架构，更多的是一种对系统全方位的分析、分解的过程（抱歉，此时方才点出主题）。但在进入正题之前，还请允许我再多言几句这个常见的词汇。

松耦合

想必绝大多数 IT 从业者（这个范围已经足够广了）都对这个词耳熟能详，甚至都会觉得完全没必要再对它进行任何阐述。

但是不得不说，不同岗位对于松耦合的认识是不同的。对于开发人员，如果修改一个接口的时候，不影响其它接口，修改一个数据结构的时候不会影响其他无关的功能，那么我们就说他的代码是松耦合的。对于设计人员，如果变动一个模块的设计不会影响另一个模块，模块间的接口保持相对稳定，那么我们也会说他设计的模块时松耦合的。

这些都是我们常见的松耦合的例子，但显然不是全部。可以想象一下，每次从新构建系统的时候，开发环境中是否有多余的不用的技术组件/框架，仅仅是因为它被包含到了你们的技术平台当中？每次部署/升级系统时，是否每次都是替换全部的发布包？

如果是，那就说明至少在这几个方面，你的平台、系统不是松耦合的。当然，之所以出现这样的问题，是由多种因素综合导致的，这也是为什么我们开篇先把架构的各个方面都罗列一遍的原因。

比如系统无法做到细粒度部署，首先可能是技术平台不支持、可能是应用组件业务层面耦合过重、也可能是部署架构的原因。只有通盘考虑各个环节，每个环节都按照既定的架构目标去设计，才能最终实现架构的真正意义上的松耦合。

内容综述

此系列文章主要从以上讲到的架构的各方面的内容入手，来探讨各种松耦合的方案、方法及途径。

• 首先是业务/数据分层分解。
• 其次是应用架构中的技术平台（后文称为“技术架构”）。
• 再次是应用架构中的功能架构（后文称为“开发架构”）。
• 最后是部署架构部分。

除了业务/数据部分外，其他都不同程度的涉及对技术的选型、方案等的分析与讨论。

总结

本文作为开篇，主要简单讲述了系统架构的各个方面以及交代后续文章的内容。从下一篇开始，我们开始介绍对业务/数据的分层分解。

第01课：业务架构和数据架构松耦合

第02课：技术架构松耦合

第03课：开发架构松耦合

第04课：部署架构松耦合

第05课：总结

阅读全文: http://gitbook.cn/gitchat/column/5a40741a36bc9e132311d014