微服务架构，在这种情况下什么是服务
Microservice architecture, what is a service in this case
我正在阅读一些关于微服务架构的文档（通过 this link for example），我想知道在这种情况下究竟什么是服务。
在 IT 中，一切都可以称为服务：
- 通过 java 命令启动的 SPRING REST 应用程序，例如：
java -jar build/libs/gs-rest-service-0.1.0.jar
- 也可以是一个类对应一个DDD中的业务层
- 它可能只是与研究领域相关的东西，比如向某人提供东西
- 和许多其他...（android 后台 运行 服务等...）
但是在微服务中，它是什么意思呢？例如，使用什么样的技术/工具在 Java EE 堆栈中创建 "service running by himself"？它只与网络服务有关？
没错，这就是微服务模型的美妙之处！例如，您可以在设计 Maven 多模块项目时开始考虑微服务。低耦合，明确的关注点分离，甚至可以是异步通信。当您更有信心将它们提取到应用程序中并 运行 在一个主机中时，下一步 - 运行 在不同的主机中。由你来决定它们应该如何部署，这与你想要实现的目标（容错与低延迟等）和你拥有的 DevOps 资源有关（因为更多的分离你需要更多的维护）。
关于 Java EE 堆栈 - 没什么特别的，只是通常的 jar 或 war 文件 运行ning 使用 java -jar 或像 Tomcat 这样的应用程序服务器。
另一个方向是使用像Docker + CoreOs / kubernetes / ..., Mesos + Marathon 等工具，但它们适用于微服务中的任何语言/框架。
编辑：
微服务可以结合使用同步（REST、SOAP）和异步协议（ActiveMQ、RabbitMQ 等消息队列）。由您决定如何组合它们。我的例子：labs.bench.co/2014/12/10/microservices-at-bench-intro
我自己的定义：
微服务是一个独立的、解耦的组件，它处理单个业务问题，并且可以从其他服务中使用。
其他人可能同意或不同意，关于这个话题有很多有趣的讨论，这使它成为软件工程师的一个很好的学习点。
从技术角度来看：
您几乎可以使用任何技术创建微服务：Java EE、Java + Spring、Python、Rails、Grails、Node.js 等等.据我所知，它似乎最常应用于网络应用程序和面向后端服务的生态系统领域。在你引用的文章中，Netflix模型是一个非常值得研究的东西，因为你可以深入地看到微服务架构的所有元素：服务发现、熔断、监控、动态配置等等。
如果你是 Java 导向的，你可能想检查一些东西：
Spring Cloud 允许您使用其中一些相同的 Netflix 组件，只需最少的手动编码：http://cloud.spring.io/spring-cloud-netflix/
一个关于github的实际操作示例（不是我的，但是我在自己学习该主题时使用过）：https://github.com/ewolff/microservice
从概念的角度来看，您的问题暗示了臭名昭著的微服务设计困境。微服务不一定有 "correct" 级别的粒度。这个想法是选择在您的业务领域内有意义的粒度级别。如果您以非常低的粒度级别（例如 CRUD 级别）实施微服务，那么您几乎肯定会以非常繁琐的服务告终，并且您可能必须在顶部构建更有意义的组合服务。如果您选择的粒度级别太高，您最终可能会得到一个更加单一的应用程序，稍后可能需要重构为微服务大小的部分。
之前的回答都很棒。
微服务架构只是一种功能分解设计。
我建议您阅读此博客 post : Microservice Design Patterns
从技术角度来看，像Docker (to run each microservice as a linux container) and Kubernetes to orchestrate them as a service (here is a Kubernetes sample)这样的工具有很多。
服务到微服务是Java是到Java脚本。不要那样想。相反，微服务可以被认为是：
- 一个小问题域。
- 自行构建和部署。
- 在自己的进程中运行。
- 通过众所周知的接口集成。
- 拥有自己的数据存储。
我将从你的最后一个问题开始 - 它只与网络服务有关？
这是有争议的。我会说，不。它与网络服务有关（但不仅限于此。）
Martin fowler 将微服务描述为 SOA 的一个小子集，毕竟微服务就是服务，而 SOA 是一个非常通用和广泛的学期。
以下是微服务的一些重要方面：
- 每个服务（或一组服务）都应该有自己的数据存储。
- 服务是围绕业务需求或功能组织的。
- 每个服务都是独立的，因此它们可以用任何语言实现。导致团队中的多语言编程文化。
- 服务可以接收来自客户端或其他服务的请求。
- 它们通常是事件驱动和异步的，因此扩展变得更容易。
- 服务很愚蠢，因为它们只做一件事（但它们应该足以自我监控）
- 它们有助于持续部署或交付，因为实施到部署的周期非常短。
它们非常小，因此部署它们不会产生太多网络开销。因此，它们可以在几分钟内部署到一个节点集群中。
此外，我想强调的是，以上内容不仅适用于微服务。 google、Netflix 和亚马逊等公司甚至在这个词被创造出来之前就已经在做类似的事情了。
微服务基本上是一个独立的流程，提供独特的单一业务功能。我们不创建 Web 微服务、业务逻辑微服务或数据库微服务。
为什么选择微服务？
- 微服务使我们的系统松散耦合，即如果我们需要更新、修复或替换微服务，我们不需要重新构建我们的整个应用程序，只需换掉需要它的部分即可。
- 构建每个微服务可以使用不同的语言和工具。微服务与定义良好的接口进行通信
- 为了可伸缩性（微服务的副本）和可靠性（一个副本失败另一个副本可以服务），通信应该是无状态的，微服务之间最常见的通信方法是 HTTP 和消息传递。
- 每个微服务都应该有自己的数据存储。
- 能够从事设计、Web 开发、编码、数据库管理和运营的小型团队。
微服务是一种软件架构风格，需要对应用程序进行功能分解。
通常，它涉及将一个整体应用程序分解为多个较小的服务，每个服务都部署在自己的存档中，然后使用标准的轻量级通信（例如基于 HTTP 的 REST 或一些异步通信（的当然，在某些时候微服务是从头开始编写的）。
微服务中的术语“微”并不表示服务中的代码行，它仅表示范围仅限于单一功能。
每项服务都是完全自主和全栈的。因此，更改服务实现不会影响其他服务，因为它们使用定义良好的接口进行通信。这种应用程序有几个优点，但它不是免费的午餐，需要在 NoOps 方面付出大量努力。
重要的是要注意每个服务必须具有的属性：
- 单一目的 — 每项服务都应专注于一个单一目的并做好。
- 松耦合——服务彼此了解甚少。对一项服务的更改不应要求更改其他服务。服务之间的通信只能通过 public 服务接口进行。
- 高内聚——每个服务将所有相关的行为和数据封装在一起。如果我们需要构建新功能，则所有更改都应本地化到一项服务。
我正在阅读一些关于微服务架构的文档（通过 this link for example），我想知道在这种情况下究竟什么是服务。
在 IT 中，一切都可以称为服务： - 通过 java 命令启动的 SPRING REST 应用程序，例如：
java -jar build/libs/gs-rest-service-0.1.0.jar
- 也可以是一个类对应一个DDD中的业务层
- 它可能只是与研究领域相关的东西，比如向某人提供东西
- 和许多其他...（android 后台 运行 服务等...）
但是在微服务中，它是什么意思呢？例如，使用什么样的技术/工具在 Java EE 堆栈中创建 "service running by himself"？它只与网络服务有关？
没错，这就是微服务模型的美妙之处！例如，您可以在设计 Maven 多模块项目时开始考虑微服务。低耦合，明确的关注点分离，甚至可以是异步通信。当您更有信心将它们提取到应用程序中并 运行 在一个主机中时，下一步 - 运行 在不同的主机中。由你来决定它们应该如何部署，这与你想要实现的目标（容错与低延迟等）和你拥有的 DevOps 资源有关（因为更多的分离你需要更多的维护）。
关于 Java EE 堆栈 - 没什么特别的，只是通常的 jar 或 war 文件 运行ning 使用 java -jar 或像 Tomcat 这样的应用程序服务器。
另一个方向是使用像Docker + CoreOs / kubernetes / ..., Mesos + Marathon 等工具，但它们适用于微服务中的任何语言/框架。
编辑：
微服务可以结合使用同步（REST、SOAP）和异步协议（ActiveMQ、RabbitMQ 等消息队列）。由您决定如何组合它们。我的例子：labs.bench.co/2014/12/10/microservices-at-bench-intro
我自己的定义：
微服务是一个独立的、解耦的组件，它处理单个业务问题，并且可以从其他服务中使用。
其他人可能同意或不同意，关于这个话题有很多有趣的讨论，这使它成为软件工程师的一个很好的学习点。
从技术角度来看： 您几乎可以使用任何技术创建微服务：Java EE、Java + Spring、Python、Rails、Grails、Node.js 等等.据我所知，它似乎最常应用于网络应用程序和面向后端服务的生态系统领域。在你引用的文章中，Netflix模型是一个非常值得研究的东西，因为你可以深入地看到微服务架构的所有元素：服务发现、熔断、监控、动态配置等等。
如果你是 Java 导向的，你可能想检查一些东西：
Spring Cloud 允许您使用其中一些相同的 Netflix 组件，只需最少的手动编码：http://cloud.spring.io/spring-cloud-netflix/
一个关于github的实际操作示例（不是我的，但是我在自己学习该主题时使用过）：https://github.com/ewolff/microservice
从概念的角度来看，您的问题暗示了臭名昭著的微服务设计困境。微服务不一定有 "correct" 级别的粒度。这个想法是选择在您的业务领域内有意义的粒度级别。如果您以非常低的粒度级别（例如 CRUD 级别）实施微服务，那么您几乎肯定会以非常繁琐的服务告终，并且您可能必须在顶部构建更有意义的组合服务。如果您选择的粒度级别太高，您最终可能会得到一个更加单一的应用程序，稍后可能需要重构为微服务大小的部分。
之前的回答都很棒。 微服务架构只是一种功能分解设计。
我建议您阅读此博客 post : Microservice Design Patterns
从技术角度来看，像Docker (to run each microservice as a linux container) and Kubernetes to orchestrate them as a service (here is a Kubernetes sample)这样的工具有很多。
服务到微服务是Java是到Java脚本。不要那样想。相反，微服务可以被认为是：
- 一个小问题域。
- 自行构建和部署。
- 在自己的进程中运行。
- 通过众所周知的接口集成。
- 拥有自己的数据存储。
我将从你的最后一个问题开始 - 它只与网络服务有关？ 这是有争议的。我会说，不。它与网络服务有关（但不仅限于此。）
Martin fowler 将微服务描述为 SOA 的一个小子集，毕竟微服务就是服务，而 SOA 是一个非常通用和广泛的学期。
以下是微服务的一些重要方面：
- 每个服务（或一组服务）都应该有自己的数据存储。
- 服务是围绕业务需求或功能组织的。
- 每个服务都是独立的，因此它们可以用任何语言实现。导致团队中的多语言编程文化。
- 服务可以接收来自客户端或其他服务的请求。
- 它们通常是事件驱动和异步的，因此扩展变得更容易。
- 服务很愚蠢，因为它们只做一件事（但它们应该足以自我监控）
- 它们有助于持续部署或交付，因为实施到部署的周期非常短。
它们非常小，因此部署它们不会产生太多网络开销。因此，它们可以在几分钟内部署到一个节点集群中。
此外，我想强调的是，以上内容不仅适用于微服务。 google、Netflix 和亚马逊等公司甚至在这个词被创造出来之前就已经在做类似的事情了。
微服务基本上是一个独立的流程，提供独特的单一业务功能。我们不创建 Web 微服务、业务逻辑微服务或数据库微服务。
为什么选择微服务？
- 微服务使我们的系统松散耦合，即如果我们需要更新、修复或替换微服务，我们不需要重新构建我们的整个应用程序，只需换掉需要它的部分即可。
- 构建每个微服务可以使用不同的语言和工具。微服务与定义良好的接口进行通信
- 为了可伸缩性（微服务的副本）和可靠性（一个副本失败另一个副本可以服务），通信应该是无状态的，微服务之间最常见的通信方法是 HTTP 和消息传递。
- 每个微服务都应该有自己的数据存储。
- 能够从事设计、Web 开发、编码、数据库管理和运营的小型团队。
微服务是一种软件架构风格，需要对应用程序进行功能分解。
通常，它涉及将一个整体应用程序分解为多个较小的服务，每个服务都部署在自己的存档中，然后使用标准的轻量级通信（例如基于 HTTP 的 REST 或一些异步通信（的当然，在某些时候微服务是从头开始编写的）。
微服务中的术语“微”并不表示服务中的代码行，它仅表示范围仅限于单一功能。
每项服务都是完全自主和全栈的。因此，更改服务实现不会影响其他服务，因为它们使用定义良好的接口进行通信。这种应用程序有几个优点，但它不是免费的午餐，需要在 NoOps 方面付出大量努力。
重要的是要注意每个服务必须具有的属性：
- 单一目的 — 每项服务都应专注于一个单一目的并做好。
- 松耦合——服务彼此了解甚少。对一项服务的更改不应要求更改其他服务。服务之间的通信只能通过 public 服务接口进行。
- 高内聚——每个服务将所有相关的行为和数据封装在一起。如果我们需要构建新功能，则所有更改都应本地化到一项服务。