CN109271143B - 基于云服务的微服务架构 - Google Patents

Abstract

本申请涉及云服务领域，揭示了一种基于云服务的微服务架构，包括：资源层，用于对外提供资源；应用服务层，用于事物排版；领域模型层，用于领域服务，设置有聚合以及仓库；端口层，用于对接外部；其中，所述资源层接收外部命令，根据外部命令调用所述应用服务层；应用服务层根据所述外部命令进行对应的业务排版，然后将外部命令发送给所述领域模型层进行对应的业务处理，并将处理结果反馈给所述应用服务层，然后由应用服务层发送给所述端口层，由端口层将所述处理结果进行相应的处理。本申请的基于云服务的微服务架构，结构简单，领域模型层中设置有聚合，加强了领域和聚合的概念，使得业务划分更加清晰，达到高内聚低耦合的目的。

Description

基于云服务的微服务架构

技术领域

本申请涉及到云服务领域，特别是涉及到一种基于云服务的微服务架构。

背景技术

基于云服务的微服务架构是一项在云中部署应用和服务的新技术。

微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行，通过这一点就可以将服务公开与基于云服务的微服务架构(在现有系统中分布一个API)区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在基于云服务的微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。

现有很多系统都进行了微服务的落地，在整体框架上都进行了微服务化，但是在设计思想上还没有明确的标准，架构相对复杂。

发明内容

本申请的主要目的为提供一种结构简单的基于云服务的微服务架构。

为了实现上述发明目的，本申请提出一种基于云服务的微服务架构，包括：

资源层，用于对外提供资源；

应用服务层，用于事物排版；

领域模型层，用于领域服务，设置有聚合以及仓库；

端口层，用于对接外部；

其中，所述资源层接收外部命令，根据外部命令调用所述应用服务层；所述应用服务层根据所述外部命令进行对应的业务排版，然后将所述外部命令发送给所述领域模型层进行对应的业务处理，并将处理结果反馈给所述应用服务层，然后由所述应用服务层发送给所述端口层，由所述端口层将所述处理结果进行相应的处理。

进一步地，所述基于云服务的微服务架构还包括：

上下文映射层，用于微服务之间的数据交互。

进一步地，所述基于云服务的微服务架构还包括：

防腐层，用于将微服务之间的交互数据进行过滤，并将过滤后的数据发送给资源层。

进一步地，所述领域模型层内设置有至少一个聚合，当所述应用服务层调用领用模型层的某一个聚合时，通过调用所述聚合的聚合根完成。

进一步地，所述聚合的内容通过仓库获取。

进一步地，所述应用服务层中设置CQRS命令查询模型，用于将所述应用服务层的查询端和命令端分开，且所述查询端用于只读功能。

进一步地，所述基于云服务的微服务架构还包括：

用户界面层，用于负责向用户显示信息和解释用户命令。

进一步地，所述基于云服务的微服务架构还包括：

基础实施层，用于向所述资源层、所述应用服务层、所述领域模型层和所述端口层提供通用的技术能力。

进一步地，所述基于云服务的微服务架构还包括：

事件发布层，用于发布供其它微服务使用的事件。

进一步地，所述领域模型层中的各领域之间通过事件和rest进行交互。

本申请的基于云服务的微服务架构，其代码结构只需要上述的资源层、应用服务层、领域模型层和端口层，结构简单，其中，领域模型层中设置有聚合，加强了领域和聚合的概念，使得业务划分更加清晰，达到高内聚低耦合的目的。

附图说明

图1为本申请一实施例的基于云服务的微服务架构的结构示意框图；

图2为本申请一实施例的基于云服务的微服务架构的结构示意框图。

本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

参照图1，本申请提供一种基于云服务的微服务架构，包括：

资源层10，用于对外提供资源；

应用服务层20，用于事物排版；

领域模型层30，用于领域服务，设置有聚合以及仓库；

端口层40，用于对接外部；

其中，所述资源层接收外部命令，根据外部命令调用所述应用服务层；所述应用服务层根据所述外部命令进行对应的业务排版，然后将所述外部命令发送给所述领域模型层进行对应的业务处理，并将处理结果反馈给所述应用服务层，然后由所述应用服务层发送给所述端口层，由端口层将所述处理结果进行相应的处理。

