微服务不需要容器_您不需要微服务

微服务不需要容器

You Aren’t Gonna Need It (YAGNI) is one of the most important principles in software development.

您根本不需要它 (YAGNI)是软件开发中最重要的原则之一。

“Perfection is achieved not when there is nothing more to add, but when there is nothing more to take away.” ~ Antoine de Saint-Exupery

“完美的实现不是在没有其他要添加的东西时实现的，而是在没有其他要增加的条件下实现的。” 〜安东尼·圣艾修伯里

We can see YAGNI as a special case of the Keep It Simple Stupid (KISS) principle. YAGNI applies to a higher level as it tells us to cut off any unnecessary part while KISS advises to make the rest as simple as possible.

我们可以将YAGNI视为保持简单愚蠢 (KISS)原则的特例。 YAGNI适用于更高的级别，因为它告诉我们削减任何不必要的部分，而KISS建议使其余部分尽可能简单。

“Everything should be made as simple as possible, but no simpler.” ~ Albert Einstein

“一切都应该尽可能简单，但不要简单。” 〜爱因斯坦

Violation of YAGNI is sometimes called overengineering. A feature for every possible case, functions/methods with a lot of input parameters, multiple if-else branches, rich and detailed interfaces, all those could be a smell of overengineering. It’s the opposite to the famous UNIX-mantra: Do one thing well.

违反YAGNI有时被称为过度工程 。 针对每种可能情况的功能，具有大量输入参数的功能/方法，多个if-else分支，丰富而详细的界面，所有这些可能都带有过度设计的味道。 与著名的UNIX口号相反： 做好一件事 。

To avoid this trap, always ask yourself a question: “Is it really needed right now?” If the answer is “Well, maybe,” then probably not.

为了避免出现此陷阱，请始终问自己一个问题： “现在真的需要吗？” 如果答案是“好吧，也许吧”，那么可能不会。

Often, significant architectural decisions must be made to implement a feature. This is a problem because the earlier a decision is made the less information we have and the more likely a wrong decision is to be made. Therefore, it is a good practice to postpone difficult decisions until the last possible moment. Ignoring YAGNI leads to a violation of this practice.

通常，必须做出重要的体系结构决策才能实现功能。 这是一个问题，因为早日做出决定，我们掌握的信息越少，就越有可能做出错误的决定。 因此，优良作法是将艰难的决定推迟到最后可能的时刻。 忽略YAGNI会违反此惯例。

The main point of YAGNI is to pay the costs first when the feature is actually needed, and not right now, just in case. YAGNI violations make development always expensive, because the complexity behind each feature must be paid, even though the feature is not necessary (yet). In other words, accidental complexity rises. And complexity is expensive. Complexity is no fun.

YAGNI的主要目的是在实际需要此功能时先支付费用 ，以防万一，现在不立即支付费用 。 违反YAGNI会使开发工作总是很昂贵，因为即使没有必要(即使有)，也必须付出每个功能背后的复杂性。 换句话说，意外的复杂性增加了。 而且复杂性是昂贵的。 复杂性不好玩。

The same reasoning can be applied to microservices. But, don’t take me wrong: there are plenty of highly useful benefits that the microservices style can bring you and a lot of great principles you can apply even to your monolith. However, the actual question remains the same: Do you really need them right now? Do you really need to scale every service up to a thousand instances? Do you need a Kubernetes cluster, a Kafka broker and an Istio service mesh? Once again: maybe, but probably not right now.

相同的推理可以应用于微服务。 但是，请不要误会我的意思：微服务风格可以为您带来很多非常有用的好处，甚至可以应用到整体上的许多重要原则 。 但是，实际问题仍然是： 您现在真的需要它们吗？ 您是否真的需要将每个服务扩展到一千个实例？ 您是否需要Kubernetes集群，Kafka代理和Istio服务网格？ 再一次：也许吧，但现在可能不行。

微服务的谬误 (Fallacies of microservices)

Let’s take a look at some typical fallacies I’ve observed so far among teams adopting microservices:

让我们来看看到目前为止我在采用微服务的团队中观察到的一些典型谬误：

1.微服务帮助您找到界限 (1. Microservices help you find boundaries)

