论文总字数：25280字

摘 要

近年来，随着互联网技术的发展，对软件开发的要求也愈来愈高，当前广泛使用的单体应用模式已经不足以满足对软件开发的要求。为解决这一问题，微服务架构模式应运而生。微服务目前已经得到了广泛的应用，在使用微服务架构时，服务间的通信是比较重要的环节，如果能够设计简便好用的的服务间通信机制将会使微服务得到更好的应用。

本文首先基于微服务架构的理论，介绍了其优势以及不足之处。然后简要地介绍了公司的系统的大致架构。之后对微服务的进程间通信进行了研究，主要包括微服务间的交互方式，API的定义以及进化，局部故障的处理和消息的格式。比较了基于消息的异步通信以及基于请求/响应的同步通信之间的优缺点。最后，根据以上信息，分别设计了异步通信和同步通信两套方案供选择，其中，异步通信选择RabbitMQ作为消息系统，同步通信基于REST进行设计，根据同步通信方案的不足之处，引入了API网关以求完善。在此方案后续的测试结果中，可以证明此方案对于微服务间通信的有效性。

论文的最后对本课题所做的工作进行了总结，进一步指出后续系统中服务间通信还需解决的问题。

关键词：微服务，进程间通信，交互，消息系统，REST

Abstract

In recent years, with the development of Internet technology, the requirements for software development have become higher and higher. Currently, the single-use application mode that is widely used is insufficient to meet the requirements for software development. To solve this problem, the microservices architecture model came into being. Microservices have been widely used. When using microservices architecture, communication between services is an important link. If you can design a simple and easy-to-use service-to-service communication mechanism, microservices can be better applied.

This paper firstly introduces its advantages and disadvantages based on the theory of microservice architecture. Then briefly introduced the general architecture of the company's system. After that, we researched the inter-process communication of microservices, which mainly included the interaction mode among microservices, the definition and evolution of API, the processing of local faults and the format of messages. The advantages and disadvantages of message-based asynchronous communication and request/response-based synchronous communication are compared. Finally, according to the above information, two schemes of asynchronous communication and synchronous communication are designed for selection. Among them, RabbitMQ is selected as the message system for asynchronous communication, and synchronous communication is designed based on REST. According to the shortcomings of the synchronous communication scheme, the API gateway is introduced in order to improve deficiencies. In the subsequent test results of this solution, it can be proved that this solution is effective for communication between microservices.

At the end of the thesis, the work done by this topic is summarized, and further points are pointed out that the communication between services in the follow-up system still needs to be solved.

KEY WORDS: Microservices, interprocess communication, interaction, message system, REST

目录

摘要 I

Abstract II

第一章 绪论 1

1.1 研究背景及意义 1

1.2 国内外研究现状 1

1.3 论文主要工作 2

1.4 论文组织结构 2

第二章 微服务架构与公司系统 3

2.1 微服务架构 3

2.1.1 微服务架构相对于单体式应用的优势 3

2.1.2 微服务架构存在的不足之处 3

2.2 公司系统介绍 4

2.3 本章小结 5

第三章 微服务进程间通信 6

3.1 交互方式 6

3.1.1 一对一交互 6

3.1.2 一对多交互 6

3.2 定义API 6

3.3 API进化 7

3.4 处理局部故障 7

3.5 进程间通信技术 8

3.5.1 异步，基于消息的进程间通信 8

3.5.2 同步，基于请求/响应的进程间通信 9

3.6 消息格式 10

3.7 本章小结 11

第四章 服务间通信的设计与实现 12

4.1 基于消息的异步通信 12

4.1.1 Apache Kafka和RabbitMQ的对比 12

4.1.2 基于RabbitMQ的消息系统的实现 13

4.2 基于REST的同步通信 15

4.3 对基于REST的同步通信方案的测试 18

4.3.1 测试内容 18

4.3.2 测试工具 18

4.3.3 测试方法 18

4.3.4 测试结果 18

4.4 本章小结 20

第五章 总结与展望 21

5.1 工作总结 21

5.2 未来展望 21

致 谢 22

参考文献 23

绪论

研究背景及意义

当我们构建应用程序时，通常会采用单体应用模式。采用这种方式进行应用构建时，应用程序通常会当作被作一个整体进行打包以及部署，而且在早期我们会发现有几个非常明显的优点，也就是容易开发，容易测试，容易部署。但是这种方式也有着显而易见的缺点^[1]，也就是随着软件不断的开发，应用程序会变得越来越臃肿。为了实现不断增加的需求，越来越多的代码需要添加到这个系统中来，于是早期的一个简单的应用会变得越来越庞大。一旦应用程序变成庞大且复杂的单体，对于开发者来说都是噩梦。由于整个应用的结构变得复杂，修改bug以及添加新需求的工作将会变得异常困难，此时，应用程序的可靠性也将降低，当出现bug时，极有可能引起整个应用的罢工。同时，调试的时间也会变长，这将意味着开发者需要花费非常长的时间来等待程序编译，造成开发效率的降低。此外，当有新技术出现时，例如有更好的框架出现，采用这种方式开发的应用程序将很难采用新技术，由于整个应用过于庞大，整个应用程序迁移将变得不现实，时间和成本方面的代价将会非常昂贵。而且，当有新人加入团队时，他需要用来熟悉整个系统的时间将变得很长，不能很快就接手开发任务，这对团队来说是效率的降低^[2]。

为了应对这些缺点，微服务架构模式应运而生。微服务^[3]这一概念在2012年首次出现，微服务架构模式的核心在于将一个应用划分为多个小的，互相关联的服务。由于其相对于单体应用模式的优点，逐渐被大家所接受并使用。而因为微服务是一种在云中部署应用和服务的新技术，因此随着云计算这一技术的普及以及发展^[4]，微服务架构也变得越来越受欢迎。很多公司，例如Amazon^[5]、Uber^[6] 和 Netflix^[7]等等，都正在使用微服务架构模式解决一些结构过于复杂的问题。

剩余内容已隐藏，请支付后下载全文，论文总字数：25280字