在本实施例中，上述资源层10包括所有对外提供的资源，包括所有的API(Application Programming Interface,应用程序编程接口)。上述应用服务层20，其没有任何的业务逻辑代码，它很简单，主要为程序提供任务处理，即，主要是事务排版，不涉及具体业务，用于多进程管理及调度，多线程管理及调度，多协程调度和状态机管理等。上述领域模型层30，包括了领域服务，其设置聚合以及仓库，这一层包含有关领域的信息，是业务的核心，领域模型的状态都直接或间接(持久化至仓库)存储在这一层，领域模型的实现，包括领域对象的确立，这些对象的生命周期管理及关系，领域服务的定义，领域事件的发布等。通常，领域模型通过对象模型来实现，这些对象同时包含了数据和行为，并且表达了准确的业务含义。端口层40，包括对接外部服务的接口、翻译层和仓库持久化实现等。上述资源层10、应用服务层20、领域模型层30和端口层40之间为松耦合结构，因此只要消息符合协商的架构，则各层的修改实现就可以根据需要进行更改，而不必担心会对其它层产生破坏。

参照图2，在一个实施例中，上述基于云服务的微服务架构还包括：

上下文映射层50，用于微服务之间的数据交互。

本申请中，各位服务团队会先建立通用语言UL(Ubiquitous Languag)和模式BC(Bounded Context，限界上下文)。UL是团队共享的语言。不管团队中的角色如何，只要是团队的一员，都将使用UL。由于UL的重要性，所以需要让每个概念在各自的上下文中是清晰无歧义的。而BC中的每个概念都有唯一的含义。一个业务领域划分成若干个BC，它们之间通过上下文映射层(Context Map)进行集成。BC是一个显式的边界，领域模型层便存在于这个边界之内，软件模型层中包含有多个领域模型，领域模型是关于某个特定业务领域的软件模型。

在一个实施例中，上述基于云服务的微服务架构还包括：

防腐层60，用于将微服务之间的交互数据进行过滤，并将过滤后的数据发送给上述资源层10。

本申请中，微服务在通过上下文映射层50集成的过程中，可以通过防腐层60进行交互数据的过滤，将与对应微服务不相关的数据过滤掉。比如，上述上下文映射层50中接收了多个微服务任务，防腐层50会将与其所在的微服务相关的任务放行，而其它的则会过滤掉。

在一个实施例中，上述领域模型层30内设置有至少一个聚合，当所述应用服务层20调用领用模型层的某一个聚合时，通过调用所述聚合的聚合根完成。

聚合，它定义了模型的关系和边界。每个聚合都有一个根，根是一个实体，并且是唯一可被外界访问的。正是如此，聚合可以保证多个模型单元的不变性，因为其它模型都参考聚合的根。所以要想改变其他对象，只能通过聚合的根去操作。聚合根如果没有了，那么聚合中的其他对象也将不存在。上述实体与面向对象中的概念类似，在这里它是领域模型的基本元素。在领域模型中，实体应该具有唯一的标识符，从设计的一开始就应该考虑实体，决定是否建立一个实体也是十分重要的。值对象，它仅仅是没有唯一标识符的实体，比如有两个收货地址的信息完全一样，那它就是值对象，并不是实体。值对象在领域模型中是可以被共享的，是“不可变的”(只读的)，当有其它地方需要用到值对象时，可以将它的副本作为参数传递。上述聚合的内容通过仓库获取，而仓库封装了获取对象的逻辑，领域对象无须和底层数据库交互，它只需要从仓库中获取对象即可。仓库可以存储对象的引用，当一个对象被创建后，它可能会被存储到仓库中，那么下次就可以从仓库取。如果用户请求的数据没在仓库中，则会从数据库里取，这就减少了底层交互的次数。

在一个实施例中，上述应用服务层中设置CQRS命令查询模型，用于将所述应用服务层的查询端和命令端分开，且所述查询端用于只读功能。

