微服务拆分

目录

前言：

逻辑视图架构风格

一、分层式架构风格

二、六边形架构

如何定义微服务架构

微服务的拆分

业务能力进行服务拆分

子域进行服务拆分

拆分的原则

单一职责

闭包原则

---

前言：

我们在软件开发的时候一直在谈论架构，那么什么是架构呢？计算机系统的软件架构是构建这个系统所需要的一组结构，包括软件元素、它们之间的关系以及两者的属性，简单来说就是元素和元素之间的关系。它的目标是可扩展性、可靠性、安全性、可维护性、可测试性以及可部署性并且可以快速的交付，为了实现上述目标，分解就特别的重要。接下来将详细阐述微服务的拆分。

说到软件架构不得不提到软件架构的4+1视图模型：

每个视图有以下的目的：

逻辑视图：开发人员创建的软件元素。在面向对象的语言中，这些元素是类和包。它们之间的关系是类和包之间的关系，包括继承、关联和依赖

实现视图：构建编译系统的输出。此视图由表示打包代码的模块和组件组成，组件是由一个或多个模块组成的可执行或可部署单元。

进程视图：运行时的组件。每个元素都是一个进程，进程之问的关系代表进程问通信。

部署视图：进程如何映射到机器。此视图中的元素由（物理或虚拟）计算机和进程组成。机器之间的关系代表网络。该视图还描述了进程和机器之间的关系。

除了这四个视图以外，4+1 中的+1是这场景，它负责把视图串联起来。是从不同维度去考虑的，每个场景负责描述在一个视图中的多个架构元素如何协作，以完成一个请求。

逻辑视图有两种经典的架构风格

逻辑视图架构风格

一、分层式架构风格

分层架构将软件元素按“层”的方式组织。每个层都有明确的职责。分层架构还限制了层之间的依赖关系。分层架构应用于前面讨论的四个视图中的任何一个。今天我们提到的三层架构是应用于逻辑视图的分层架构。它将应用程序的类组织到以下层中。

表现层：包括实现用户界面或外部API的代码 业务逻辑层：包含业务逻辑 数据持久化层：实现和数据库交互的逻辑

这种架构模式也就是我们常说的MVC，V就是表现层，C就是业务逻辑层，M就是model 层，这种架构有什么缺点呢？

我们先从表现层来说，它无法实现多个系统调用的事实。单一数据持久化层，无法展现应用程序与多个数据库进行交互的事实同时由于C依赖于M，将妨碍你在没有数据库的情况下测试业务逻辑。

二、六边形架构

六边形架构风格选择以业务逻辑为中心的方式组织逻辑视图。应用程序具有一个或多个人站适配器，而不是表示层，它通过调用业务逻辑来处理来自外部的请求。同样，应用程序具有一个或多个出站适配器，而不是数据持久化层，这些出站适配器由业务逻辑调用并调用外部应用程序。此架构的一个关键特性和优点是业务逻辑不依赖适配器，相反适配器依赖于业务逻辑。

对于业务逻辑来说它有两种端口：入站和出站端口。入站端口是业务逻辑公开的API，它使外部应用程序可以调用它。主要是入站适配器调用它完成一次请求，出站端口的一个实例是存储库接口，调用出站适配器比如说DAO