微服务架构，在这种情况下是什么服务

Question

我正在阅读一些关于微服务架构的文档（通过this link for example），我想知道在这种情况下究竟是什么服务。

在IT中，一切都可称为服务： - 通过java命令启动的SPRING REST应用程序，如：

  

java -jar build / libs / gs-rest-service-0.1.0.jar

• 它也可以是与DDD中的业务层相对应的类
• 它可能只是与所研究的领域有关的东西，比如向某人提供某些东西
• 和其他许多人......（android后台运行服务等......）

但在微服务中，它意味着什么？例如，在Java EE堆栈中使用什么样的技术/工具来创建“自己运行的服务”？它只与webservices有关吗？

Answer 1

我自己的定义：

微服务是一个独立的，解耦的组件，可以处理单个业务问题，并且可以从其他服务中获取。

其他人可能会同意或不同意，并且就此主题进行了许多有趣的讨论，使其成为软件工程师的一个重要研究点。

从技术角度来看： 您几乎可以在任何技术中创建微服务：Java EE，Java + Spring，Python，Rails，Grails，Node.js等等。从我所看到的，它似乎最常应用于Web应用程序和后端面向服务的生态系统领域。在您引用的文章中，NetFlix模型是一个非常有趣的研究，因为您可以深入了解微服务架构的所有元素：服务发现，断电，监控，动态配置等。

如果您是面向Java的，可能需要查看一些内容：

Spring Cloud允许您使用这些相同的NetFlix组件，只需少量手动编码：http://cloud.spring.io/spring-cloud-netflix/

github上的实际操作示例（不是我的，但我在自己的主题学习中使用过它）：https://github.com/ewolff/microservice

从概念的角度来看，你的问题暗示了一个臭名昭着的微服务设计困境。没有必要正确的＆＃34;微服务的粒度级别。我们的想法是选择在您的业务领域中具有意义的粒度级别。如果你以非常低的粒度级别（例如CRUD级别）实现微服务，那么你几乎肯定会得到非常繁琐的服务，你可能不得不在顶层构建更有意义的复合服务。如果你选择的粒度级别太高，你最终可能会得到一个更整体的应用程序，这可能需要稍后重构为微服务大小的部分。

Answer 2

以前的答案很棒。 微服务架构只是功能分解设计。

我建议你阅读这篇博文：Microservice Design Patterns

从技术角度来看，有很多工具如Docker（将每个微服务作为linux容器运行）和Kubernetes来协调它们作为服务（这里是一个Kubernetes sample）。

Answer 3

确切地说，这就是微服务模型的美妙之处！例如，在设计maven多模块项目时，您可以开始考虑微服务。低耦合，明确的关注点分离，甚至可能是异步通信。当您更自信地将它们提取到应用程序中并在一个主机中运行时，下一步 - 在不同的主机中运行。由您决定应该如何部署它们，它与您希望实现的目标（容错与低延迟等）和您拥有的DevOps资源相关（因为您需要更多分离，因此需要更多维护）。 / p>

关于Java EE堆栈 - 没有什么特别的，只是通常使用 java -jar 运行的jar或war文件或像Tomcat这样的应用程序服务器。

另一个方向是使用Docker + CoreOs / kubernetes / ...，Mesos + Marathon等工具，但它们适用于微服务中的任何语言/框架。

修改

微服务可以使用同步（REST，SOAP）和异步协议（如ActiveMQ，RabbitMQ等消息队列）的组合。由您来决定如何组合它们。我的例子：labs.bench.co/2014/12/10/microservices-at-bench-intro

Answer 4

微服务的服务是Java是JavaScript。不要这么想。相反，微服务可以被认为如下：

1. 一个小问题域。
2. 自行构建和部署。
3. 在自己的过程中运行。
4. 通过众所周知的界面进行整合。
5. 拥有自己的数据存储。

Answer 5

我会从你的上一个问题开始 - 它只与webservices有关吗？ 这是值得商榷的。我会说，不。它与webservice有关（但不仅仅与它有关。）

在所有微服务是服务之后，Martin fowler将微服务描述为<小的SOA子集，而SOA是一个非常通用和广泛的术语。

下面是微服务重要方面的一些：

1. 每个服务（或一组少数服务）应该拥有自己的数据存储。
2. 服务是围绕业务需求或功能组织的。
3. 每项服务都是独立的，因此可以用任何语言实施。导致团队中的多语言编程文化。
4. 服务也可以接受客户或其他服务的请求。
5. 它们通常是事件驱动和异步的，因此缩放变得更容易。
6. 服务是愚蠢的，因为他们只做一件事（但他们应该自己足以监控自己）
7. 它们可以帮助您进行持续部署或交付，因为实施部署周期非常小。

8. 它们非常小，因此在部署它们时没有太多的网络开销。因此，可以在几分钟内跨节点集群部署它们。

   另外，我想强调的是，以上不仅仅是微服务的真实情况。像谷歌，netflix和亚马逊这样的公司在创造这个词之前就已经做过类似的事了。

Answer 6

微服务基本上是一个独立的过程，提供独特的单一业务功能。我们不创建Web微服务，业务逻辑微服务或数据库微服务。

为何选择微服务？

• 微服务使我们的系统松散耦合，即如果我们需要更新，修复或更换微服务，我们不需要重建我们的整个应用程序，只需更换需要它的部分。
• 构建每个微服务可以使用不同的语言和工具。微服务与定义良好的接口进行通信
• 对于可扩展性（微服务的副本）和可靠性（一个副本无法通过其他副本可以服务），通信应该是无状态的，微服务之间最常用的通信方法是HTTP和消息传递。
• 每个微服务都应该拥有自己的数据存储区。
• 能够从事设计，Web开发，编码，数据库管理和操作的小团队。

source

Answer 7

微服务是一种软件架构样式，需要对应用程序进行功能分解。

通常，它涉及将一个整体应用程序分解为多个较小的服务，每个服务都部署在其自己的存档中，然后使用标准的轻量级通信（例如，基于HTTP的REST或一些异步通信）组成单个应用程序（当然，在某些时候，微服务是从头开始编写的）。

微服务中的“微”一词并不表示服务中的代码行，而仅表示范围仅限于单个功能。

每项服务都是完全自治和全栈的。因此，更改服务实现对其他服务使用定义良好的接口进行通信不会产生任何影响。这种应用程序有很多优点，但是它不是免费的午餐，需要在NoOps中付出很大的努力。

重要的是要注意，每个服务必须具有的属性：

• 单一目的-每个服务都应专注于一个单一目的并做到这一点。
• 松散耦合-服务彼此之间几乎一无所知。更改一项服务不应要求更改其他服务。服务之间的通信只能通过公共服务接口进行。
• 高内聚性—每个服务将所有相关行为和数据封装在一起。如果我们需要构建一项新功能，则所有更改都应仅本地化为一项服务。