grade 子项目部署_子系统的两种类型的部署

grade 子项目部署

在开发过程中，您有时会拥有很少更改的系统部分，需要大量资源，具有许多先决条件和/或需要大量时间来部署。 你通常做什么？ 将该部分提取到一个单独的应用程序中，并在一个或多个服务器上运行，让开发人员连接到这些服务。 例如：搜索引擎界面，CPU密集型操作，第三方系统等。在某种程度上，您可以使系统模块化。

但是，这种模块化存在一个缺点–它增加了复杂性和故障点。 如果模块之间的通信中断，该如何跟踪和调试问题（它们可能是由两个（或多个）系统中的任何一个引起的），如何使应用程序的公共接口的多个版本保持同步（怎么办）？您需要多个版本并存？），如何在一个原子步骤上处理两个应用程序的部署等等。

很多时候，您不需要引入这种复杂性，但是在开发过程中仍然需要灵活性。

我有时使用的一种选择是使子系统既嵌入式又作为独立模块。 为此，您需要制作一个处理两种部署类型的薄层（从架构角度将其称为层；就代码而言，它将由2个类和一个接口组成）。 有一个接口定义了由模块执行的操作，还有两个实现–一个是RESTful，调用单独部署的应用程序的RESTful服务，一个只是封装执行实际操作的类（甚至是类本身）。并且存在于应用程序的类路径中。

一个例子。 您有一个ExtractionService ，它必须对输入执行一些文本分析和概念提取。 这需要大量的CPU和内存，因此每个开发人员都无法在本地运行它。 你做

• ExtractionService接口，定义提取操作
• RestfulExtractionService ，它配置了终结点URL，并调用包装实际提取实现的restful服务
• ClasspathExtractionService ，它可以是实际的提取实现，也可以是其简单包装。

您如何根据项目及其依赖项来组织它？ 您有一个单独的带有打包实现的jar打包项目，有一个war打包的项目（取决于jar），该项目将实现包装在RESTful API中，您的主应用程序也取决于jar。

根据您是处于开发模式还是生产模式，如何切换实现？ 这取决于您使用的框架。 使用spring时，您只需拥有@Resource("${service.implementation}") ExtractionService service ，即可在外部配置 service.implementation 。

您为什么需要它，这是否增加了开销，为什么我不只是保持生产中的模块化？ 您将能够构建和部署一个整体应用程序（仅具有类路径依赖项）并将其部署到生产环境中，而不必担心第二段中提到的问题。 您要保持体系结构简单，这始终是一件好事。 同时，无需重新部署系统的繁重部分，即可在开发过程中获得很大的灵活性。 只需几个类和一个配置开关即可实现所有这些功能。 当然，它并不总是适用，但是如果您遇到类似的情况，请考虑将其作为一种选择。

参考： Bozho的技术博客博客中的JCG合作伙伴 Bozhidar Bozhanov的 两种子系统部署类型 。

翻译自: https://www.javacodegeeks.com/2013/07/two-types-of-deployment-for-subsystems.html

grade 子项目部署