摘 要

由于传统的Web项目随着项目功能的增加，项目的规模会越来越大，从而导致项目内部的功能模块会越来越多，就会使得项目越来越复杂，最终导致添加、修改功能复杂性高，软件更新、升级困难。而当下社会项目需求变化迅速，项目功能更改频繁，因此传统的单体Web项目显然不能满足当下社会的要求。

为了改善这种状况，本文采用了一种新的方案来进行Web项目的开发，该方案主要由容器技术和微服务架构组成。旨在开发可扩展性强，易于修改和维护的Web项目来满足当下社会的需求。

本文选定了一个仓储物流系统作为研究对象，将其做成了一个微服务架构的Web项目。构建此Web项目的过程如下：

1. 对要做的系统进行需求分析，数据库设计，得出系统的功能需求和数据库表格。
2. 以微服务架构的方法对得到的功能需求和数据库表格进行系统的设计，得出整个

系统的大体架构。

1. 将系统架构与Spring Cloud结合生成具体的Web项目。
2. 将Web项目部署到Docker上。

本文的Web项目最终在Docker容器上运行，完成了系统所需的所有功能，实现了微服务中的服务治理，客服端负载均衡，服务容错保护，API网关服务。整个Web项目能够达到预期的可扩展性强，易于修改和维护的特点。

关键词：微服务；Docker；消息队列；Spring Cloud

Abstract

With the increase of project functions, the traditional Web projects will become larger and larger，leading to more and more functional modules in the project, which will make the project more and more complex, and eventually the complexity of adding and modifying functions is high, and software updates and upgrades are difficult.Nowadays, the demand for social projects has changed rapidly and the functions of the projects have changed frequently. Therefore, the traditional Monolithic Architecture Web project obviously cannot meet the requirements of the current society.

In order to improve this situation, this article adopts a new program to develop the Web project, which mainly consists of container technology and microservice architecture. It aims to develop web projects that are highly scalable, easy to modify and maintain to meet the needs of the current society.

This article selected a warehousing logistics system as a research object, and made it a Web project of a microservice architecture. The process of building this web project is as follows:

1. Demand analysis of the system to be done, database design, functional requirements of

the system and database tables.

1. The functional requirements and database tables obtained through the microservice

architecture approach are systematically designed and the overall architecture of the entire system is obtained.

1. Combine the system architecture with Spring Cloud to generate specific Web projects.
2. Deploy the Web project to Docker.

The Web project of this article finally runs on the Docker container, completes all the functions required by the system, realizes service management, load balancing at the customer service side, service fault tolerance protection, and API gateway service in the microservice architecture. The entire Web project can achieve the expected scalability, ease of modification and maintenance.

Key Words： microservice；Docker；message queue；Spring Cloud

目 录

摘 要 I

Abstract II

第1章 绪论 1

1.1 研究背景及意义 1

1.2 国内外研究现状 2

1.3 本文主要研究内容 3

1.4 本文的组织结构 3

第2章 微服务的设计 4

2.1确定项目 4

2.1.1 项目名称 4

2.1.2 项目需求分析 4

2.2项目的微服务化 5

2.2.1 项目的微服务分解 5

2.2.2 项目的微服务集成 7

第3章 微服务实现 8

3.1选定技术 8

3.1.1技术选型 8

3.1.2技术简介 8

3.2微服务架构的实现 9

3.2.1 微服务的数据库设计 9

3.2.2 微服务组件的构建 10

3.2.3 微服务组件的组合 11

3.2.4 微服务之间的通信 14

第4章 微服务的部署 17

4.1 Docker简介 17

4.2 Docker基本知识 17

4.2.1 Docker组件 17

4.2.2 Docker容器 17

4.2.2 Docker镜像 17

4.2.2 Docker Networking 18

4.3将微服务部署到Docker上 18

4.4测试项目的功能 20

第5章 结论 22

5.1主要工作总结 22

5.2展望 22

参考文献 23

致 谢 24

第1章 绪论

1.1 研究背景及意义

就当下而言，当需要开发一个Web项目时。按照传统的方式，开发的流程是先对项目进行需求分析，然后设计编码，编码完成后进行测试，测试合格后打成一个归档包，最终将归档包部署在服务器上发布运行。这种方式看起来合情合理，使用起来也没有显而易见的问题。但是他的整个项目中只有一个归档包。一个归档包（例如war格式）包含所有功能的应用程序，通常称为单体应用^[1]。而架构单体应用的方法论，就是单体应用架构^[1]。单体架构在项目初期是一种比较好的架构。因为在项目初期，项目的规模小，项目内的代码数量少，使用单体架构可以很容易的进行部署与测试。但是，随着时间的流逝，项目的功能需求可能会越来越多，慢慢地、项目中的代码也会越来越多，项目也就变得越来越复杂。单体应用的发展趋势如图1.1所示。

图1.1 单体架构应用演化过程

