Question

我有多模块应用程序。更明确的是，这些是maven模块，其中高级模块依赖于低级模块。以下是一些模块： -

    user-management
    common-services
    utils
    emails

例如： - 如果user management模块想要使用来自utils模块的任何服务，它可以调用其服务，因为utils的依赖已经注入了用户管理。要真正按照微服务器架构转换/调用我的项目，我相信我需要将每个模块转换为可独立部署的服务，其中每个模块都是一个war模块并通过http提供其服务（主要是作为非常好的Web服务）。这是正确的还是其他任何事情都需要照顾？

现在可能每个模块都必须是安全的和身份验证层吗？

如果那是微服务的关键，我真的不明白当有人问你是否曾在微服务上工作时它不是工具/平台/框架而是一个简单的概念将您的单片应用程序划分为较小的可部署模块集，这些模块的服务可通过HTTP获得。不是吗？可能是另一个流行词。

更新： - 很显然，微服务的方式就像独立的单元testablemodule一样，可扩展，因为它可以部署在单独的机器上，松耦合等，但我看到我需要处理两个复杂的问题

身份验证： - 对于每个模块，我需要确保它对现在不是这种情况的请求进行身份验证
交易： - 我无法维持目前我可以轻松完成的不同服务的交易原子性

Answer 1

你所拥有的东西大多是正确的，但你似乎正在考虑某些事情作为要求，而你却忘记了微服务应该具备的一个非常重要的特征。

微服务的主要特征是 无状态 和独立性。无论他们是＆＃34; WAR＆＃34;模块以及它们是否通过＆＃34; HTTP＆＃34;提供服务。（当然它们是否是RESTful）是次要问题，你可能会听到相反的论点。

无国籍状态意味着没有单独的微服务可能包含状态。（除了缓存之外。）微服务应该始终将持久化数据的任务委托给某个数据库模块，这样它们就不会将任何状态保留在内存中。这样的想法是，如果一个微服务失败，（或者如果整个机器包含许多微服务失败），你可以将传入的请求路由到另一个实例（或另一台机器），一切都将继续工作。

（当然，如果你想要我的意见，这只是一个懦弱的认识，我们不知道如何编写可靠的高度并发软件，但数据库人员很聪明，他们似乎已经想到了全部，所以我们只是将维护我们的状态的问题委托给他们编写的软件。）

Answer 2

在我看来，微服务架构与DDD结合良好

我认为您应该将您的多模块项目视为“整体”，并根据域概念而不是maven项目进行微服务分离。

例如：不要创建一个名为“utils”的微服务，而是创建一个名为“accounts”或“user-management”的微服务或者你的域名。我认为如果没有域驱动的开发，它就会失去它的用处。

之后很容易在域的不同方面工作，知道它被其余部分分开。你应该看看Alistair Cockburn的六角形建筑

Answer 3

如何拆分应用程序取决于您拥有的模块类型。如果模块包含业务逻辑，那么创建新服务并通过Http或Messaging进行通信是有意义的。另一方面，如果您的模块没有业务逻辑，但只有一组辅助函数可能更好地将其提取到单独的公共/私有maven包中，并将其用作依赖项。

是的，microservice是最近流行的热门话题，但一个概念已经存在了一段时间。但它还带来了更多。虽然它提供了扩展和独立服务部署的好处，但它带来了管理和编排大量服务的复杂性。

例如，在monolith应用程序中，当您只是从另一个模块调用一个函数时，您确定它始终可用于调用。对于微服务，由于中断或部署，某些服务可能会停止运行，在这种情况下，您必须考虑优雅地处理这些情况（例如，应用circuit breaker模式）。

在进行微服务时还有许多其他事项要考虑，有很多关于这个主题的文献。我从Nginx上读到了Microservices: From Design to Deployment。这简短又甜蜜。

所以，当人们问你Have you worked with microservices before?时，我想他们想知道你是否熟悉并且对这个概念的所有陷阱都有一些经验。

