在微服务中划分系统的依据是什么条件？微服务应该有多小的规模？
答案 0 :(得分：1)
我们在多个项目中实施微服务架构，我 会尝试与他们分享我的经验以及我们如何去做。
首先让我解释一下我们如何将域划分为微服务。在此期间 还将解释微服务的大小标准。为了 了解我们需要了解整个方法：
我们将系统划分为微服务的条件：
我们根据两组环境拆分微服务：
仅考虑制作/登台设置：
基于DDD（域驱动设计）有界上下文： 绑定上下文= 1微服务。 这是我们最终拥有的最大的女士。大多数时候 绑定的上下文也被拆分为多个微服务。 为什么？ 原因是我们的领域很大，因此保留了整个有界上下文 因为一项微服务效率很低。效率低下，我主要是指扩大规模的原因，但是 还进行开发扩展（由较小的团队负责一项微服务）和其他一些原因 以及。
CQRS（命令查询隔离原理）： 在划分为每个绑定上下文的micros服务或每个1个绑定上下文为多个微服务之后 对于其中的一些微服务，我们将它们分为2个或更多的微服务，而不是1个。一个命令/写入微服务，第二个是读取/查询微服务。 例如 假设您拥有“用户微服务”和“用户读取微服务”。 “用户微服务”负责 创建，更新，删除和一般管理用户。另一方面，“用户读取微服务”只是负责 用于检索用户（它是只读的）。我们遵循CQRS模式。
在某些极端情况下，写入/域微服务具有多个读取微服务。有时这些Read-micro-service很小，以至于它们只有一个非规范化视图 表示主要使用某种No-SQL db进行快速访问。在某些情况下，它是如此之小，以至于 从代码预期的角度来看，它将只有几个C＃/ Java类以及1,2个表或JSON集合 在他们的数据库中。
提供域不可知或静态工作或服务的服务
示例1是一个非常小的微服务，负责生成 来自html模板的pdf形式的特定报告。
示例2是一个微服务，它只是向一些特定用户发送简单的文本消息 根据他们的权限。
考虑开发设置：
除了用于本地开发/运行目的的生产/登台设置之外，我们还需要 特殊的微服务，它们会做一些工作以使本地设置工作。 本地设置使用docker（docker-compose）完成。 小型微服务的例子有：
数据库，缓存，身份，Api网关和文件存储。 对于生产/分阶段设置中的所有这些事情，我们在这里使用云提供商 为这些东西提供服务，因此我们不需要将它们引入微服务。 但是为了使整个系统运行以进行开发/测试，我们需要 以Docker容器的形式创建小型微服务以替换这些云服务。
将测试/播种数据添加到系统中。 为了向微服务的本地开发系统提供数据，我们需要一个 小型微服务，其唯一目的是调用微服务公开的某些API，并且 向其中发布一些数据。 这样，我们可以使用预定义的数据来设置一个有效的开发环境，以便进行测试 一些简单的业务场景。
这样做的好处是，您可以结合使用本测试数据设置和本地 用于创建集成和端到端测试的开发设置。
微服务应该有多小？
在我们的案例中，最小的微服务包括 仅具有一个非规范化视图（1个表或1个JSON集合）的视图/只读mircro服务，这些代码来自预期代码 其中有几个C＃/ Java类。因此，当涉及到代码时，我认为不会那么小 是一个合理的选择。同样，这是主观的观点。 根据有关微服务的一些建议，此大小可以认为“太小” 您可以在线阅读有关内容。我们这样做是因为它帮助我们解决了性能问题。 对该数据的需求如此之大，以至于我们将其隔离开来，以便我们可以对其进行独立扩展。 这使我们有可能根据其需求并独立地扩展此微服务/视图 来自该域的其余部分。
小型微型服务的第二种情况是html-to-pdf服务，该服务只是基于pdf文件创建 在特定格式的html模板上。您可以想象这个功能子集有多小。
建议：
我对每个设计微服务的人的建议是提出正确的问题：
微服务的规模应该有多大，以便我们不存在将整体拆分为多个整体的情况？ 这意味着创建的微服务的规模太大且难以管理，因为这是问题所在 巨石。最重要的是，您会发现分布式系统的弊端。
微服务的规模会影响您的性能吗？ 对于您的客户而言，关键是系统性能良好，因此考虑 微服务系统体系结构的标准可能是非常有效的观点。
我们应该还是应该提取功能/逻辑的某些关键部分以将其隔离？ 哪个关键逻辑是如此重要，以至于您无法承受它的崩溃或服务中断 为了它？ 这样，您可以保护系统中最关键的部分。
我可以组织具有这种微服务架构拆分的团队吗？
考虑到我已经完成了微服务架构，而我又拥有了“ n”个微服务 我将如何管理它们？这意味着支持他们，安排部署，根据需要进行扩展， 显示器等等？ 如果您提出的这种架构对您来说是具有挑战性且不可管理的 组织或团队，然后重新考虑他们。没有人需要一个难以管理的系统。
还有更多可能将您引向正确方向的信息，但这些都是我们遵循的方向。
这些问题的答案将自动带您到最小/最大的微型服务 为您的域/业务。我上面关于微服务规模的示例现在可能适用于您的情况 以及我们在哪里使用的规则，但回答这些问题将使您更接近自己 自己决定的方法/规则。
结论
微服务应尽可能小，以满足您的需求。名称“微”表示它们可能很小。 注意不要将此规则作为整个系统的规则。 最小的微服务是解决某些特定问题（例如扩展或 关键逻辑隔离，而不是在这样规模的微服务中设计/拆分整个系统的规则。 如果为了拥有微型微服务而必须拥有许多非常小的微服务，那么您将很难 没有真正的好处来管理他们。小心分开。