我应该转向基于微服务的架构吗？

Question

我正在开发一个整体系统。它的所有代码都在一个存储库中（Web API 和后台工作人员）。系统是用 Nodejs 编写的，MongoDB (Mongoose) 用作数据存储。我的目标是为项目的发展设定一条新路径。起初我想知道我是否可以转向基于微服务的架构。

单体架构会产生一些问题：

• 如果我的后台工作人员需要扩展。尽管只使用了其中的一小部分，但我必须将所有项目部署到服务器。
• 代码更改时必须重新部署所有系统。如果在重新部署系统时支付处理器调用 webhook 怎么办？

使用微服务的优势非常明显：

• 单个微服务的代码库更小。更容易推理。
• 能够选择最适合特定用例的编程工具。
• 更易于扩展。

查看当前代码，我注意到 Mongoose ODM（对象文档映射器）模型在所有项目中用于创建、查询和更新数据库中的模型。作为一个好的编程原则，所有这些与数据库的交互都应该被抽象出来。业务逻辑不应泄漏到其他系统层。我可以通过引入存储库模式（域驱动设计）来做到这一点。虽然代码仍然在 web api 和后台工作人员之间共享，但这并不是一项艰巨的任务。

如果我决定将存储库提取到独立的微服务中，那么就会出现所有问题：

• 必须引入某种查询语言来适应复杂的搜索查询。
• 接口必须提供一种在不通过网络返回所有数据库文档的情况下迭代搜索结果（基于光标的导航）的方法。

由于项目处于早期阶段，并且我是唯一的开发人员，因此使用基于微服务的架构似乎有点过头了。也许我应该考虑其他方法？

将业务逻辑和与数据库的交互提取到单独的存储库中并在服务之间共享以避免服务之间复杂的通信协议？

Answer 1

根据我过去几年在微服务领域工作的经验，在当前情况下这似乎是一种矫枉过正，但从长远来看是有回报的。

基于以上信息，我的想法是：

• 代码结构-微服务架构（MSA）应用在上述上下文中意味着不分离DAO，业务逻辑等，而是更多地根据业务功能设计系​​统。例如，如果它是一个电子商务应用程序，那么您可以将运输、购物车、搜索作为单独的服务，这些服务可以进一步细分为更小的服务。阅读有关领域驱动设计的更多信息here。
• 部署单元 - 将微服务应用程序保持为独立的部署单元是一项关键原则。因此，保留应用程序的垂直切片并将它们打包为带有应用程序代码、应用程序服务器（如果有）、数据库和操作系统（Linux 等）的 Docker 映像

• 通信 - 使用 MSA，服务之间的通信成为关键，因此一般做法是保持面向消息的通信方法（阅读reactive system and reactive programming 以获得更多信息） .

• PaaS 解决方案 - 有多种 PaaS 解决方案可供您应用，您无需担心容器管理、容器编排、自动扩展、配置管理、日志管理和监控等。请参阅以下 PaaS 解决方案：

• https://www.nanoscale.io/ by TIBCO

• https://fabric8.io/ - 来自 RedHat

• https://openshift.io - 来自 RedHat

• 云供应商平台 - AWS、Azure 和 Google Cloud 从部署的角度来看，它们都对微服务应用程序提供特定支持，如果您不这样做，我们可以将其用作替代解决方案希望在您的组织中部署 PaaS 解决方案。

希望这些建议能够帮助您了解整体情况，以便您可以根据未来需要构建架构。

Answer 2

我正在开发一个单体系统...我的目标是为项目的发展设定一条新路径。起初我想知道我是否可以转向基于微服务的架构。

您需要以哪些方式发展项目？主要是错误修复、添加功能、提高性能和/或可扩展性吗？您预计未来会有其他开发者合作吗？您目前有维护问题吗？在指导您的选择时应考虑这些问题（以及更多问题）的答案。

您似乎正在围绕微服务架构的优缺点做功课，所以如果您一开始还没有问自己为什么要这样做，那么现在是这样做的好时机。

也许我应该考虑其他方法？

总是有美好的旧事物，不要破坏，这是怎么回事；）