3

我想开始将我的应用程序拆分为微服务。我的第一个任务是删除我们每个应用程序中重复的功能。诸如电子邮件发送、导出、搜索索引等之类的事情——在每个应用程序中重复相同或相似代码的事情。

我只是觉得有点不知所措，很难开始。我知道微服务的目的是您可以为工作选择正确的语言，但就我们目前的目的而言，我假设 .NET 将是我将在其中构建所有内容的主要框架。

基本上，首先，我想创建一个微服务，它只发送电子邮件，我们所有的应用程序都可以与之交谈并告诉他们发送他们需要的电子邮件。我的想法是电子邮件发件人具有发送电子邮件的逻辑，但每个应用程序都需要告诉它收件人、正文等。

我正在努力解决以下问题：

  • 应用程序应该使用什么协议来与该服务通信？基于 HTTP 的 REST？如果是这种情况，电子邮件发送微服务是否有效地只是一个 Web API 2 应用程序（如果我要构建一个 REST api，这就是我个人会使用的）。

  • 如果我要使用 REST，从后端进行安静调用的最佳方式是什么？我们系统中的大多数电子邮件现在都是通过后端代码发送的。我已经看到了 RestSharp 这个名字，这通常被认为是最好的方法吗？

  • 未来的规划，我认为拥有某种了解所有服务的网关将是有益的，这样每个应用程序只需要知道这个网关，然后网关就可以与它需要的任何服务进行对话。这只是应用程序和微服务之间的另一个 REST API 吗？

抱歉所有的问题，只是在所有这些东西（和一般的建筑）上开始，以便在我的工作场所加紧工作，目前有点让我头晕目眩。

4

2 回答 2

0

由于电子邮件本质上是一个异步过程（即发即弃），并且通常需要使用一些不可靠的资源，因此最好通过消息队列（MSMQ、RabbitMQ 等）与它们集成，这些往往具有相当不错的 .net蜜蜂。

如果您超越了电子邮件之类的简单事物，可能值得花时间研究围绕队列的更大规模的框架，以便更好地支持重试、错误管理、事务管理等。这些通常被称为“服务总线”技术和.net 中有几个不错的免费 OSS，包括MassTransit和Rebus。如果/当您寻找完全受支持的 .net 服务总线时，您可能会找到其中的NServiceBus，为了充分披露，我是原作者。

于 2015-04-17T07:14:08.493 回答
0

这确实是一个大课题。进入微服务时，您需要记住，很多令人头疼的事情将是可操作的（面向 devops），而不是“代码”。

此外，那里有很多东西，以至于在某些时候你只需要做出决定，不管它是否是最佳的。在任何情况下，事情都会在此过程中发生变化。目前做出最好的决定，坚持下去，然后再进行调整。

关于您的问题，REST 是一种常见做法。还有其他选项（WCF、Avro 等）。给自己一个做决定的时间表。如果您了解 REST 并且对 REST 感到满意，请做出决定。尝试看看你是否可以构建它，以便以后可以更改/添加其他协议，但不要让它耽误你太多。

就像 Udi 说的那样，一些架构考虑因素是您是否需要调用此服务同步或异步（通过消息总线）。另外，是的，考虑一下服务发现。有几个选项（动物园管理员、领事）。

有关一些背景和概述，请尝试浏览一些资源：
http ://blog.arkency.com/2014/07/microservices-72-resources/

这也提供了微服务模式的快速概述：
http ://microservices.io/patterns/microservices.html

但同样，有很多信息和做事的方式，不要被淹没。

于 2015-04-20T07:40:24.347 回答