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

Question

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

Monolith架构会产生一些问题：

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

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

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

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

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

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

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

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

Answer 1

根据我过去几年在微服务部门工作的经验，在当前的情况下看起来似乎有点过头了但是长期回报。

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

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

• 通信 - 使用MSA，服务之间的通信成为关键，因此通常的做法是继续使用面向消息的通信方法（阅读reactive system and reactive programming了解更多信息洞察力）。

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

TIBCO的

• https://www.nanoscale.io/

• https://fabric8.io/ - RedHat

• https://openshift.io - RedHat

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

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

Answer 2

  

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

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

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

  

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

总是有一个好的旧的不打破什么去;）