- 选题背景和意义：
随着计算机技术的不断发展，计算机所应用的领域越来越广，人们对计算机软件的需求也变得越来越复杂，软件系统的规模越来越大，软件的可靠性越发成为问题。曾经用的单体架构，虽然有软件项目易于设计和管理，部署也比较简单的优点，但已经逐渐不能满足软件设计的要求了。单体架构其问题集中表现在：1.测试成本随软件复杂程度提高而指数级提高，给软件企业带来巨大负担。2.软件扩展性差，当有新的需求被提出，单体架构无法很好进行迭代设计，从而不得不重新制定一个新的方案。3.可靠性差，整个软件结构呈一个烟囱型，牵一发而动全身，且所有数据集中在一个数据库里，所有功能访问同一个数据库，很容易达到数据库性能瓶颈而奔溃。4.可伸缩性差，有些时候只需要整个软件的其中一些功能，这时单体架构没法将所需功能从整个软件中剥离，给移植、简化等都带来难度。5.跨语言程度差，在不同的语言平台开发时，甚至要重新设计方案，可能会造成大量重复代码被编写，开发效率低下。6.团队协作难度较高，所有功能集成在一个筒形里，开发分工时无法准确将各个功能或服务分离，一个接口可能被多个开发人员同时实现，产生重复劳动。
虽然单体架构非常适合简单软件的敏捷开发，但遇到功能多而复杂的大型软件系统，此架构显然开始力不从心，这时必须有一个新的思路，新的架构来解决或改进以上问题，微服务架构应运而生。
二、课题关键问题及难点：
- 在线考试系统涉及到学校，班级，教师，学生和家长等多方，所以服务如何拆分成为此次课题的主要难点。
- 由于每个服务都有自己的数据库，所以如何设计数据库架构，以保证各服务自己运行良好，服务间信息通讯高效也是问题，即数据库架构的设计是此次课题的又一难点。
- 测试微服务架构的软件要比单体架构软件复杂，有时候测试一个功能就会牵扯到多个服务，这也是问题之一。
- 微服务软件的部署也相对单体架构软件要复杂，由于微服务架构服务较多，每个服务可能都需要独立进行配置、部署、扩展和监控，我们可能需要一种相对自动化的监控方案。
- 服务间的交互模式需要推敲，交互中可能会遇到接口反馈延迟的问题，需要一个解决方案。
- 文献综述（或调研报告）：
随着互联网技术的发展, 大型IT系统一般采用分布式计算模式, 以优化资源配置并提高系统可靠性、可用性和灵活性等。为了便于分布式信息系统的设计、开发与集成, 以及提高系统架构的灵活性、复用性和可增长性, 面向服务的体系结构SOA因此产生。SOA体系结构将定义良好的, 具有开放接口并独立于软硬件平台以及实现技术的单个服务组件关联起来, 以构造整体应用并采用松耦合的方式保护既有IT基础设施。实际上, SOA只是一种架构思想, 而Web服务及其相关标准和SOAP、WSDL、UDDI等协议的出现, 则为SOA的具体实践提供了技术支撑和处理方案。Web服务基于SOA架构理念, 采用一套标准技术实现了对企业间服务资源的共享和复用。SOA体系结构及Web服务等相关标准和技术的产生, 为构造松耦合的大型分布式应用指明了较好的方向, 并做了开拓性工作。
尽管Web服务为跨平台的企业开发提供了方便, 但是在开发模式上, 仍然采用的是单体架构。单体架构由于自身特点较适合小型应用的开发, 并不适用于业务复杂度较高、业务需求量较大的中、大型企业。微服务体系结构思想的出现, 则较好地解决了上述难题。其核心要义在于基于面向服务的思想, 对传统大型应用系统进行功能分解, 推动细粒度服务的使用。微服务架构 (Micro Services Architecture, MSA) 则指根据应用系统的业务需求, 通过对预定义的微服务进行重组而形成企业级应用的分布式体系结构。它主要将传统概念上的单体应用在功能、数据等方面进行分解, 划分为多个具有明确边界并可被自由重组的小规模子服务。这些子服务间采用轻量级通信方式实现交互、协作, 每个服务都有自己的数据库并可在独立进程中被部署、运行等, 服务之间保持技术异构性, 可由不同的团队选择合适的工具、语言进行开发。
与单体架构相比, 微服务架构的优势在于: (1) 微服务按业务功能划分, 每个服务都具备特定的功能, 易于开发、维护等; (2) 每个独立的微服务可以由不同的语言基于不同的平台开发, 灵活性较好; (3) 子服务可独立部署, 能够实现可持续集成及交付; (4) 容错能力强大, 单个微服务出现问题不会影响系统其他服务的运行; (5) 可实现动态按需实时扩展等。目前, 微服务体系结构的思想已被应用于很多大型公司的分布式应用系统中。
随着微服务体系结构的不断发展及成熟, 微服务框架已逐渐成为一些中大型企业从传统架构转型到微服务架构的最佳化实践。四种主流微服务框架中, 根据服务调用方式以及功能特色可将它们分为RPC (Remote Procedure Call) 型微服务框架和RESTful微服务框架两种这些框架的基本特征如表1所示。
表1 微服务框架基本特征比较
其中, Dubbo、Motan和g RPC属于RPC型微服务框架, 这类框架可以像调用本地服务一样调用远程服务, 从而实现高效可靠的网络透明传输。Dubbo和Motan属服务治理型RPC框架, 主要提供丰富的服务治理功能。与Dubbo相比, Motan去除了Dubbo中一些不常用的组件和配置, 功能虽不如Dubbo强大, 但比较简单、易用。Dubbo自2017年重新维护后又增加了对Node.js、Python等语言的支持并与当当网维护的Dubbox进行了合并, 增加了对RESTful的远程调用, 并且在序列化方式等方面也进行了扩展。g RPC则可提供对Java、Objective-C、C 、PHP等多种语言接口的支持, 但未实现较为全面的服务治理功能。Spring Cloud来源于Spring Boot框架, 本质上是一种RESTful的微服务框架, 设计时从资源的角度对系统进行拆分并为每个资源设置特定的URI。与另外三种RPC框架相比, Spring Cloud提供了搭建微服务体系结构几乎所需的全套功能, 而在Dubbo中实际上只实现了Spring Cloud中服务治理的部分。Spring Cloud因其功能全面、部署方便且操作简单, 是业界目前使用最广泛的微服务框架。
微服务作为一种分布式系统的解决方案, 为构建复杂的分布式微服务应用需提供服务注册与发现、服务间通信和服务部署等关键技术。同时, 与传统面向服务体系结构的实施方案相比, 微服务体系结构的伸缩性较好, 更能满足大型应用的需求。因此, 除需具备传统实施方案中基本的如服务注册与发现, 服务组合等功能外, 微服务体系结构还需某些扩充模块, 并对已有模块进行扩展或优化。这些扩充模块主要包括负载均衡、API网关和容错机制等。
以上是毕业论文文献综述，课题毕业论文、任务书、外文翻译、程序设计、图纸设计等资料可联系客服协助查找。
