一、文献综述
（一）国内外研究现状
正如文献[5]中所描述，传统的企业系统架构中，针对一个复杂的业务需求，通常使用对象或业务类型来构建一个单体项目。在业务初期，由于所有的业务逻辑在一个应用中，开发、测试、部署都还比较方便。但是随着企业的发展，系统为了应对不同的业务需求不断为该单体项目增加不同业务模块。单体应用往往面对的业务需求广泛，不断扩大的需求会使得单体应用变得越来越臃肿。
而单体应用常常部署在一个进程内，往往修改一个很小的功能后部署上线，可能会影响到其它功能。单体中各个功能模块使用场景、并发程度、资源消耗各有不同，对资源的利用又互相影响，因此对各个功能模块的系统容量难给出较为准确的评估。随着系统的发展，维护成本会变得越来越大，且难以控制。
单体应用的扩展只能复制多个应用副本，这种扩展方式将会带来更多的资源浪费，因为在单体应用中，可能真正出现瓶颈的只是其中部分模块，而其他模块并不需要这么多的资源，在复制副本的时候所有模块都将被复制。
为了解决单体应用的问题，在长期的实践中产生了一种分布式的系统架构风格“微服务”。如文献[3]中所描述，微服务架构风格是一种将单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理中心，服务可用不同的语言开发，使用不同的数据存储技术。
大量的服务被拆分成一个一个单体应用，各个应用需要的依赖环境也是各种各样。有时候会出现，在开发的机器上运行的好好的，但是在测试的机器上就不能运行的问题。对于运维人员来说，需要熟悉各种环境的搭建，花费了极大时间和精力，而且非常容易出错。目前多数服务器上的资源都没得到充分的利用。一个应用占了整台服务器的资源，而应用实际上只是用到服务器上资源的30%甚至更低，而且同一个服务器上的应用环境并非独立，可能还会造成互相影响的异常出现。在使用虚拟机之后好像问题都解决了，但是虚拟机自身又带来了不可忽略的性能损耗和资源开销。为了解决上面的问题，人们参考了过去海运的问题，从运集装箱出取得灵感，于是诞生了容器，容器提供相互隔离，并且完整干净的环境，给部署带来了极大的便利。参考：文献[4]、文献[6] 、文献[8] 、文献[15]。
服务得到了拆分，部署也变的更加迅速，为了适应业务的调整可能需要对部分服务进行扩容。由此产生了大量的各种各样的服务，这些服务散布在各种各样的地方，管理这些服务又成了一大难题，由此便产生了服务编排。参考：文献[6]。
电子文档根据不同的存储方式，一般可分为流式文档和版式文档。流式文档主要存储的是逻辑数据，文字内容主要借助流式布局进行从上到下自然排版，受不同环境引用，显现不同排版效果。版式文档是将文字、图形、图像等多种数字内容对象按照一定规则进行版面固定呈现，是一种独立于软件、硬件、操作系统、呈现/打印设备的的电子文档格式。参考：文献[10]。
以上是毕业论文文献综述，课题毕业论文、任务书、外文翻译、程序设计、图纸设计等资料可联系客服协助查找。
