应用架构的核心使命是什么？阿里高级技术专家这样说

阿里妹导读：什么是架构？关于架构这个概念很难给出一个明确的定义，也没有一个标准的定义。若是，硬是要给一个概述，阿里巴巴高级技术专家张建飞认为架构就是对系统中的实体以及实体之间的关系所进行的抽象描述。今天，张建飞来谈谈应用架构的核心使命是什么，是否与你想得同样？往下看，一块儿寻找答案。

架构

架构始于建筑，是由于人类发展（原始人自给自足住在树上，也就不须要架构），分工协做的须要，将目标系统按某个原则进行切分，切分的原则，是要便于不一样的角色进行并行工做。

为何须要架构？

有系统的地方就须要架构，大到航空飞机，小到一个电商系统里面的一个功能组件都须要设计和架构。

我很喜欢《系统架构：复杂系统的产品设计与开发》里面的一句话：结构良好的创造活动要优于毫无结构的创造活动。

与之相对应的，如今不少敏捷思想提倡no design，只要work就好。期待好的架构能够在迭代中天然涌现。这个想法有点太理想化了，在现实中，只要能work的代码，工程师是不多有动力去重构和优化的。

架构师的职责

做为架构师，咱们最重要的价值应该是“化繁为简”。但凡让事情变得更复杂，让系统变得更晦涩难懂的架构都是值得商榷的。

架构师的工做就是要努力训练本身的思惟，用它去理解复杂的系统，经过合理的分解和抽象，使哪些系统再也不那么难懂。咱们应该努力构建易懂的架构，使得在系统上工做的其余人员（例如设计者、实现者、操做员等）能够较为容易地理解这个系统。

软件架构

软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的链接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，好比具体某个类或者对象。在面向对象领域中，组件之间的链接一般用接口来实现。

软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互做用、指导构件集成的模式以及这些模式的约束组成。软件架构不只显示了软件需求和软件结构之间的对应关系，并且指定了整个软件系统的组织和拓扑结构，提供了一些设计决策的基本原理。

软件架构的核心价值应该只围绕一个核心命题：控制复杂性。他并不意味着某个特定的分层结构，某个特定的方法论（贫血、DDD等）。

软件架构分类

在介绍应用架构以前，咱们先来看一下软件架构的分类。

随着互联网的发展，如今的系统要支撑数亿人同时在线购物、通讯、娱乐的须要，相应的软件体系结构也变得愈来愈复杂。软件架构的含义也变得更加宽泛，咱们不能简单地用一个软件架构来指代全部的软件架构工做。按照我我的理解，我将软件架构划分为：

业务架构：由业务架构师负责，也能够称为业务领域专家、行业专家。业务架构属于顶层设计，其对业务的定义和划分会影响组织结构和技术架构。例如，阿里巴巴在没有中台部门以前，每一个业务部门的技术架构都是烟囱式的，淘宝、天猫、飞猪、1688等各有一套体系结构。然后，成立了共享平台事业部，打通了帐号、商品、订单等体系，让商业基础实施的复用成为可能。

应用架构：由应用架构师负责，他须要根据业务场景的须要，设计应用的层次结构，制定应用规范、定义接口和数据交互协议等。并尽可能将应用的复杂度控制在一个能够接受的水平，从而在快速的支撑业务发展的同时，在保证系统的可用性和可维护性的同时，确保应用知足非功能属性要求（性能、安全、稳定性等）。

分布式系统架构：分布式系统基本是稍具规模业务的必选项。它须要解决服务器负载，分布式服务的注册和发现，消息系统，缓存系统，分布式数据库等问题，同时架构师要在CAP（Consistency，Availability，Partition tolerance）之间进行权衡。

数据架构：对于规模大一些的公司，数据治理是一个很重要的课题。如何对数据收集、数据处理提供统一的服务和标准，是数据架构须要关注的问题。其目的就是统一数据定义规范，标准化数据表达，造成有效易维护的数据资产，搭建统一的大数据处理平台，造成数据使用闭环。