This is probably the most dangerous misunderstanding of microservices and a very expensive mistake you can make. Remember: Microservices are about technology, boundaries are about business. No technology can help you define your boundaries, only proper understanding your business does.

这可能是对微服务的最危险的误解，并且是您可能犯的非常昂贵的错误。 请记住：微服务与技术有关，边界与业务有关 。 任何技术都无法帮助您定义界限，只有正确理解您的业务才能做到。

Microservices are just one option how to physically separate components once boundaries are correctly defined. At the same time, they make the boundaries hard to change if they are found to be wrong, which often happens, especially in early phases of the product development.

一旦正确定义了边界，微服务只是如何物理分离组件的一种选择。 同时，如果发现错误，边界将很难更改，这种情况经常发生，尤其是在产品开发的早期阶段。

Try to define your service boundaries without any concerns of technology, build a team around them, implement a few product iterations. As you gain some confidence, you can turn them into microservices, if it will solve an actual problem.

尝试在不考虑技术的情况下定义服务边界，围绕它们建立团队，实施一些产品迭代。 如果您有信心，可以解决实际问题，就可以将它们转变为微服务。

2.微服务使您的系统模块化 (2. Microservices make your system modular)

Microservices don’t make your system modular out of the box. Modularity means a logical separation of business concepts. Microservices make this separation visible and difficult to cross over. While this is good, it does not come without drawbacks such as resistance to refactoring the structure of the modules.

微服务不会使您的系统模块化。 模块化意味着业务概念的逻辑分离。 微服务使这种分离可见并且难以跨越。 虽然这很好，但它并非没有缺点，例如难以重构模块的结构。

Anyway, there are much cheaper options such as using packages/namespaces, modules/artifacts, etc. Those solutions provide a good level of physical separation along with ease to change.

无论如何，还有很多便宜的选择，例如使用包 /名称空间， 模块 /工件等。这些解决方案提供了良好的物理隔离级别，并且易于更改。

3.微服务使您的系统性能出色 (3. Microservices make your system performant)

The possibility to scale every single service independently is one of the most emphasized advantages of microservices. While this is true, it comes with costs. Running every service as a separate process can’t be done without a supporting infrastructure. Things like service mesh, service discovery or load balancer come to mind first.

独立扩展每项服务的可能性是微服务最强调的优势之一。 虽然这是事实，但要付出代价。 没有支持的基础架构，无法将每个服务作为单独的流程运行。 首先想到诸如服务网格，服务发现或负载平衡器之类的东西。

Cloud providers offer a working solution for you, but one has to bear in mind that remote calls are always more expensive than inter-process communication. Do you really need to scale all your services? Maybe one or two most loaded would be enough. Vertical scaling or scaling the whole system are options that usually just work and that are much cheaper that microservices.

云提供商为您提供了一种可行的解决方案，但必须记住，远程调用总是比进程间通信贵。 您真的需要扩展所有服务吗？ 也许一两个负载最重就足够了。 垂直扩展或扩展整个系统通常是可行的，并且比微服务便宜得多。

Another aspect is a good modularity. When service boundaries are incorrectly defined and multiple remote calls must be done to process a request, the overall performance is likely to decrease when turning such a system into microservices.

另一个方面是好的模块化。 当错误地定义了服务边界并且必须执行多个远程调用来处理请求时，将此类系统转变为微服务时，整体性能可能会下降。

4.微服务更便宜 (4. Microservices are cheaper to operate)

A typical example of this fallacy is Serverless computing. While there definitely are use-cases where the serverless approach can be beneficial and cheap to develop and operate, the amount of such use-cases is pretty limited. What’s more, it’s easy to get an impression that going serverless means just writing code and taking no care how it’s being operated. This is usually not true. For example, monitoring is still an important and a hard problem no one else will solve for you.

这种谬误的典型示例是无服务器计算。 尽管肯定有一些用例，无服务器方法可以有益且廉价地开发和运行，但这种用例的数量非常有限。 而且，很容易给人一种印象，即无服务器化意味着只编写代码，而不关心它的操作方式。 这通常是不正确的。 例如，监视仍然是一个重要而又艰巨的问题，没人能为您解决。

Serverless is an extreme case. An application running in the cloud in the same way as previously in your own server warehouse is likely to be much more expensive. This is very true especially for so-called Lift&Shift solutions.

