Java 进程之间的通信是否仍在微服务中？
Is communication between to Java processes still within Microservices?
实际上我即将实现一些微服务架构。
在一台 Windowns 机器上有三个不同的进程 运行 我要让它们相互通信。
这是微服务的范式吗？还是我太过分了？
Context：一个让前端 webapp 执行位于服务器后端机器上的 tools/scripts 的系统。
组件:
- REST 接口（webapp 前端与之通信）
- ToolBoxExecutor（REST 控制器与之通信）
- ToolSyncer（由 ToolBoxExectutor "triggered" 刷新工具的所有 Git 存储库）
这三个组件没有太多的逻辑负载 - 但我仍然希望它们不要充当 REST 控制器的服务 - 只是为了 "microservices"。我希望它们都是三个独立的 java 应用程序。
我走对了吗？
High-level
Am I on the right track?
没有。通过关注一种新兴的、as-yet 松散定义的架构风格作为你的目标 objective，你完全没有抓住要点。值得考虑的是，微服务架构的设计和架构属性是否适合您的项目，但您正在倒退。对我来说，这是一个危险信号，你声称“只是为了 'microservices'” 做出设计决定。
关于微服务的分析
至于你是否真的在构建微服务风格的东西（无论对你有价值的东西），让我们看看微服务的特征 as described at martinfowler.com:
通过服务进行组件化
据我所知，从您介绍的内容来看，您确实在这样做，但我真正需要继续的是，您在几个不同的合作过程中拥有 运行ning 部分。这并不是作为组件或作为服务运行的全部内容。每个组件应该有一个 well-defined 作业和一个 well-defined 接口，尽可能独立于实现特性。组件应该只依赖彼此定义的接口来进行互操作。
围绕业务能力进行组织
在 运行 看来，您所展示的内容与此特征完全相反，围绕技术层而不是业务功能进行组织。
产品不是项目
这更多的是生命周期管理方面的考虑，而不是架构方面的考虑。目前还不清楚你是否以这种方式运作，但你提出问题的方式让我倾向于猜测不是。
智能端点和哑管道
您的设计是否具有此特征尚不清楚，但考虑到您定义的组件的性质，这似乎很有可能。
在某种程度上，将整个事物视为一个微服务可能更合适（请参阅上面的“围绕业务能力组织”），它具有 REST 接口这一事实是一个好兆头。
去中心化治理
这又是一个特点，似乎有点larger-scale不如你一个人的努力。在某种程度上，你似乎可以自由地设计和构建你的产品，你似乎确实从去中心化治理中受益。然而，由于您似乎是一个 one-man 团队，这在您正在进行的开发工作范围内并不真正适用。
去中心化数据管理
不清楚您的计划是否具有此特征，甚至不清楚它在多大程度上适用于您。
基础设施自动化
再次不清楚这在多大程度上体现了您的意图，甚至在多大程度上属于您的关注范围。
失败设计
您没有说任何与此特征相关的内容。
进化设计
尚不清楚您提议的架构在多大程度上展现了这一特征。不过，我倾向于猜测不是很多。
总体
您所描述的似乎与 Martin Fowler 所描述的术语“微服务架构”所适用的规模不符。您可以根据自己的规模应用此范例的某些方面；其中一些您似乎适用，其他一些您似乎不适用，还有一些我无法根据您的架构概述进行评估。
我认为尝试将所有这些特征带入你的规模并不能很好地为你服务，而且你这样做的程度当然不是衡量你设计质量的好指标。您可能希望将产品设计为在更大的微服务环境中工作，但这对您几乎没有限制；事实上，为您提供的自由是微服务方法的主要优势之一。
实际上我即将实现一些微服务架构。 在一台 Windowns 机器上有三个不同的进程 运行 我要让它们相互通信。
这是微服务的范式吗？还是我太过分了？
Context：一个让前端 webapp 执行位于服务器后端机器上的 tools/scripts 的系统。
组件:
- REST 接口（webapp 前端与之通信）
- ToolBoxExecutor（REST 控制器与之通信）
- ToolSyncer（由 ToolBoxExectutor "triggered" 刷新工具的所有 Git 存储库）
这三个组件没有太多的逻辑负载 - 但我仍然希望它们不要充当 REST 控制器的服务 - 只是为了 "microservices"。我希望它们都是三个独立的 java 应用程序。
我走对了吗？
High-level
Am I on the right track?
没有。通过关注一种新兴的、as-yet 松散定义的架构风格作为你的目标 objective，你完全没有抓住要点。值得考虑的是，微服务架构的设计和架构属性是否适合您的项目，但您正在倒退。对我来说，这是一个危险信号，你声称“只是为了 'microservices'” 做出设计决定。
关于微服务的分析
至于你是否真的在构建微服务风格的东西（无论对你有价值的东西），让我们看看微服务的特征 as described at martinfowler.com:
通过服务进行组件化
据我所知，从您介绍的内容来看，您确实在这样做，但我真正需要继续的是，您在几个不同的合作过程中拥有 运行ning 部分。这并不是作为组件或作为服务运行的全部内容。每个组件应该有一个 well-defined 作业和一个 well-defined 接口，尽可能独立于实现特性。组件应该只依赖彼此定义的接口来进行互操作。
围绕业务能力进行组织
在 运行 看来，您所展示的内容与此特征完全相反，围绕技术层而不是业务功能进行组织。
产品不是项目
这更多的是生命周期管理方面的考虑，而不是架构方面的考虑。目前还不清楚你是否以这种方式运作，但你提出问题的方式让我倾向于猜测不是。
智能端点和哑管道
您的设计是否具有此特征尚不清楚，但考虑到您定义的组件的性质，这似乎很有可能。
在某种程度上，将整个事物视为一个微服务可能更合适（请参阅上面的“围绕业务能力组织”），它具有 REST 接口这一事实是一个好兆头。
去中心化治理
这又是一个特点，似乎有点larger-scale不如你一个人的努力。在某种程度上，你似乎可以自由地设计和构建你的产品，你似乎确实从去中心化治理中受益。然而，由于您似乎是一个 one-man 团队，这在您正在进行的开发工作范围内并不真正适用。
去中心化数据管理
不清楚您的计划是否具有此特征，甚至不清楚它在多大程度上适用于您。
基础设施自动化
再次不清楚这在多大程度上体现了您的意图，甚至在多大程度上属于您的关注范围。
失败设计
您没有说任何与此特征相关的内容。
进化设计
尚不清楚您提议的架构在多大程度上展现了这一特征。不过，我倾向于猜测不是很多。
总体
您所描述的似乎与 Martin Fowler 所描述的术语“微服务架构”所适用的规模不符。您可以根据自己的规模应用此范例的某些方面；其中一些您似乎适用，其他一些您似乎不适用，还有一些我无法根据您的架构概述进行评估。
我认为尝试将所有这些特征带入你的规模并不能很好地为你服务，而且你这样做的程度当然不是衡量你设计质量的好指标。您可能希望将产品设计为在更大的微服务环境中工作，但这对您几乎没有限制；事实上，为您提供的自由是微服务方法的主要优势之一。