物理架构：物理架构关注软件元件是如何放到硬件上的，包括机房搭建、网络拓扑结构，网络分流器、代理服务器、Web服务器、应用服务器、报表服务器、整合服务器、存储服务器和主机等。

运维架构：负责运维系统的规划、选型、部署上线，创建规范化的运维体系。

典型应用架构

分层架构

分层是一种常见的根据系统中的角色（职责拆分）和组织代码单元的常规实践。常见的分层结构以下图所示：

CQRS

CQS(Command Query Separation，命令查询分离)最先来自于Betrand Meyer（Eiffel语言之父，OCP提出者）提出的概念。其基本思想在于，任何一个对象的方法能够分为两大类：

• 命令(Command)：不返回任何结果(void)，但会改变对象的状态。
• 查询(Query)：返回结果，可是不会改变对象的状态，对系统没有反作用。

六边形架构

六边形架构是Alistair Cockburn在2005年提出，解决了传统的分层架构所带来的问题，实际上它也是一种分层架构，只不过不是上下，而是变成了内部和外部（以下图所示）。

六边形架构又称为端口-适配器架构，这个名字更容器理解。六边形架构将系统分为内部（内部六边形）和外部，内部表明了应用的业务逻辑，外部表明应用的驱动逻辑、基础设施或其余应用。

适配器分为两种类型（以下图所示），左侧表明 UI 的适配器被称为主动适配器（Driving Adapters），由于是它们发起了对应用的一些操做。而右侧表示和后端工具连接的适配器，被称为被动适配器（Driven Adapters），由于它们只会对主适配器的操做做出响应。

洋葱圈架构

洋葱架构与六边形架构有着相同的思路，它们都经过编写适配器代码将应用核心从对基础设施的关注中解放出来，避免基础设施代码渗透到应用核心之中。这样应用使用的工具和传达机制均可以轻松地替换，能够必定程度地避免技术、工具或者供应商锁定。
不一样的是洋葱架构还告诉咱们，企业应用中存在着不止两个层次，它在业务逻辑中加入了一些在领域驱动设计的过程当中被识别出来的层次（Application，Domain Service，Domain model，Infrastructure等）。

另外，它还有着脱离真实基础设施和传达机制应用仍然能够运行的便利，这样可使用 mock 代替它们方便测试。

在洋葱架构中，明确规定了依赖的方向：

• 外层依赖内层；
• 内层对外层无感知。

COLA应用架构

COLA架构是我团队自主研发的应用架构，目前已经开源。在COLA的设计中，咱们充分汲取了经典架构的优秀思想。除此以外，咱们补充了规范设计和扩展设计，而且使用Archetype的方式，将架构固化下来，以即可以快速的在开发中使用。

开源地址

COLA架构目前已经开源，地址： https://github.com/alibaba/COLA

分层设计

COLA的分层是一种改良了的三层架构。主要是将传统的业务逻辑层拆分红应用层、领域层和基础实施层。以下图所示，左边是传统的分层架构，右边是COLA的分层架构。

其每一层的做用范围和含义以下：

1）展示层（Presentation Layer）：负责以Rest的格式接受Web请求，而后将请求路由给Application层执行，并返回视图模型（View Model），其载体一般是DTO（Data Transfer Object）；

2）应用层（Application Layer）：主要负责获取输入，组装上下文，作输入校验，调用领域层作业务处理，若是须要的话，发送消息通知。固然，层次是开放的，如有须要，应用层也能够直接访问基础实施层；

3）领域层（Domain Layer）：主要是封装了核心业务逻辑，并经过领域服务（Domain Service）和领域对象（Entities）的函数对外部提供业务逻辑的计算和处理；

