在同一服务器上运行Spring Clound配置和Eureka

我们正在尝试为我们的应用程序创建一个仪表板，作为单个入口/配置点。为此，我们将构建和UI，并希望在同一个实例上运行SpringCloud。我们有什么理由不这样做吗？如果没有，这是可能的吗？

@mvlupan，没有什么能阻止你们一起使用。这就是我们创建

@EnableEurekaServer

和

@EnableConfigServer

的原因之一

pom.xml

snippet

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>1.2.7.RELEASE</version>
    <relativePath/> <!-- lookup parent from repository -->
</parent>

<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-config-server</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-eureka-server</artifactId>
    </dependency>
</dependencies>

application.properties

snippet（这样eureka和配置服务器就不会冲突）

---

为了在生产环境中实现高可用性，应至少有2个实例在不同的服务器上运行

ConfigServer和EurekaServer都应该有2个实例

就我个人而言，我更喜欢看到ConfigServer和EurekaServer作为一个进程运行，如@Spencergib所示

首先运行的是配置优先或发现优先方法

附言。 我希望您的仪表板应用程序将与ConfigServer/EurekaServer分开，

---

因此，它自身的问题不会影响业务关键部件。

好吧，我想问另一个问题。你为什么要这么做？克服同源政策？在这种情况下，我将构建一个“前端”引导应用程序，为用户界面和代理Eureka和配置服务器提供服务。ideea将创建一个具有一些UI（管理）功能的spring引导应用程序，并集成配置和Eureka服务。这将简化我们的部署过程，因为我们正在考虑部署到可以部署jar的地方。你的建议将迫使我们把一切都包装成码头工人的形象。我不是说这是一个坏主意，但是我们会为这个服务单独部署一个程序。为什么你认为你不能把它包装成一个罐子呢？我想我需要3个单独的spring“引导”应用程序。也许你可以分享一下如何在一个jar中包装这3个应用程序，然后用

java-jar以“正常”的方式开始…

我确实理解你的想法，但这也与微服务的想法相矛盾。顺便说一句：如果你只有一个罐子，你为什么需要Euraka？谢谢你的回答。现在我想知道它是否有意义。因为配置服务用于提供跨环境的配置（dev/prod/etc）…而Eureka似乎与某个环境绑定，在那里它连接不同的服务。Eureka是否具有此能力（与多个环境一起工作）？这有意义吗？@mvlupan那么你最终使用了什么？

@EnableEurekaServer
@EnableConfigServer
@SpringBootApplication
public class DemoconfigandeurekaserverApplication { /*...*/}

spring.cloud.config.server.prefix=/config