微服务应该有多小? [英] How small a micro service should be?
问题描述
在微服务中划分系统的条件是什么?微服务应该有多小"?
Which are the conditions based on which a system should be split in micro-services and how "small" should a micro service be?
推荐答案
我们在多个项目中实现微服务架构，而我 会尝试与他们分享我的经验以及我们在哪里做.
We where implementing micro-services architecture in multiple projects and I will try to share my experience with them and how we where doing it.
首先让我解释一下我们如何将域划分为微服务.在此期间 还将解释微服务应该多小或多大的标准.为了 了解我们需要了解整个方法:
Let me first try to explain how we split our Domain into micro-services. During this the criteria for how small or how big the micro-service should be will be explained as well. In order to understand that we need to see the whole approach:
我们将系统划分为微服务的条件:
我们根据两组环境拆分微服务:
We where splitting the micro-services based on 2 set of environments:
- 基于生产/登台设置. 通常，这是系统将在生产环境上运行以使用的方式 由我们的客户提供.
- 基于Development(开发人员开发机)的设置. 这是每个开发人员必须在其计算机上按顺序进行的设置 运行/调试/开发整个系统或部分系统.
- Based on Production/Staging setup. This is in general how would the system run on a Production environment to be used by our customers.
- Based on Development(Developers development machine) setup. This the setup which each developer has to have on their machine in order to run/debug/develop the full system or parts of it.
仅考虑制作/登台设置:
-
基于 DDD (域驱动设计)有限的上下文: 绑定上下文= 1个微服务. 这是我们最终拥有的最大的女士.大多数时候 绑定的上下文也被拆分为多个微服务. 为什么? 原因是我们的领域很大，因此保留了整个有界上下文 因为一项微服务效率很低.效率低下，我主要是指扩大规模的原因，但是 还进行开发扩展(由较小的团队负责一项微服务)和其他一些原因 以及.
Based on DDD(Domain Driven Design) Bounded Context: Where Bounded Context = 1 micro-service. This was the biggest ms that we ended up having. Most of the time the Bounded Context was also split into multiple micro-services. Why? The reason is that our Domain was very big so keeping the whole Bounded Context as one micro-service was very inefficient. By inefficient I mean mostly scaling reasons, but also development scaling(having smaller teams taking care of one micro-service) and some other reasons as well.
CQRS (命令查询隔离原理): 在划分为每个绑定上下文的micros服务或每个1个绑定上下文为多个微服务之后 对于其中的一些微服务，我们将它们分为2个或更多的微服务，而不是1个.一个命令/写入微服务，第二个是读取/查询微服务. 例如 假设您有一个用户微服务"和用户读取微服务". 用户微服务"负责 创建，更新，删除和一般管理用户.另一方面，用户读取微服务"只是负责 用于检索用户(它是只读的).我们遵循CQRS模式.
CQRS(Command Query Segregation Principle): After splitting to micros-service per Bounded Context or multiple micro-services per 1 Bounded Context for some of those micro-services we had them split in 2 or more microservices instead of 1. One Command/Write micro-service and the second was the Read/Query micro-service. For example lets say you have a "Users micro-service" and "Users-Read micro-service". The "Users micro-service" was responsible for creating, updating, deleting and general management of Users. On the other hand the "Users-Read micro-service" was just responsible for retrieving Users(it was read-only). We where following the CQRS pattern.
在某些极端情况下，写入/域微服务具有多个读取微服务.有时这些Read-micro-service很小，以至于它们只有一个非规范化视图 表示主要使用某种No-SQL db进行快速访问.在某些情况下，它是如此之小，以至于 从预期的代码来看，它将只有几个C#/Java类以及1,2个表或JSON集合 在他们的数据库中.
The Write/Domain micro-service in some extreme cases had multiple Read micro-services. Sometimes these Read-micro-service where so small that they where just having one De-Normalized View-like representation mostly using some kind of No-SQL db for fast access. In some cases it was so small that from code prospective it would just have a couple of C#/Java classes in it and 1,2 Tables or JSON Collections in their Database.
提供域不可知或静态工作或服务的服务
Service which provides Domain agnostic or Static work or services
-
示例1是一个非常小的微服务，负责生成 来自html模板的pdf形式的特定报告.
Example 1 of this was a very small micro-service which was responsible for generating specific reports in form of pdf from an html template.
示例2是一个微服务，它只是向一些特定用户发送简单的文本消息 根据他们的权限.
Example 2 was a micro-service which was just sending simple text messages to some specific users based on their permissions.
考虑开发设置:
除了用于本地开发/运行目的的生产/登台设置之外，我们还需要 特殊的微服务，它们会做一些工作以使本地设置工作. 本地设置是使用docker(docker-compose)完成的. 小型微服务的例子有:
In addition to the ones for Production/Staging setup for local purpose of developing/running we needed special micro-services which would do some work in order to make the local setup work. The local setup was done using docker(docker-compose). Examples of small micro-services there was:
-
数据库，缓存，身份，Api网关和文件存储. 对于生产/分阶段设置中的所有这些事情，我们在这里使用云提供商 为这些事物提供服务，因此我们无需将其放入微服务中. 但是为了使整个系统运行以进行开发/测试，我们需要 以Docker容器的形式创建小型微服务以替换这些云服务.
Database, Cache, Identity, Api Gateway and File Storage. For all this things in the Production/Staging setup we where using a Cloud provider which provides services for these things so we did not have a need to put them in micro-services. But in order to have a whole system running for development/testing purposes we needed to create small micro-services in form of Docker containers to replace these Cloud services.
将测试/播种数据添加到系统中. 为了向微服务的本地开发系统提供数据，我们需要一个 小型微服务，其唯一目的是调用微服务公开的某些API，并且 向其中发布一些数据. 这样，我们可以使用预定义的数据来设置一个有效的开发环境，以便进行测试 一些简单的业务场景.
Adding test/seeding data into the system. In order to feed the local development system of micro-services with data we needed to have a small micro-service which sole purpose was to call some API's exposed by the micro-services and post some data into them. This way we could setup a working development environment with predefined data in order to test some simple business scenarios.
这样做的好处是，您可以结合使用本测试数据设置和本地 用于创建集成和端到端测试的开发设置.
The good thing about this is that you can use this test data setup in combination with the local development setup for creating integration and end-to-end tests.
微服务应该有多小?
-
在我们的案例中，最小的微服务中有几个 仅具有一个非规范化视图(1个表或1个JSON集合)的视图/只读mircro服务，这些代码来自预期的代码 里面有几个C#/Java类.因此，当涉及到代码时，我认为不会那么小 是一个合理的选择.同样，这是主观的观点. 根据有关微服务的一些建议，此大小可以认为太小" 您可以在线阅读有关内容.我们这样做是因为它帮助我们解决了性能问题. 对该数据的需求如此之大，以至于我们将其隔离开来，以便我们可以独立地扩展它. 这使我们有可能根据其需求并独立地扩展此微服务/视图 来自该域的其余部分.
In one our cases the smallest micro-services where a couple of View/Read-only mircro-services which had only one De-Normalized View(1 Table or 1 JSON Collection) which from code prospective had a couple of C#/Java classes in it. So when it comes to code I don't think that much smaller then this would be a reasonable option. Again this is subjective view. This size can be considered as "too small" based on some suggestions around micro-service which you can read about online. We did that because it helped us solve performance issues. The demand for this data was so big that we isolated it so that we can scale it independently. This gave us the possibility to scale this micro-service/view individualy based on its needs and independently from the rest of that Domain.
小型微型服务的第二种情况是html-to-pdf服务，该服务仅基于以下内容创建pdf文档 在特定格式的html模板上.您可以想象功能的这个子集有多小.
Second case of a small micro-service is the html-to-pdf service which was just creating pdf documents based on specific formatted html template. You can imagine how small this subset of functionality was.
建议:
我对每个设计微服务的人的建议是提出正确的问题:
My suggestion for everyone designing micro-services would be to ask the right questions:
-
微服务的规模应该有多大，以便我们不存在将整体拆分为多个整体的情况? 这意味着创建的微服务的规模太大，难以管理，因为这是问题所在 巨石.最重要的是，您会发现分布式系统的弊端.
How big should micro-service be so that we don't have situation with monolith split into multiple monoliths? This means that the size of the created micro-services would be too big and hard to manage as this was the problem for monoliths. On top of this you get the drawbacks of distributed systems.
微服务的大小会影响您的性能吗? 对于您的客户而言，关键是系统性能良好，因此，将其视为 微服务系统体系结构的标准可能是非常有效的观点.
Is that size of a micro-service going to affect your performance? For you customers the key is that the system performance is good, so considering this as criteria for micro-services system architecture could be a very valid point.
我们应该还是应该提取功能/逻辑的某些关键部分以将其隔离? 哪个关键逻辑是如此重要，以至于您无法承受它的崩溃或服务中断 为了它? 这样，您可以保护系统中最关键的部分.
Should or can we extract some critical part of the functionality/logic in order to isolate it? Which critical logic is so important that you can not afford to have it broken or service-downtime for it? This way you can protect your most critical part of the system.
我可以用这种微服务架构拆分来组织我的一个或多个团队吗?
Can I organize my team or teams with this kind of micro-services architecture split?
考虑到我已经完成了微服务架构，而我又拥有了"n"个微服务 我将如何管理它们?这意味着支持他们，安排部署，根据需要进行扩展， 显示器等等? 如果您提出的这种架构对您来说是具有挑战性且不可管理的， 组织或团队，然后重新考虑他们.没有人需要一个难以管理的系统.
Considering I have the micro-services architecture done and I have "n" micro-services how will I manage them? This means support them, orchestrate deployment, scale based on needs, monitor and so on? If this architecture that you came up turns out to be challenging and not manageable for your organisation or teams then reconsider them. Nobody needs an unmanageable system.
还有更多可以引导您走向正确方向的信息，但这些都是我们遵循的方向.
There are many more which could could lead you to the right directions but these where the ones we where following.
这些问题的答案将自动带您到最小/最大的微型服务 为您的域/业务.我上面关于微服务规模的示例现在可能适用于您的情况 以及我们在其中使用的规则，但回答这些问题将使您更接近自己 自己决定的方法/规则.
Answers to those questions will automatically lead you to the smallest/biggest possible micro-service for your Domain/Business. My example about micro-services size from above might now work for your case and the rules that we where using as well, but answering these questions will bring you closer to your own approach/rule to decide that.
结论
微服务应尽可能小，以满足您的需求.名称"micro"表示它们可能很小. 注意不要将此规则作为整个系统的规则. 最小的微服务是解决某些特定问题(例如扩展或扩展)的例外. 关键逻辑隔离，而不是在这样规模的微服务中设计/拆分整个系统的规则. 如果为了拥有微型微服务而不得不拥有许多非常小的微服务，那么您将很难 在没有任何实际好处的情况下进行管理.小心分割它.
The micro-services should be as small as you need it to fit your needs. The name "micro" indicate that they can be very small. Be careful to not make this a rule for all your system. The smallest micro-services are rather an exception to solve some specific problem like scaling or critical logic isolation rather then a rule for designing/splitting the whole system in micro-services of that size. If you have to many very small micro-services just for the sake of having them and them being small you will have hard time in managing them with no real benefit. Be careful how you split it.
这篇关于微服务应该有多小?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
