共计 4676 个字符，预计需要花费 12 分钟才能阅读完成。
简介：“让上帝的归上帝，凯撒的归凯撒。”
作者 | 张建飞 阿里巴巴高级技术专家
架构
什么是架构？
对于架构这个概念很难给出一个明确的定义，也没有一个规范的定义。
硬是要给一个概述，我认为 架构就是对系统中的实体以及实体之间的关系所进行的形象形容。
架构始于修建，是因为人类倒退（原始人自力更生住在树上，也就不须要架构），分工协作的须要，将指标零碎按某个准则进行切分，切分的准则，是要便于不同的角色进行并行工作。
为什么须要架构？
有零碎的中央就须要架构，大到航空飞机，小到一个电商零碎外面的一个性能组件都须要设计和架构。
我很喜爱《零碎架构：简单零碎的产品设计与开发》外面的一句话：构造良好的发明流动要优于毫无构造的发明流动。
与之绝对应的，当初很多麻利思维提倡 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 的代码，在接上一段业务逻辑代码，而后还要落库，发消息 ….. 等等。
再简略的业务，依照下面这种写代码的形式，都会变得复杂，难保护。
因而，我认为利用架构的外围使命就是要拆散业务逻辑和技术细节。让外围业务逻辑能够反映畛域模型和畛域利用，能够复用，能够很容易被看懂。让技术细节在辅助实现业务性能的同时，能够被替换。
最初咱们发现，利用架构的道就是：“让上帝的归上帝，凯撒的归凯撒。”