微服务的应用架构

架构描述的是在更高层次将应用拆分为子系统或模块的方法,以及这些子系统之间的交互关系。在一个基于微服务架构构建的应用中,每个服务都需要有自己的架构。

事实上,单体应用在复杂度较低时,它的生产效率是要高于微服务的。只有在复杂度逐渐增加,它的劣势才慢慢显现并导致生产效率下降。因此在评价单体应用和微服务架构的好坏时,我们要辩证地评价。

我们做的应用都是要满足用户的需求的。在业界喜欢用MVP最小可用产品来验证用户的需求。这一阶段成本和交付时间是最主要的考量因素。以便获得用户的反馈来迭代开发产品。在这种背景下,无疑单体应用是最合适的,单体应用开发简单,只需要构建一个单独的应用程序,其次,测试也不麻烦,只需要测试端到端的场景和调用接口的测试;部署也简单,只需要将应用整体打包好上传到服务器即可,没有过多的依赖。我们在做单体应用时,也可以通过模块化设计来保持部分逻辑的重用。在单体应用内部设计好相应的模块,包括对外的接口、数据存储。方便日后向其他架构模式迁移。

当系统壮大后,各方面的复杂度都在增加,就是时候对单体应用的体系进行拆解,典型的手法就是分层。这种分层遵循上层使用下层的定义的服务,下层对上层隐藏自己的实现细节。分层在一定程序提供了解耦的能力,层与层之间的依赖程度有效地降低了。分层的数量要适合,过多反而会影响性能,因为数据在每一层传递时都会被封装成对应的格式。有时上层修改时,会引起级联修改。

典型的两层结构:客户端/服务端。对于简单的应用来说两层没有太大的问题,如果业务变得复杂了,将业务写到哪一层都不太合适。

那么引入一个中间层,我们将它称为领域层或业务逻辑层,把复杂的业务逻辑写在这一层。三层的结构就变成了展示层,业务逻辑层、数据访问层。展示层就是我们的前端,业务逻辑层和数据访问层就是我们的后端。 或许大家已经听过前后端分离,因此三层还可以是这样的:接口层、业务逻辑层、数据访问层。这三层都是后端的,前端就通过接口层与后端交互。

在微服务架构中也可以采用分层结构,但是六边形架构在微服务架构中更加流行。六边形架构也叫端口适配器架构。它以业务逻辑为中心来组织代码。如下图这个例子:
微服务的应用架构_第1张图片
六边形中间是具体的业务逻辑,如业务规则、领域对象、领域事件。在六边形的边界上有进出的端口,通常以某种协议的API形式出现,与之对应的是外部的适配器,它们将完成外部系统的调用,并通过端口与应用交互。适配器有入站和出站适配器两种,入站适配器通过调用入站端口处理来自外界的请求,出站适配器通过调用外部系统或服务处理来自业务逻辑的请求。

六边形架构分离了系统层与业务层的具体实现:
1、系统层:应用的外层边界,负责与外部系统的交互,以及非业务属性的实现。
2、业务层:也称为领域层,应用的内层边界,负责核心业务逻辑的实现。

六边形架构的目标是创建松散耦合的应用,通过端口和适配器连接需要的软件环境和基础设施。这样我们就可以看到业务逻辑不依赖于适配器。这样的代码组织就可以在代码层面获得很好的分离,让领域边界更加清晰。六边形架构的扩展性也非常好,例如我们要引入一种新的通信协议,或一种新型的数据库,那么我们只需要实现对应的适配器就可以完成引入。

你可能感兴趣的:(微服务,架构,微服务,云原生)