无服务器是极端情况。 在云中以与以前在自己的服务器仓库中相同的方式运行的应用程序可能会贵得多。 尤其是对于所谓的Lift＆Shift解决方案而言，这是非常正确的。

One idea behind microservices is to move a piece of complexity from development into operations, where it is easier (and cheaper) to tackle. Yes, doing microservices right, you might save some money on development but your operation costs will probably increase rapidly. This is not necessarily a bad thing as you do save some bucks at the end of the day, it’s just something to be aware of.

微服务背后的一个想法是将一部分复杂性从开发转移到运营中，在此过程中更容易(更便宜)来解决。 是的，如果正确执行微服务，您可以节省一些开发费用，但是您的运营成本可能会Swift增加。 这不一定是一件坏事，因为您最终还是省下了一些钱，这只是需要注意的事情。

5.微服务更易于开发 (5. Microservices are easier to develop)

Because a lot of complexity is moved to operations, great Ops skills are required inside the teams when taking the microservices-oriented approach. As the need for communication between Devs and Ops becomes crucible, there’s no room for traditional separation by technical responsibilities. All members of the team must work together on a whole business feature, preferably colocated in the same room.

由于将很多复杂性转移到了运营上，因此在采用面向微服务的方法时，团队内部需要出色的Ops技能。 随着开发人员和操作人员之间的通信需求变得越来越迫切，传统上的技术责任分离已无余地。 团队的所有成员必须在整个业务功能上协同工作，最好在同一房间内。

Microservices are a practical approach to Agile development and require a real DevOps mindset, where the whole team is responsible for the product from the first sketches to running the production environment.

微服务是敏捷开发的一种实用方法，需要一种真正的DevOps思维方式，整个团队负责从最初的草图到运行生产环境的整个产品。

If “DevOps” in your organization is done by that guy sitting in the last office on the second floor, then you shouldn’t even think about microservices.

如果您组织中的“ DevOps”是由坐在二楼最后一个办公室的那个人完成的，那么您甚至不应该考虑微服务。

6.微服务很小 (6. Microservices are small)

Very popular topic and a big misconception. “Micro” does mean small or even smaller, right? Small is good, small is easy. Easy to understand, easy to develop, easy to operate… Well, no. “Micro” is not about size, it is about responsibility. Anecdotes such as two pizza teams or code that fits on my screen might work in some organizations, however, they are no general rules.

非常受欢迎的话题和很大的误解。 “微型”意味着更小甚至更小，对吗？ 小是好，小是容易。 易于理解，易于开发，易于操作……嗯，不。 “微观”与规模无关，而与责任有关 。 诸如两个披萨团队之类的轶事或适合我的屏幕的代码在某些组织中可能适用，但是，这不是通用规则。

A service should be minimal in its responsibility and API. A service should implement just a single business capability. Nothing more, nothing less. The contract must be simple and clear. No unnecessary pollution, no implementation details.

服务的职责和API应该最少。 服务应仅实现单个业务功能。 仅此而已。 合同必须简单明了。 没有不必要的污染，没有实施细节。

The implementation can be big, even huge at the beginning. The bounded context (from Domain-driven development) defines the biggest possible service. That is the boundary to start with. Other services will emerge by themselves as the domain becomes clearer.

开始时实现可能很大，甚至可能很大。 有界上下文(来自域驱动的开发)定义了最大可能的服务。 这是开始的边界。 随着域变得更加清晰，其他服务将自行出现。

摘要 (Summary)

Always ask yourself: “Do I really need this right now? Is this the simplest thing that can possibly work?”

总是问自己： “我现在真的需要这个吗？ 这是最简单的可行的方法吗？”

Don’t go microservices just because they look cool and everybody is talking about them — they are no silver bullet. Doing so would be a violation of the YAGNI principle on the architecture level. That is, don’t do it. All in all, you aren’t gonna need it!

不要仅仅因为微服务看起来很酷并且每个人都在谈论它们而去微服务-它们不是灵丹妙药。 这样做将在体系结构级别上违反YAGNI原则。 也就是说，不要这样做。 总而言之，您将不需要它！

翻译自: https://medium.com/@ttulka/you-arent-gonna-need-microservices-ef22498bd3c0

微服务不需要容器