微服务架构设计之六边形架构
以前接触的web开发都是三层架构，实习的这家公司采用的是六边形架构，此文将简单介绍一下微服务架构设计之六边形架构。
前言
六边形架构又称”端口适配器架构“，本质上也是一种分层架构，跟传统的MVC架构不同的是，从上下层转为了内外层。
内部代表了应用的业务逻辑，外部代表应用的驱动逻辑、基础设施或其他应用。
核心理念是应用通过端口与外部进行交互。核心的业务逻辑与外部资源完全隔离，仅通过适配器进行交互。
六边形架构
原理
左侧，应用程序端，输入适配器
这是用户或外部程序与应用程序交互的一面。它包含允许这些交互的代码。通常，您的用户界面代码，API的HTTP路由，以及使用您的应用程序的程序的JSON序列化都在这里。
内部，业务逻辑
这是我们想要从左侧和右侧隔离的部分。它包含所有关注和实现业务逻辑的代码。业务词汇和纯粹的业务逻辑，与解决应用程序的具体问题，使其丰富和具体的所有内容相关联，处于中心位置。
在这里，我们选择根据业务逻辑组织其模块（目录），理想状态下可以考虑采用领域驱动设计。
右侧，基础设施方面，输出适配器
取决于您的应用程序需要什么，它驱动的工作。它包含必要的基础结构详细信息，例如与数据库交互的代码，调用文件系统或处理对您所依赖的其他应用程序的HTTP调用的代码。
特性
外部可替换
一个端口对应多个适配器，是对一类外部系统的归纳，它体现了对外部的抽象。应用通过端口为外界提供服务，这些端口需要被良好的设计和测试。内部不关心外部如何使用端口，从一开始就要假定外部使用者是可替换的。六边形的六并没有实质意义，只是为了留足够的空间放置端口和适配器。适配器可以分为2类，“主”、“从”适配器，也可称为“驱动者”和“被驱动者”。自动测试
在六边形架构中，自动化测试和用户具有同等的地位，在实现用户界面的同时就需要考虑自动化测试。它们对应相同的端口。六边形架构不仅让自动化测试这件事情成为设计第一要素，同时自动化测试也保证应用逻辑不会泄露到用户界面，在技术上保证了层次的分界。依赖倒置
六边形架构必须遵循如下规则：内部相关的代码不能泄露到外部。所谓的泄露是指不能出现内部依赖外部的情况，只能外部依赖内部，这样才能保证外部是可以替换的。对于驱动者适配器，就是外部依赖内部的。但是对于被驱动者适配器，实际是内部依赖外部，这时需要使用依赖倒置，由驱动者适配器将被驱动者适配器注入到应用内部，这时端口的定义在应用内部，但是实现是由适配器实现。
实现细节
右侧的依赖倒置
- 定义实现所需的接口
- 逻辑层的成员变量直接引用抽象接口，依赖注入
- 逻辑服务使用抽象出来的方法
- 输出适配器具体实现抽象接口
如果不做依赖倒置，后续要把nsq替换成kafka的话，就需要将所有用到nsq的地方全部重写。
有了依赖倒置，新的中间件只需要实现定义好的接口即可。
六边形结构测试
在一般情况下，左侧代码的作用可以由测试框架直接扮演。实际上，测试代码可以直接驱动业务逻辑代码。
右边的代码必须由业务驱动。通常，如果要编写单元测试，可以使用模拟或任何其他形式的测试双重替换它，具体取决于要测试的内容。
项目结构
项目结构图参考