上述CQRS本身只是一个读写分离的思想，全称是：Command QueryResponsibility Segregation，即命令查询职责分离。一个命令表示一种意图，表示命令系统做什么修改，命令的执行结果通常不需要返回；一个查询表示向系统查询数据并返回。CQRS架构的核心出发点是将整个系统的架构分割为读和写两部分，从而方便对读写两端进行分开优化；采用CQRS命令查询模型的一个前提是，你的系统要接受系统使用者查询到的数据可能不是最新的，而是有几个毫秒的延迟。之所以会有这个前提，是因为CQRS架构考虑到，作为一个多用户同时访问的互联网应用，当在高并发修改数据的情况下，比如秒杀、12306购票等场景，用户UI上看到的数据总是旧的。比如你秒杀时提交订单前看到库存还大于0，但是当你提交订单时，系统提示你宝贝卖完了。这个就说明，在这种高并发修改同一资源的情况下，任何人看到的数据总是Stale的，即旧的。

在一个实施例中，上述基于云服务的微服务架构还包括：

用户界面层70，用于负责向用户显示信息和解释用户命令。上述的用户可以是另一个计算机系统，不一定是使用用户界面的人；

基础实施层80，用于向所述资源层、应用服务层、领域模型层和端口层提供通用的技术能力。比如，基础实施层为应用服务层传递消息，为领域模型层提供持久化机制等，为用户界面层绘制屏幕组件，等等。基础设施层80还能够通过架构框架来支持本申请中其它各层之间的交互模式；

事件发布层90，用于发布供其它微服务使用的事件。

在一个具体实施例中，上述领域模型层中的各领域之间通过事件和rest进行交互。使各领域之间处于低耦合状态。

本申请实时的基于云服务的微服务架构，通过上下文定义和通用语言的建立，能加强团队内的协作；加强领域和聚合的概念，建模的思想，使得业务划分更加清晰，达到高内聚低耦合的目的。

上所述仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (8)

1.一种基于云服务的微服务架构，其特征在于，包括：

资源层，用于对外提供资源；

应用服务层，用于事物排版；

领域模型层，用于领域服务，设置有聚合以及仓库；

端口层，用于对接外部；

其中，所述资源层接收外部命令，根据外部命令调用所述应用服务层；所述应用服务层根据所述外部命令进行对应的业务排版，然后将所述外部命令发送给所述领域模型层进行对应的业务处理，并将处理结果反馈给所述应用服务层，然后由所述应用服务层发送给所述端口层，由所述端口层将所述处理结果进行相应的处理；

上下文映射层，用于微服务之间的数据交互；其中，各位服务团队会先建立通用语言UL和模式BC；一个业务领域划分成若干个BC，它们之间通过上下文映射层进行集成；BC表示限界上下文；

防腐层，用于将微服务之间的交互数据进行过滤，将与对应微服务不相关的数据过滤掉，并将过滤后的数据发送给所述资源层；其中，若上下文映射层中接收了多个微服务任务，防腐层会将与其所在的微服务相关的任务放行，而其它的则会过滤掉。

2.根据权利要求1所述的基于云服务的微服务架构，其特征在于，所述领域模型层内设置有至少一个聚合，当所述应用服务层调用所述领用模型层的某一个聚合时，通过调用所述聚合的聚合根完成。

3.根据权利要求2所述的基于云服务的微服务架构，其特征在于，所述聚合的内容通过仓库获取。

4.根据权利要求1所述的基于云服务的微服务架构，其特征在于，所述应用服务层中设置CQRS命令查询模型，用于将所述应用服务层的查询端和命令端分开，且所述查询端用于只读功能。

5.根据权利要求1-4中任一项所述的基于云服务的微服务架构，其特征在于，还包括：

用户界面层，用于负责向用户显示信息和解释用户命令。

6.根据权利要求1-4中任一项所述的基于云服务的微服务架构，其特征在于，还包括：

基础实施层，用于向所述资源层、所述应用服务层、所述领域模型层和所述端口层提供通用的技术能力。

7.根据权利要求1-4中任一项所述的基于云服务的微服务架构，其特征在于，还包括：

事件发布层，用于发布供其它微服务使用的事件。

8.根据权利要求1-4中任一项所述的基于云服务的微服务架构，其特征在于，所述领域模型层中的各领域之间通过事件和rest进行交互。