解读六边形架构

追溯微服务架构的渊源，普通会触及到六边形架构。追溯六边形架构的来源，要看始作俑者Alistair Cockburn的这篇文章， 读原文，译重点，记感触， 如下：

六边形架构用意

驳回等同的形式，运行可以经过用户，程序，智能化测试或批处置脚原本驱动，而独立于最终的运转环境及数据库启动开发和测试。

当外部事情抵达端口的时刻，相应的适配器将其转化成适合的环节调用或许信息，而后传递给运行，而运行对输入设备无所不知。输入内容时，运行经过端口把要传递进来的信息传给适配器，适配器再针对信息接纳者的详细成功要求将其转化成适合的信号。从语义过去说，运行跟它周围的适配器有着良好的互动，而对适配器外部的一切无感知。

这是一种设计形式，被Cockburn定义为“端口和适配器形式“，设计形式不只指点了代码的成功，同时允许结构的成功，又是一种解耦合的技巧。

所需处置的疑问场景

不能处置疑问的架构，都只是架构师手中的玩具。六边形架构面对的一个典型疑问是业务逻辑与用户界面的代码交叉，这是开发中一个十分令人头痛的疑问，有三个恶果：

“***的那一层”产生了，可以在架构里参与一个新的层，并承诺不会有业务逻辑被放到着一新层里。但是随着期间的推移，会发现新的层里还是掺杂了业务逻辑，于是老疑问又产生了。

怎样办呢?假定一下，假设运行提供的每一特性能都有相应的API会是怎样的结果呢?QA可以经过智能化测试脚原本监测新改的代码，测验能否会破坏已有的性能。业务专家在GUI进去之前就可以创立智能化测试用例，作为程序员们检测能否正确成功上班的依据，同时，这也将成为测试部门所运转的测试的一局部。运行以"headless"形式部署，其它程序经过调用API的形式经常使用所提供的性能。这种形式使得复杂系统的设计变得容易，面向业务的运行之间不须要人工干预就可以相互调用。***，回归测试检测到产生疑问的中央，并加以修复，而保障业务逻辑不会进入表现层。

另一个典型的疑问是，假设运行绑定了外部数据库或其它服务，当数据库宕机或许正在迁徙的时刻，依赖数据库的程序就无法反常上班。这会造成照应提前，这是一种相当蹩脚的体验。

这两个疑问之间没有显著的咨询，但它们之间看起来是对称的。这又是一种面向接口的设计么?可以这样了解，由于接口的概念外延太大了，而在详细的编程言语成功中，interface 有往往太小了。这里把它明白为端口和适配器。

打算

不论用户端交互疑问还是服务端数据库编程疑问，其同源要素就是在设计和成功环节中产生的业务逻辑混杂，以及与外部实体之间的交相互关。咱们要关注的非对称性不是运行的"左边"和"左边"，而是它的"外部"和"外部"，该属于"外部"的代码就不要暴露到"外部"去，其基础通常还是那些基本的设计准则。

六边形架构的外围思念是：运行经过"端口"跟外部启动交互的。"端口"让人联想到操作系统的端口，任何合乎协定的设备都可以被插到相应的端口上。端口的协定是为了两个设备之间能够启动通讯而设计的，位于OSI7层协定模型中的传输层。

对运行来说，API就是协定。关于每一个外部设备，都有对应的适配器把API转换老本人所须要的信号，反之亦然。用户图形界面就是一个很好的例子，它是把用户操作映射到端口API的适配器，还有其它的例子如智能测试套件，批处置驱动器，以及任何须要跨运行程序交互的代码。

关于运行的数据处置层面，运行经过与外部实体交互失掉数据，这里用到的协定普通指数据库协定。从运行角度来看，把SQL数据库迁徙到普通的文件或许其它类型的数据库，API依然坚持不变。顺应于同一个端口的适配器还包括SQL适配器，文件适配器，以及更关键的数据库mock，它可以是驻存在内存里的数据库，不必定是实在的数据库。

很多运行都只要两个端口：用户端端口 和数据库端端口。这种状况看起来是对称的，很人造地就会用单维度多档次的架构来构建它。在开发运行程序时，就是咱们经常看到的三层、四层或五层架构。这种架构有两个疑问：

这就是六边形架构提出的要素，它着重处置对称性疑问，运行经过端口与外部启动交互，而外部的实体也可以用雷同的形式来处置。六边形架构强调以下两点：

首先，经过"内外"的不对称性以及端口的特点，解脱单维度多档次架构的约束。可以定义不同数量的端口，2个，3个或许4个，这里说的六边形不限于只要六个边，可以依据须要参与更多的端口和适配器，"六边形架构"只是视觉上的一种叫法。

其次，关注全体架构的结果导向，一个端口对应一个或一组有目的交互行为。但一个端口普通会有多个适配器，可以是无人应对机，语音留言机，按键电话，用户图形界面，测试套件，批处置驱动器，HTTP接口，程序之间的接口，mock的数据库，或许实在的数据库。

