12

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

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

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

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

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

4

7 回答 7

1

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

我建议你阅读这篇博文：微服务设计模式

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

于 2015-04-12T19:08:31.733 回答
1

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

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

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

编辑：

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

于 2015-04-12T17:16:35.320 回答
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

从概念的角度来看，您的问题暗示了一个臭名昭著的微服务设计困境。微服务不一定有“正确”的粒度级别。这个想法是选择在您的业务领域内有意义的粒度级别。如果您以非常低的粒度级别（例如 CRUD 级别）实现微服务，那么您几乎可以肯定最终会得到非常繁琐的服务，并且您可能必须在上面构建更有意义的复合服务。如果您选择太高的粒度级别，您最终可能会得到一个更加单一的应用程序，这可能需要稍后重构为微服务大小的部分。

于 2015-04-12T17:23:30.120 回答
1

我将从您的最后一个问题开始-它仅与网络服务有关吗？ 这是值得商榷的。我会说，不。它与网络服务有关（但不仅与它有关。）

Martin fowler 将微服务描述为SOA 的一个小子集，毕竟微服务是服务，而 SOA 是一个非常通用和宽泛的术语。

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

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

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

    另外，我想强调的是，以上不仅适用于微服务。谷歌、Netflix 和亚马逊等公司甚至在这个词出现之前就已经在做类似的事情了。

于 2016-07-07T06:58:44.363 回答
0

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

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

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

每个服务都是完全自治的和全栈的。因此，更改服务实现不会影响其他服务，因为它们使用定义良好的接口进行通信。这种应用程序有几个优点，但它不是免费的午餐，需要在 NoOps 方面付出大量努力。

重要的是要关注每个服务必须具有以下属性：

  • 单一目的——每项服务都应该专注于一个单一的目的并做好。
  • 松散耦合——服务之间对彼此知之甚少。对一项服务的更改不应要求更改其他服务。服务之间的通信只能通过公共服务接口进行。
  • 高内聚——每个服务都将所有相关的行为和数据封装在一起。如果我们需要构建一个新功能，所有的更改都应该本地化到一个单一的服务。
于 2019-08-01T12:15:27.957 回答
0

服务到微服务就是 Java 就是 JavaScript。不要那样想。相反，微服务可以被认为如下：

  1. 一个小问题域。
  2. 自行构建和部署。
  3. 在自己的进程中运行。
  4. 通过众所周知的接口进行集成。
  5. 拥有自己的数据存储。
于 2016-06-14T17:48:45.257 回答
0

微服务基本上是一个自包含的流程，提供独特的单一业务能力。我们不创建 Web 微服务、业务逻辑微服务或数据库微服务。

为什么是微服务？

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

资源

于 2018-04-15T07:19:56.073 回答