实际上我即将实现一些微服务架构。 在一台Windowns机器上运行三个不同的进程，我即将让它们相互通信。
这是微服务的典范吗？或者我是不是推得太远了？
上下文：允许前端Web应用程序执行位于服务器后端计算机上的工具/脚本的系统。
零件：
这三个组件没有很大的逻辑负载 - 但我仍然希望它们不要充当REST控制器的服务 - 仅仅是为了微服务＆＃34;。我希望它们都是三个独立的java应用程序。
我是否走在正确的轨道上？
答案 0 :(得分：1)
我是否走在正确的轨道上？
没有。通过专注于一种新兴的，尚未松散定义的建筑风格作为最终目标，你完全忽略了这一点。考虑到微服务架构特有的设计和架构属性是否适合您的项目是值得考虑的，但是您需要将其转向倒退。你声称自己正在做出设计决定并且只是为了“微服务”而对我来说是一个红旗。＆＃34;＆＃34;
至于你是否实际上是以微服务的方式构建一些东西（无论对你有什么价值），让我们来看看微服务特征as described at martinfowler.com：
据我所知，你确实是这样做的，但我真正需要做的就是你在几个不同的合作过程中运行。这不仅仅是组件，也不是作为服务运行。每个组件都应具有明确定义的作业和明确定义的接口，尽可能独立于实现特性。组件应该只依赖于其他组件＆＃39;定义了互操作的接口。
您所呈现的内容似乎与此特征背道而驰，围绕技术层而非业务能力进行组织。
这更像是生命周期管理的考虑因素，而不是架构管理考虑因素。目前还不清楚你是否以这种方式进行操作，但是你的问题让我感觉不舒服。
您的设计是否具有此特性尚不清楚，但考虑到您定义组件的性质，它似乎很可能。
在某种程度上，将整个事物视为一个微服务可能更合适（参见＆＃34;围绕业务能力组织＆＃34;上面），它具有REST接口这一事实是一个好兆头。 / p>
这是另一个特征，似乎比你单独的努力规模更大。在某种程度上，您似乎主要是自由设计和构建您的产品，看起来您确实从分散治理中受益。但是，由于你似乎是一个单人团队，因此在你正在进行的开发工作范围内并不真正适用于内部。
目前还不清楚您的计划是否具有此特征，甚至是否适用于您。
它再次不清楚这是如何表达你的意图，以及它在你关注的范围内的程度。
你没有说过这个特点。
目前还不清楚您提出的架构在多大程度上展现了这一特性。不过，我倾向于猜不太多。
您所描述的内容似乎与术语＆＃34;微服务架构＆＃34;正如Martin Fowler所描述的那样适用。您可以按照您的规模应用这种范式的某些方面;其中一些似乎适用，有些你似乎不适用，有些我无法评估你的架构概述。
我并不认为您可以通过尝试将所有这些特性带到您的规模来获得良好的服务，当然，您这样做的程度并不是设计质量的良好指标。您可能希望将产品设计为在更大的微服务环境中工作，但这对您几乎没有限制;实际上，为您提供的自由是微服务方法的主要优势之一。