微服务和模块化架构设计的权衡？

Question

Microservices 和Modular Programming 已被证明是设计软件系统时的正确选择。它的好处包括可重用性、可分发性、可读性等。

我们是一个使用 OSGI 作为模块化实现的 MOOC 网站：

• 每个功能都有自己的数据库、服务和独立的 Web 应用程序
• 禁止直接访问其他功能的数据库

以3个特征为例：

     course               project         Q&A(question&answer)

+---------------+    +---------------+    +---------------+
|     web       |    |     web       |    |     web       |
|               |    |               |    |               |
+---------------+    +---------------+    +---------------+
|     service   |    |     service   |    |     service   |
|               |    |               |    |               |
+---------------+    +---------------+    +---------------+
|     dao       |    |     dao       |    |     dao       |
|               |    |               |    |               |
+---------------+    +---------------+    +---------------+
|     Database  |    |     Database  |    |     Database  |
|               |    |               |    |               |
+---------------+    +---------------+    +---------------+

要求：

1. 每个课程/项目都有问答模块，参与的用户可以在这里提问有关该课程/项目的问题。
2. 一个独立的全局（或通用）问答条目，列出了从所有课程/项目中汇总的问题，用户可以在此处提出与上下文无关（即与任何课程/项目无关）的问题。

我不知道这种设计或架构（每个功能从上到下完全隔离）好不好，但我确实面临一些不便：

1. 模块化网络应用程序

   问答功能既是独立功能，也是课程/项目的一部分。目前我认为将 Q&A 模块嵌入为独立 course-webapp/project-webapp 的 web 组件和独立 qa-webapp 本身，但我不知道重用控制器以避免 web 层上重复代码的最佳方法是什么

2. 理性数据库Polymorphic Association问题

   一个问题可能属于课程/项目，或者与上下文无关，并且课程/项目的 id 来自另一个数据库，多态关联是不可避免的。目前我在表格问题上使用额外的列 post_to_type 来解决这个问题。

3. 让我说课程/项目可以是私人的或公共的。全球问答条目下列出的问题仅包括属于公共课程/项目的问题，不包括私人问题。但是同样，由于每个功能都有自己的数据库，并且禁止直接访问其他功能的数据库，我不知道处理这个问题的优雅和有效的方法是什么。

在使用 OSGI 时，我们的模块化设计是否有问题，或者只是我认为对此感到不舒服？以及设计微服务/模块化架构的最佳实践是什么，特别是在 Java 等面向对象的语言中？

谢谢！

Answer 1

微服务应该围绕有界上下文构建，这可能与您在此处所说的特性一致，但也可能不符合；）找到边界是一项棘手且困难的任务，如果没有完整的内容，几乎不可能正确完成你系统的上下文。其他人可以根据自己的经验提供提示或分享见解，但无论您的模型是否正确，都无法为您提供答案。也不要太担心“正确”，肯定有几种方法可以构建你的代码，所有这些都可能有用。因此，请专注于使模型有用并解决任何问题（例如，代码变得难以维护、沟通过于冗长等）。

his book 中的 Sam Newman 建议从粗粒度有界上下文开始，如果将来需要，可以将其拆分为更小的上下文。他还有一个非常好的章节，谈到将单体应用拆分为服务。即使你正在从事一个新项目，我建议你看看他的书，以及其他人关于将单体应用程序分解为微服务的帖子和讨论。在我看来，这是了解如何找到这些界限、人们犯了什么错误以及如何改正错误的最佳方式。

我还建议您查看 Simon Brown 的“模块化单体”演示文稿。微服务并不是模块化的唯一选择，Simon 在那里分享了有用的见解。