4）基础实施层（Infrastructure Layer）：主要包含Tunnel（数据通道）、Config和Common。这里咱们使用Tunnel这个概念来对全部的数据来源进行抽象，这些数据来源能够是数据库（MySQL，NoSql）、搜索引擎、文件系统、也能够是SOA服务等；Config负责应用的配置；Common是通用的工具类。

扩展设计

对于只有一个业务的简单场景，对扩展性的要求并不突出，这也是为何扩展设计常被忽略的缘由，由于咱们大部分的系统都是从单一业务开始的。可是随着业务场景愈来愈复杂，代码里面开始出现大量的if-else逻辑。此时除了常规的策略模式之外，咱们能够考虑在架构层面提供统一的扩展解决方案。

在扩展设计中，咱们提炼出两个重要的概念，一个是业务身份，另外一个是扩展点。

业务身份是指业务在系统惟一标识一个业务或者一个场景的标志。在具体实现中，咱们使用BizCode来表示业务身份，其中BizCode采用相似Java包名命名空间的方式。例如，咱们能够用“ali.tmall”表示阿里天猫业务，用“ali.tmall.car” 表示阿里天猫的汽车业务，而用"ali.tmall.car.aftermarket"表明这是阿里天猫的汽车业务的后市场场景。

每一个业务或者场景均可以实现一个或多个扩展点（ExtensionPoint），也就是说一个业务身份加上一个扩展点，能够惟一地肯定一个扩展实现（Extension）。而这个业务身份和扩展点的组合，咱们将其称之为扩展坐标（ExtensionCoordinate），以下图所示。

这样，经过业务身份+扩展点，咱们就能够从框架层面实现对不一样租户，不一样业务，不一样场景的扩展定制了。整个阿里业务中台正是基于这个思想，实现的多业务支撑的。

规范设计

任何事物都是规则性和随机性的组合。规范的意义就在于咱们能够将规则性的东西固化下来，尽可能减小为所欲为带来的复杂度，一致性能够下降系统复杂度。从命名到架构皆是如此，而架构自己就是一种规范和约束，破坏这个约束，也就破坏了架构。

COLA制定了一些列的规范：包括组件（Module）结构、包（Package）结构、命名等。

好比对于组件，咱们要求使用COLA的应用都应该遵循以下图所示的组件划分：

COLA架构总览

在架构思想上，COLA主张像六边形架构那样，使用端口-适配器去解耦技术细节；主张像洋葱圈架构那样，以领域为核心，并经过依赖倒置反转领域层的依赖方向。最终造成以下图所示的组件关系。

换一个视角，从COLA应用处理响应一个请求的过程来看。COLA使用了CQRS来分离命令和查询的职责，使用扩展点和元数据来提高应用的扩展性。整个处理流程以下图所示：

应用架构的核心

纵观上面介绍的全部应用架构，咱们能够发现一个共同点，就是“核心业务逻辑和技术细节分离”。

是的，六边形架构、洋葱圈架构、以及COLA架构的核心职责就是要作核心业务逻辑和技术细节的分离和解耦。

试想一下，业务逻辑和技术细节糅杂在一块儿的状况，全部的代码都写在ServiceImpl里面，前几行代码是作validation的事，接下来几行是作convert的事，而后是几行业务处理逻辑的代码，穿插着，咱们须要经过RPC或者DAO获取更多的数据，拿到数据后，又是几行convert的代码，在接上一段业务逻辑代码，而后还要落库，发消息.....等等。

再简单的业务，按照上面这种写代码的方式，都会变得复杂，难维护。

所以，我认为应用架构的核心使命就是要分离业务逻辑和技术细节。让核心业务逻辑能够反映领域模型和领域应用，能够复用，能够很容易被看懂。让技术细节在辅助实现业务功能的同时，能够被替换。

最后咱们发现，应用架构的道就是：“让上帝的归上帝，凯撒的归凯撒。”

原文连接 本文为云栖社区原创内容，未经容许不得转载。