Answer 4

你所理解的是非常好的，你找到了微服务变得越来越复杂的正确区域（分布式事务），但让我澄清一些关于微服务的观点。

微服务并不意味着通过HTTP公开的独立服务：微服务可以以同步或异步方式与其他服务进行通信，因此REST是解决方案之一，它是适用的对于同步通信，你可以像使用Kafka或hornetq等消息驱动一样执行异步通信。在同步通信中，底层服务也可以调用Thrift协议。
SRP之后的微服务：微服务的优点在于每个服务只集中在一个业务域用例上，因此它只处理一个域对象的功能。但是utils模块是常用的方法，因此每个微服务都依赖于它。因此，即使utils模块中的一个小变化也需要构建所有其他微服务，因此它违反了微服务12原则，因此解散了utils服务并使其与每个服务一致。
处理身份验证：具体而言，微服务可以是以下三种类型之一：
一个。 核心服务 ：只需执行域操作（如创建/更新/删除帐户）
湾 聚合服务 ：调用一个或多个核心服务，收集结果并对其执行一些操作。
C。 边缘服务 ：暴露给客户端（如移动/浏览器等）。我们有时称它为网关服务;这项服务的关键是接受用户请求，并根据URL将其转发给实际的微服务。因此，如果它对所有微服务都很常见，那么它是进行身份验证的理想场所。
处理分布式事务：是的，这是微服务中最难的部分，但您可以通过事件驱动/消息驱动的方式实现它。每个动作都会弹出一个事件;该事件的订阅者接收该操作并执行某些操作并生成另一个事件。如果失败，它会生成一个反向事件，用于补偿创建的第一个事件。

例如，从micoservice A说，我们扣除了100卢比，因此创建了一个AccountDebited事件。现在在微服务B中我们尝试将该账户存入账户。如果成功，我们会创建一个由A收到的AccountCredited并创建另一个事件AmountTransfered。如果失败，我们会生成一个AccountCreditedFailed事件，该事件由A接收并生成一个反向事件 - AccountSpecialCredit - 它保持原子性。

Answer 5

在某种程度上，你是正确的，在外面的微服务中它看起来像这样。当你进入内部时，你正确地提到了两个复杂的问题：

身份验证： - 对于每个模块，我需要确保它对请求进行身份验证（现在不是这种情况）

交易： - 我无法维持不同服务的交易原子性，而目前我可以很容易地做到这一点

除此之外，有许多事情需要了解，否则做和部署微服务将是非常艰难的：

我在这里提到其中一些，你可以从我的帖子中看到完整列表：

微服务究竟是什么？有人说它不应该超过1000行代码。有人说它应该适合一个有界的上下文（如果你不知道有限的上下文是什么，现在就不要理会它;继续阅读）。
甚至在决定什么是“微服务”之前，服务究竟是什么？
微服务不允许一次更新多个实体;我如何保持实体之间的一致性？
我的所有微服务都应该有一个数据库集群吗？
每个人都在谈论什么是最终的一致性？
如何整理由驻留在不同服务中的多个实体组成的数据？
如果一项服务出现故障会怎样？依赖服务的行为如何？
我是否应该在微服务之间进行同步调用以始终获得一致的数据？
如何管理几个或所有微服务的版本升级？是否总能在没有停机的情况下完成这项工作？
最后一个不可避免的问题 - 如何将整个应用程序作为集成应用程序进行测试？
- 断路怎么办？（如果一项服务不应影响其他服务）
- CI / CD管道和.......

我们在开始微服务之旅时所理解的是：

微服务中破坏业务问题的设计模式是域驱动设计
支持微服务开发的平台。（我们使用了Lagom），它解决了上面提到的一些问题

所以在迈向多个流程拱的过程中。使用Rest或其他方法进行通信时，需要注意新的注意事项，这些注意事项在Monolithic中并不直接可见，人们想知道您是否了解这些注意事项。

将多模块项目迁移到微服务？

5 个答案: