我了解微服务是关于独立的松散耦合服务。我已阅读https://en.wikipedia.org/wiki/Microservices。
谈到 Azure，我知道有许多组件，例如 Azure Service Fabric、AKS，并且还可以选择使用 Docker 或任何其他容器化工具在 Azure VM 中部署容器。但是，由于微服务是关于开发 atmoic 可单独扩展的服务，这也可以通过将每个服务部署为应用服务计划中的 Azure Web API APP 并根据性能指标配置自动缩放来实现（尽管每个 API APP 可能不是单独的可扩展，它们仍然可以在部署、配置等方面单独管理）？
有人可以建议这个思维过程是否正确吗？
【问题讨论】：
标签： azure microservices azure-container-service
微服务不是平台或技术，因此如果您可以制作小型可独立部署的服务，那么它们就是微服务。当然 - 一些技术会有所帮助，但这取决于您的情况。
如果您只需要一些服务，您可能不需要任何复杂的服务。确保服务建模良好，拥有自己的数据，理想情况下具有良好的监控和部署管道设置。尽可能针对服务故障进行设计。
您需要独立缩放每个部分吗？理想情况下，您应该能够，但服务有非常不同的要求吗？您可以有许多小型应用服务计划，但这是以未使用资源为代价的，因此需要时进行拆分。
【讨论】：
这个问题和答案当然是基于意见的，但通常在考虑微服务时，不要考虑 API 和 VM 等负载。而是考虑。当我上传图片时，需要调整其大小，并更新表格以提供拇指的网址。或者当 XXX 记录在数据库中更新时，运行 XXX 以创建报告，或更新 Azure 搜索。而且每个服务，只知道如何做一件事情而已。即调整图像大小。
现在可以说。我有一个系统、一个 repo 库和一些函数库。当一张图片发布时，我上传，然后调用这个，那个等等。
使用 Micor 服务。相反，您只需将图像添加到队列中。创建一个具有队列触发器的 azure 函数。这将调整大小并将大和拇指保存到存储中。然后这将更新数据库，或者在真正的微服务中，它会添加一个队列来存储新信息，另一个函数会监视该队列并插入到数据库中。
您可以从任何地方使用数据库队列。您可以从任何地方使用 Blob 队列。您的主要 API 并不关心图像的处理方式。您可以在某一天更改您的功能，以保存到 Dropbox，而不是 azure blob。一切都非常简单，无需重新构建 API，因为 API 并不关心。
我使用它的一个很好的例子是电子邮件和短信。我的系统不知道如何发送电子邮件或 SMS。他们只知道如何添加到队列中。我的微服务。 SendEmail 和 SendSMS 确实知道该怎么做，而且我可以更改发送内容的方式和对象，真的很容易。我明天可以从 Twilio 更改为发送网格，而无需告诉 API 我已经完成了它。
关于更复杂的事情。我已获得批准，此时批准会向用户或管理员发送电子邮件或 SMS，并且可能会随着时间而改变。所以我有一个短信服务器、电子邮件服务和approvalService。当批准发生时，它只是将配置添加到队列中，其余的由逻辑应用程序完成，它知道向 XXX 发送电子邮件，向 XXX 发送短信，然后更新数据库。我的 api，只是一个帖子，它创建了一个队列。
基本上我在这里说的是开始，也许是移植一个现有的应用程序。从工作流程开始，例如发送电子邮件、调整图像大小、创建报告、创建 PDF、向 50 个订阅者发送电子邮件等，然后将所有代码取出并放入只知道如何做一件事的自己的微服务中。然后，当您充满信心地成长时，使用逻辑应用从所有这些服务创建一个工作流，让 azure 处理其余的事情，这就是他们想要做的。
【讨论】：