当单体架构演化到很复杂时，如图1.1最后一个阶段，他会包含很多代码和数据。当需要修改项目中的某个功能或者新增项目功能时，要考虑是否与已有的功能冲突，鉴于单体架构代码量的巨大，这将是一个巨大的挑战。在项目功能修改或新增完毕之后，要想使用新的功能，还需要将整个项目重新部署发布。由上可见，单体架构的项目在修改和维护方面可能会付出巨大的代价。而且如果有开发人员的更迭，新来的开发人员需要花费大量的时间来学习项目已有的上下文才能进行开发。这就造成了一种很严重浪费。

为了避免上述情况的发生，微服务架构应运而生。微服务架构的思想是纵向划分架构，将业务划分为不同的服务，每个服务是一个独立的实体。每个服务可以独立地部署在PAAS(Platform As A Service,平台即服务)上^[2]。各个服务之间通过AMQP(Advanced Message Queuing Protocol，高级消息队列协议)或者Restful API进行通信^[3]，从而保证了单个业务应用程序的规模不会过大,也就保证了系统的复杂性。

1.2 国内外研究现状

近年来，国内外的软件开发组织都在不断地向着敏捷开发、DevOps^[3](英文Development和Operations的组合)迈进。敏捷开发：以用户的需求为核心，采用迭代、循序渐进的方法进行软件开发；DevOps：开发与运营的结合，用于软件的快速交付。

通过对敏捷开发和DevOps的简单了解，可以知道目前国内外Web项目的研究方向主要是向着快速将用户的需求转化为产品的方向发展，这样做可以快速适应市场环境的变化，从而使开发者变得更加富有竞争力，进而赢得更多的用户。因此开发Web项目时，快速与变化成了当下最值得考虑因素。要使Web项目具有以上特点，首先项目不能过大，其次项目的部署发布必须要快捷简单。然而随着开发时间的增长，传统的Monolithic Architecture^[4]（单体架构）会变得越来越大，越来越难以维护和部署，也就和快速变化渐行渐远。所以国内外许多公司都开始放弃Monolithic Architecture,转向Microservice Architecture^[4]（微服务架构）。

比如亚马逊，阿里巴巴，eBay和Netflix等许多组织通过采用现在称为Microservice Architecture模式的方式解决了Monolithic Architecture会随着时间的推移越来越大的问题。这个想法不是构建一个单一的庞大的应用程序，而是将应用程序拆分为一组较小的互连服务。

克里斯理查森发表过观点：微服务通常实现一组不同的特征或功能，例如订单管理，客户管理等^[4]。每个微服务都是一个小型应用程序，它具有自己的六边形架构，由业务逻辑和各种适配器组成。一些微服务会暴露其他微服务或应用程序客户端使用的API。其他微服务可能会实现一个Web UI。在运行时，每个实例通常是云VM或Docker容器。

在设计微服务方面，埃里克埃文斯在《领域驱动设计》一书中引入了一个很重要的概念是bounded context（限界上下文）^[2]。在任何一个给定的领域中都包含多个限界上下文，每个限界上下文的内容分为两部分，一部分需要与外部通信，另一部分不需要。每个上下文都有明确的接口，该接口决定了它会暴露哪些模型给其他上下文。

对于Docker，Docker是一种容器技术^[5]。容器与管理程序虚拟化有所不同，管理程序虚拟化通过中间层将一台或多台独立的机器虚拟运行于物理硬件之上，而容器则是直接运行在操作系统内核之上的用户空间。因此容器技术可以理解为“操作系统级虚拟化”。

1.3 本文主要研究内容

本文的主要研究内容为以下三个方面：

1. 微服务设计：通过在业务功能，技术边界，限界上下文方面的分析与研究将本论

文的仓储物流系统划分为一系列松耦合，高内聚，粒度适中的微服务。

1. 微服务的集成：将划分得到的一系列微服务进行集成，最终得到一个Web项目。

在微服务集成时需要考虑避免破坏性修改、保证API的技术无关性、服务易于消费方使用、隐藏内部实现细节。避免破坏性修改可以保证服务提供者在微调时（比如在响应中增加一个字段）服务消费者不用更改；保证API的技术无关性使得项目的技术栈不受限；服务易于消费方使用使项目的可移植性好；隐藏内部细节可以进一步的降低耦合。

1. 微服务的Docker部署：将通过微服务集成得到的Web项目部署到Docker上。部

署的过程中主要研究容器的使用，镜像的使用和服务的编排。

1.4 本文的组织结构

本文共分为五章，具体内容如下：

第一章：绪论。主要介绍本文的研究背景与意义，国内研究现状和本文的主要研究内容以及本文的组织结构。

第二章：微服务设计。主要介绍本文待开发项目名称的确定、项目的需求分析、项目的微服务化。

第三章：微服务实现。主要介绍编写项目中用到的具体技术、微服务的具体实现等。

第四章：微服务部署。主要介绍Docker容器技术以及如何将编写好的微服务部署到Docker上。

第五章：结论。对最终的项目进行一个总结和对未来的展望。

