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

【问题标题】：Microservice architecture, what is a service in this case微服务架构，这种情况下什么是服务
【发布时间】：2015-06-17 23:24:00
【问题描述】：

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

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

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

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

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

【问题讨论】：

查看关于微服务的精彩解释、挑战和解决方案youtube.com/watch?v=CriDUYtfrjs

标签： java web-services rest microservices

【解决方案1】：

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

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

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

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

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

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

【讨论】：

【解决方案2】：

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

为什么选择微服务？

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

source

【讨论】：

【解决方案3】：

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

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

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

每个服务（或少数几个）都应该有自己的数据存储。
服务是围绕业务需求或功能组织的。
每个服务都是独立的，因此它们可以用任何语言实现。导致团队中的多语言编程文化。
服务可以接受来自客户端或其他服务的请求。
它们通常是事件驱动和异步的，因此扩展变得更容易。
服务是愚蠢的，因为它们只做一件事（但它们应该能够自给自足地监控自己）
它们有助于持续部署或交付，因为实施到部署周期非常小。
它们非常小，因此在部署它们时没有太多的网络开销。因此，它们可以在几分钟内跨节点集群部署。

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

【讨论】：

【解决方案4】：

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

一个小问题域。
自行构建和部署。
在自己的进程中运行。
通过众所周知的接口进行集成。
拥有自己的数据存储。

【讨论】：

【解决方案5】：

我自己的定义：

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

其他人可能同意或不同意，关于这个话题有很多有趣的讨论，这使它成为软件工程师的一个很好的研究点。

从技术角度： 您可以使用几乎任何技术创建微服务：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 级别）实现微服务，那么您几乎肯定会以非常健谈的服务告终，并且您可能必须在上面构建更有意义的复合服务。如果您选择的粒度级别太高，您最终可能会得到一个更加单一的应用程序，这可能需要稍后重构为微服务大小的部分。

【讨论】：

组件的组合呢？喜欢用户管理和计费管理？一个与另一个相关，但服务必须解耦。在这种情况下如何将代码拆分为尊重微服务概念的可行微服务？
正如 Francois 的链接中提到的，一种技术是实现用户管理和计费管理服务，然后将这些服务与另一个服务放在一起，以根据需要聚合它们的行为。在某种程度上，关于什么是/不是服务的一部分的决定归结为您的应用程序的使用和个人关注的完整性之间的权衡。这是微服务设计固有的挑战。

【解决方案6】：

没错，这就是微服务模型的美妙之处！例如，您可以在设计 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

【讨论】：

我的意思是：rest 和 soap 是创建微服务的唯一方法吗？
通常你有同步（REST、SOAP）和异步协议（像ActiveMQ、RabbitMQ等消息队列）的组合。再次由您决定如何组合它们。我的例子：labs.bench.co/2014/12/10/microservices-at-bench-intro
这意味着如果我用 java 编码两个微休息服务，我必须创建两个不同的战争文件来放入我的网络服务器？无状态认证呢？是否存在其他人使用的前台服务（身份验证管理）？
是的，两个不同的战争文件。关于无状态身份验证——这不是关于微服务的问题，更多的是关于实现的问题。 Spring Security 支持它，您可以使用诸如 Tomcat 集群支持之类的东西来共享会话 - tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
另一种方式是将security/auth中间件实现为库，并在所有微服务中使用。

【解决方案7】：

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

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

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

【讨论】：