到Java进程之间的通信是否仍在微服务中？

实际上，我即将认识到一些微服务架构。 在一台Windowns机器上运行三个不同的进程，我将让它们相互通信

这是微服务的范例吗？还是我太过分了

上下文：允许前端Web应用程序执行位于服务器后端计算机上的工具/脚本的系统

组件：

• REST接口（webapp前端与之通信）
• ToolBoxExecutor（REST控制器正在与之通信）
• ToolSyncer（由Toolboxexector“触发”以刷新工具的所有Git存储库）

这三个组件没有很大的逻辑负载，但我仍然希望它们不要仅仅为了“微服务”而充当REST控制器的服务。我希望它们都是三个独立的java应用程序

我在正确的轨道上吗？

高水平 我走对了吗

不。如果把重点放在一种新兴的、但定义松散的体系结构风格上作为最终目标，那么你就完全没有抓住要点。值得考虑的是，被认为是微服务体系结构特征的设计和体系结构属性是否适合您的项目，但您正在将其反过来。对我来说，你声称“仅仅为了‘微服务’而”做出设计决策是一个危险信号

关于微服务的分析 至于你是否真的在构建微服务风格的东西（无论对你来说有什么价值），让我们看看微服务的特点：

通过服务实现组件化 据我所知，从你们所介绍的内容来看，你们确实在做这件事，但我真正要做的是，你们在几个不同的、协作的过程中运行着一些片段。这不是作为一个组件或作为一个服务运行的全部。每个组件都应该有一个定义良好的作业和一个定义良好的接口，尽可能独立于实现特性。组件应仅依赖彼此定义的接口进行互操作

围绕业务能力进行组织 您所介绍的内容似乎与此特征正好相反，是围绕技术层而不是业务能力进行组织的

产品而非项目 这与其说是体系结构方面的考虑，不如说是生命周期管理方面的考虑。现在还不清楚你是否是这样运作的，但你的提问方式让我倾向于猜测不是这样

智能端点和哑管道 您的设计是否具有此特性尚不清楚，但考虑到您定义组件时组件的性质，这似乎是可能的

<> P>在将整个事情看作一个微服务（参见“围绕业务能力组织”）的情况下，更合适的是，它有一个REST接口是一个很好的标志。 分权治理 这是另一个比你的努力更大的特点。在某种程度上，您似乎可以自由地设计和构建您的产品，似乎您确实从分散的治理中获益。然而，由于您似乎是一个人的团队，所以在您正在进行的开发工作的范围内，这实际上并不适用于内部

分散数据管理 目前还不清楚你的计划是否具有这一特点，甚至不清楚它在多大程度上适用于你

基础设施自动化 现在还不清楚这对你的意图有多大的影响，甚至在你所关注的领域内也有多大程度的影响

失效设计 你没有说过与这个特征有关的话

进化设计 目前还不清楚您提出的体系结构在多大程度上体现了这一特点。不过，我倾向于猜测得不多

全面的 正如Martin Fowler所描述的，您所描述的内容似乎与“微服务体系结构”这个术语所适用的范围不同。当然，你可以在你的尺度上应用这个范例的某些方面；其中有些似乎确实适用，有些似乎不适用，还有一些我无法根据您的体系结构概述进行评估

---

我认为，试图将所有这些特性纳入您的规模并不能很好地满足您的要求，当然，您这样做的程度并不能很好地衡量您的设计质量。您可能希望设计产品在更大的微服务环境中工作，但这对您没有什么限制；事实上，为您提供的自由是微服务方法的主要优势之一。

非常感谢您为我扫清了障碍。我会用新学到的知识重新思考这个问题！