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

Question

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

单体架构带来了一些问题：

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

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

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

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

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

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

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

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

Answer 1

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

根据以上信息，我的想法是：

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

• 通信 -使用 MSA，服务之间的通信成为关键，因此一般做法是保持面向消息的通信方法（阅读有关反应式系统和反应式编程的更多信息）。

• PaaS 解决方案 -有多种 PaaS 解决方案可供您应用，这样您就不必担心容器管理、容器编排、自动扩展、配置管理、日志管理和监控等所有其他方面。请参阅以下内容PaaS解决方案：

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

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

• https://openshift.io - 由 RedHat 提供

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

希望这些指针将有助于理解整体格局，以便您可以构建您的架构以满足未来的需求。