第2章 微服务的设计

2.1确定项目

2.1.1 项目名称

本论文的项目名称是仓储物流系统。

2.1.2 项目需求分析

本系统主要做的是仓储物品的管理和物流单的管理，以及物品下单时仓储物品与物流单的交互（物品下单后，仓储物品对应物品数量减少，物流单中多一条物流单信息）。所以本系统的用例图如图2.1所示：

图2.1 整个系统的用例图

通过对用例图用例的分析，可以发现整个系统的领域对象有两个，一个是仓储物品，另一个是物流单。领域对象的属性，仓储物品的属性主要有物品id，物品名称，库存量，条形码，入库时间，修改时间等。物流单的属性主要有物流单编号，物品id，物品名称，物品数量，快递公司，快递公司单号，物流单物品重量，物流目的地，物流单创建时间、物流单修改时间等。仓储物品与物流单之间的关联为1个仓储物品对应0个或者多个物流单。所以本系统的类图如图2.2所示：

图2.2 本系统的领域类图

2.2项目的微服务化

2.2.1 项目的微服务分解

根据图2.1，可以知道本文要做的Web项目要实现的功能。那么接下来按照以下几点将其分解成为微服务。

1. 业务功能。本文的Web项目涉及九个业务功能，这九个业务功能为增加仓储物品、

查找仓储物品、修改仓储物品、删除仓储物品、增加物流单、修改物流单、删除物流单、查找物流单、仓储物品下单。初步可以将这九个业务功能按涉及的领域对象数量分为三类，第一类(只涉及仓储物品)：增加仓储物品、删除仓储物品、修改仓储物品、查找仓储物品；第二类(只涉及物流单)：增加物流单、删除物流单、修改物流单、查找物流单；第三类(同时涉及仓储物品和物流单)：仓储物品下单。同样，可以根据涉及领域对象数量先对本文的Web项目进行初步的微服务分解，先将涉及单个领域对象的功能构建成一个微服务，这样可以先涉及两个微服务。一个仓储物品微服务满足第一类功能需求，一个物流单微服务满足第二类需求。这时还有一个第三类的功能需求，因为它涉及两个领域对象，所以暂时不处理它。

1. 限界上下文。在任何一个给定的领域中包含多个限界上下文。每个限界上下文中

的内容分成两部分，一部分不需要与外部通信，另一部分需要。通过限界上下文的定义，结合第一步得出两个微服务，可以将第一步得到的两个微服务看做两个限界上下文。而这两个限界上下文只包含了不需要与外部通信的部分。现在考虑功能分类中的第三类：仓储物品下单这一功能需求。仓储物品下单的整个流程是仓储物品数量减少，生成新的物流单。从流程中可以看到仓储物品下单与两个微服务之间都有联系，结合限界上下文的定义，可以用外部接口的形式来实现仓储物品下单功能。在仓储物品微服务中添加一个外部接口，同时在物流单微服务中也添加一个外部接口。当使用仓储物品下单功能时，仓储物品微服务执行相应业务逻辑，然后通过仓储物品微服务外部接口向物流单微服务发送信息，物流单微服务通过物流单微服务接口接受信息并执行相应业务逻辑。

1. 从耦合度方面。仓储物品微服务直接与物流单微服务进行通信会造成服务之间耦

合度过高。就会导致只要物流单微服务停掉了，那么物品下单功能就用不了。但实际上这两个微服务是可以异步通信的，在物流单微服务不可用的情况下，物品下单功能还是可以使用的。为了达到这种效果，需要引入一个消息队列微服务，使以上的两个微服务通过消息队列进行通信。

通过以上三步可以知道本文要做的Web项目核心可以分解为三个微服务，一个仓储管理微服务，一个物流单管理微服务，一个消息队列微服务。分解后整个项目的架构如图2.3所示。

图2.3 微服务的初步分解模型

2.2.2 项目的微服务集成

通过微服务分解，对要做的项目的核心微服务进行了确定，但是核心微服务只是核心，它并不能带代表本文要做的微服务系统。因为它还缺少一些必要的组件，现在把它们组合起来。第一个要组合的是服务注册中心，服务注册中心用于发现与注册服务，以此确定系统的边界。负载均衡组件，由于微服务同时启动多个实例是常有的，所以需要一个负载均衡组件来实现反向代理。网关组件，微服务的服务数量过多，有时一个操作可能由多个微服务协同完成，所以有时用户执行一个操作可能要访问多个微服务，这样不仅使得用户体验不好，也让业务逻辑混乱，所以本项目需要一个服务网关。

同时考虑到集成规则避免破坏性修改、保证API的技术无关性、服务易于消费方使用、隐藏内部实现细节。本文的微服务所暴露出的API都是基于JSON数据或者消息队列。

以上是毕业论文大纲或资料介绍，该课题完整毕业论文、开题报告、任务书、程序设计、图纸设计等资料请添加微信获取，微信号：bysjorg。

相关图片展示：