我的项目的架构是微服务架构？

Question

在我的项目中，我们以一个SOD脚本开始新的一天，该脚本执行了一天中的某些功能。然后它在完成时生成事件，从而触发更多的进程来启动数据加载，这样的进程链有时会通过事件生成或数据库中的状态更新而继续运行。

所有流程都是使用不同语言开发的独立服务吗？这种架构是归类为微服务架构还是更像事件驱动系统？如何区分它们

Answer 1

您在这里没有给出很多信息，但是我将根据您给出的信息进行回答。您提到您有独立运行的独立流程。这些字面意义上的多个进程是在一台机器上运行还是在指单个服务（例如多个API）？各个服务是否依赖于其他服务的数据？听起来您说的是一项服务呼叫另一项服务，依此类推。

通常来说，微服务体系结构由多个单独的服务（API，后台服务等）组成，每个服务都为整个应用程序贡献自己的“部分”。在域驱动设计术语中，每个部分都称为有界上下文。每个服务应自主运行，拥有其数据（多个服务不应共享一个大数据库），并且应位于为其设计的特定有界上下文中。这些服务中的每一个都独立运行，很多时候使用Kubernetes或其他类型的容器协调器。然后，客户端应用程序（即Web UI）可以通过类似API网关的请求。然后，网关可以接收该请求，调用所需的单个服务，然后进行汇总或构建响应以发送回客户端。每个服务都是它自己的难题所在，将它们组合在一起便构成了整个应用程序。

这是一个非常简化的解释，因为这个主题很大，所以不要以我所说的为特定定义。微服务的整个概念实际上只是应该遵循的一组原则，而不是如何设计应用程序体系结构的特定蓝图。如果您想进行研究以真正更好地了解此主题，我可以推荐Microsoft的有关容器化微服务应用程序的电子书。另外，我在微服务方面的经验主要是与Web相关的应用程序或系统，因此也许有其他经验的人可以提供更多帮助。