从运行层面来看，这一架构的目的是将留意力聚焦在内外非对称性上，让外部的实体从运行视角来看都是一样的。

结构

一个典型的六边形架构运行有两个端口，每个端口对应几个适配器，这两个端口区分用于运行控制和数据失掉。该运行可以被智能化测试，系统层面的回归测试，用户交互操作，远程HTTP调用或许另外一个本地运行驱动。在数据方面，经过性能经常使用外部的数据库，可以是Oracle数据库，mock的数据库，测试数据库或消费数据库，从而成功运行和外部数据库的解耦。运行的性能说明是依据六边形外部的接口来编写的，而不是依据外部或许用到的任何一种技术。

关于一个典型的三层架构而言，简化起见，每个端口只给出两个适配器。架构的顶层跟底层可以实用多个适配器，这些适配器是可以依照必定顺序来开发。带有数字的箭头展现了一个团队是如何依照必定顺序来开发和经常使用运行的：

代码示例

FIT的文档给出了一个繁难的例子来说明端口与适配器形式，它是一个计算折扣多少钱的运行：discount(amount) = amount *rate(amount);

在这个运行里，amount来自用户的输入，而rate来自数据库，所以须要两个端口。先用测试代码跟rate常量来测试，而后再经常使用GUI跟mock数据库，来自IHC的GyanSharma提供这个示例的代码，详细参考原文。

另一个用Ruby和Rack成功的例子可以看这里。

六边形架构中的左右非对称性

六边形架构强调端口之间的相似性。在成功的时刻普通有两种格调，称之为"主"和"从"，或许叫驱动者跟被驱动者，实践上是CS结构的又一表现。

在上方的例子中，FIT被用在左边的端口上，而mock的物品在左边。在三层架构中，FIT在最顶层，mock在***层。这两者之间的区别在于是谁触发了会话，或许谁在会话中起主导作用。FIT就是"主"，这个框架就是被设计用来经过脚原本驱动运行的。Mock数据库就是"从"，数据库被设计用来照应来自运行的查问或记载变卦事情的。

依据系统用例，把"主"的端口和适配器放在了六边形的左边，而"从"的端口和适配器放在了六边形的左边。它们之间的相关以及它们的成功形式是很有用的，但前提是要用在六边形架构中。端口与适配器形式***的好处就是可以让运行可以齐全独立地运转。

六边形架构的运行边界

六边形架构对用例编写也有强化作用。开发者在编写用例时常犯的失误是把端口外边的技术细节蕴含在用例里，这样的用例易读性差，有趣，软弱，难于保养。经常使用六边形架构后，编写用例应该以运行的边界为准。用例要明白运行能够允许的性能和事情，而不用关心外部的技术是怎样样的。

如何经常使用端口取决于团体阅历。一种极其的状况，每个用例都被赋予一个端口，这样运行里就会有成千盈百的端口。另一种状况是，把左右两头的端口区分兼并起来，这样就只剩两个端口了。这两种状况都不是最理想的。一些大家所熟知的运行是这样的：

这些实例没有拘泥于端口的数量，一切都是为了业务系统服务的。普通偏差于选用更少的端口，实践上是另一种对分层模型的界定。

原文中谈到的一个实在运行是这样的，报警系统从国度天气服务中心失掉地震，龙卷风，火灾和洪水的预警，而后经过电话或语音留言通知人们。假设遵照技术与业务指标相关联的准则，可以设计成一个接口用于接纳来自预告源的数据，一个用来向言语留言机发送通知，一个GUI治理界面，以及一个失掉订阅者数据的数据库接口。当宿愿向系统里参与一些接口的时刻，比如一个来自天气服务中心的http接口，或许一个到订阅者的邮件接口，还要思考怎样让运行套件满足客户定制化需求。这样就会会堕入保养和测试的恶梦，由于要为不同的定制需求开发不同的版本。

经过系统接口设计的调整，新的六边形架构面向的是业务指标，而不是详细的技术，而且把一切的详细技术换成了适配器。这样，很快就把http和邮件接口参与到了系统中，把运行部署成"headless"形式，并参与了一个适配器，可以按需经过API调用衔接到其余运行上。***，由于运行的独立运转才干和各种适配器的存在，就可以经常使用独自的智能化脚本启动回归测试了。

一句话体会

六边形架构的初衷是为了处置技术与业务系统的解耦合疑问，以及技术与技术间的解耦合疑问，这一架构从设计形式中来，从业务的实体服务登程，将面向接口的设计详细化的端口协定和适配器成功，将业务虚体成功自服务的完备性，可以看作是微服务的一个通常基础吧。

【本文来自专栏作者老曹的原创文章，作者微信群众号：喔家ArchiSelf,id:wrieless-com】

戳这里，看该作者更多好文