我正在开发一个整体系统。它的所有代码都位于一个存储库中(Web API 和后台工作人员)。系统采用Nodejs编写，并使用MongoDB(Mongoose)作为数据存储。我的目标是设定项目如何发展的新路径。起初我想知道我是否可以转向基于微服务的架构。
单体架构产生了一些问题:
- 如果我的后台工作人员需要扩展。我必须将所有项目部署到服务器，尽管只使用了其中的一小部分。
- 代码更改时必须重新部署所有系统。如果在系统重新部署时支付处理器调用 webhook 会怎样？
使用微服务的优势非常明显:
- 单个微服务的代码库更小。更容易推理。
- 能够选择最适合特定用例的编程工具。
- 更容易扩展。
查看当前代码，我注意到整个项目都使用 Mongoose ODM(对象文档映射器)模型来创建、查询和更新数据库中的模型。作为良好编程的原则，所有与数据库的交互都应该被抽象。业务逻辑不应泄漏到其他系统层。我可以通过引入存储库模式(领域驱动设计)来做到这一点。虽然代码仍然在 Web API 及其后台工作人员之间共享，但这并不是一项艰巨的任务。
如果我决定将存储库提取到独立的微服务中，则会出现所有问题:
- 必须引入某种查询语言来适应复杂的搜索查询。
- 界面必须提供一种迭代搜索结果的方法(基于光标的导航)，而无需通过网络返回所有数据库文档。
由于项目还处于早期阶段，而且我是唯一的开发人员，因此采用基于微服务的架构似乎有些矫枉过正。也许我应该考虑其他方法？
将业务逻辑和与数据库的交互提取到单独的存储库中并在服务之间共享，以避免服务之间复杂的通信协议(protocol)？
最佳答案
根据我过去几年在微服务方面的工作经验，这在当前情况下似乎有些过分，但从长远来看是值得的。
根据上述信息，我的想法是:
- 代码结构 - 微服务架构(MSA)应用于上述环境意味着不分离 DAO、业务逻辑等，而是更多地根据业务功能设计系统。例如，如果是电子商务应用程序，那么您可以将运输、购物车、搜索作为单独的服务，这些服务还可以进一步划分为更小的服务。阅读有关领域驱动设计的更多信息 here .
- 部署单元 -将微服务应用保持为独立的部署单元是一项关键原则。因此，保留应用程序的垂直切片，并将它们打包为包含应用程序代码、应用程序服务器(如果有)、数据库和操作系统(Linux 等)的 Docker 镜像
通信 - 对于 MSA，服务之间的通信成为关键，因此一般做法是继续采用面向消息的通信方法(阅读 reactive system and reactive programming 以获取更多见解) .
PaaS 解决方案 - 有多种可用的 PaaS 解决方案可供您应用，这样您就无需担心所有其他方面，例如容器管理、容器编排、自动化扩展、配置管理、日志管理和监控等。请参阅以下 PaaS 解决方案:
https://www.nanoscale.io/由 TIBCO 提供
https://fabric8.io/ - 由红帽
https://openshift.io - 由红帽
云供应商平台 -AWS、Azure 和 Google Cloud 从部署角度来看都对微服务应用程序提供特定支持，如果您不这样做，我们可以将其用作替代解决方案希望在您的组织中部署 PaaS 解决方案。
希望这些指导能够帮助您了解整体情况，以便您可以根据 future 的需要构建您的架构。
关于node.js - 我应该转向基于微服务的架构吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46949073/