我想开始将我的应用分成微服务。我的第一个任务是删除每个应用程序中重复的功能。像电子邮件发送，导出，搜索索引等的东西 - 在每个应用程序中重复相同或类似代码的东西。
我只是觉得有点不知所措并且努力开始。我理解微服务的目的是你可以为工作选择正确的语言，但是对于我们目前的目的，我假设.NET将是我将构建所有内容的主要框架。
基本上，首先，我想创建一个微服务，只需发送我们所有应用可以与之交谈的电子邮件，并告诉他们发送所需的电子邮件。我的想法是电子邮件发件人有发送电子邮件的逻辑，但每个应用程序需要告诉收件人，正文等。
我正在努力解决以下问题：
应用程序应使用哪种协议与此服务进行通信？ REST over HTTP？如果是这种情况，那么发送微服务的电子邮件是否会成为一个Web API 2应用程序（如果我要构建一个REST api，这就是我个人要做的事情。）
如果我要使用REST，最好的方法是从后端拨打休息电话吗？我们系统中的大多数电子邮件都是通过后端代码发送的。我已经看到RestSharp的名字被抛出，这通常被认为是最好的方式吗？
未来的计划，我认为拥有某种了解所有服务的网关将是有益的，因此每个应用程序只需要了解这个网关，然后网关就可以了解它需要的任何服务。这只是应用程序和微服务之间的另一个REST API吗？
对不起所有的问题，只是开始使用所有这些东西（以及一般的架构），以便在我的工作场所加强，现在有点让我理解。
答案 0 :(得分：0)
由于电子邮件是一个固有的异步过程（一劳永逸），并且经常需要使用一些不可靠的资源，最好通过消息队列（MSMQ，RabbitMQ等）与它们集成，这些往往很漂亮体面的.net API。
如果你超越电子邮件之类的简单事情，那么查看队列周围的大型框架可能是值得的，以便为重试，错误管理，事务管理等提供更好的支持。这些通常被称为＆＃34 ;服务巴士＆＃34;技术，.net中有一些很好的免费OSS，包括MassTransit和Rebus。如果/当您去寻找完全支持的.net服务总线时，您可能会发现NServiceBus，为了充分披露，我是原作者。
答案 1 :(得分：0)
这确实是一个很大的主题。当进入微服务时，你需要记住你的许多令人头痛的事情都是可操作的（面向devop）而不是“代码”。
此外，还有很多，在某些时候你只需要做出决定，无论它是否是最佳的。在任何情况下，事情都会发生变化。现在做出最好的决定，一起做，然后再调整。
关于您的问题，REST是一种常见做法。还有其他选项（WCF，Avro，等等）。给自己一个决定的时间表。如果您了解REST并对REST感到满意，请做出决定。试着看看你是否可以构建它以便以后可以更改/添加其他协议，但不要让它太过延迟。
与Udi一样，一些架构考虑因素是您需要调用此服务同步或异步（通过消息总线）。 此外，是的，考虑服务发现。有几种选择（zookeeper，consul）。
对于某些背景和概述，请尝试浏览一些资源：
http://blog.arkency.com/2014/07/microservices-72-resources/
这也简要概述了微服务模式：
http://microservices.io/patterns/microservices.html
但同样，有很多信息和做事方式，不要淹没。