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

Question

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

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

Answer 1

您在这里没有提供很多信息，但我会尝试根据您提供的信息来回答。您提到您有独立运行的独立流程。这些实际上是在一台机器上运行的多个进程，还是您指的是单个服务，例如多个 API？单个服务是否依赖于其他服务的数据？听起来您是在说一个服务调用另一个服务，依此类推。

一般来说，微服务架构由多个独立的服务（API、后台服务等）组成，每个服务都为整个应用程序贡献自己的“部分”。在领域驱动设计术语中，这些部分中的每一个都被称为有界上下文。每个服务都应该自主运行，拥有它的数据（多个服务不应该共享一个大数据库）并保持在它所设计的特定有界上下文中。这些服务中的每一个都是独立运行的，很多时候使用 Kubernetes 或其他类型的容器编排器。然后，客户端应用程序（即 Web UI）可以通过 API-Gateway 之类的东西发出请求。然后网关可以接受该请求，调用它需要的各个服务，然后聚合或构建响应以发送回客户端。每个服务都贡献了自己的一块拼图，当它们组合在一起时，它们就构成了整个应用程序。

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