宗教、法律和公约的创建是为了解决社会问题，正如新技术是为了解决技术问题而创建的一样。微服务架构是对一个技术问题的新技术发展。不幸的是，由于缺乏对微服务历史的了解，这个概念在软件开发社区中仍然存在争议。

Religions, laws, and conventions have been created to address societal problems just as new technologies are created to address technological problems. The microservices architecture is a new technological development to a technological problem. Unfortunately, the concept remains controversial among the software development community due to a lack of understanding about the history of microservices.

当开发人员不了解微服务的历史时，他们会在实施过程中浪费时间和金钱。这导致出现了大量诅咒微服务架构及其容器（即 Docker 和 Podman）、编排器（即 Kubernetes 和 Nomad）和虚拟计算管理系统（云计算）的文章。当然，工程师在使用这些工具时面临的问题可以通过了解微服务的目的来消除。

When developers fail to understand the history of microservices, they waste time and money in its implementation. This leads to the creation of numerous articles which curse the microservices architecture and its containers (i.e Docker and Podman), orchestrators (i.e Kubernetes and Nomad), and virtual computing management systems (Cloud Computing). Of course, the issues engineers face with these tools can be eliminated by understanding the purpose of microservices.

微服务的概念化

The Conceptualization of Microservices

微服务架构是对计算机物理限制的解决方案。换句话说，物理定律——连同光速——在物理上限制了单个计算机的运行速度。那么当您需要运行超出单台计算机物理限制的软件时会发生什么？

The microservices architecture is a solution to the physical limits of a computer. In other words, the Laws of Physics — alongside the speed of light — physically limits the speed that an individual computer can run at. So what happens when you need to run software that exceeds the physical limits of an individual computer?

可伸缩性 是增加服务可以处理的操作量的能力。例如，Web 服务器软件向用户的客户端发送（提供）页面。它通过处理用户请求（一个操作）然后将页面发送给用户（另一个操作）来实现。缩放此 Web 服务器意味着增加它在给定时间段内（即每秒）可以提供的页面数量。

Scalability is the ability to increase the amount of operations a service can handle. As an example, a Web Server software sends (serves) pages to a user’s client. It does so by processing user requests (an operation) and then sending the page to the user (another operation). Scaling this Web Server means increasing the amount of pages it can serve in a given time period (i.e per second).

当运行 Web 服务器的计算机需要扩展时，一种方法是升级计算机。这种升级——称为垂直缩放——提高了计算机的速度，从而提高了 Web 服务器的速度限制。然而，在某些时候，升级计算机变得不可能。因此，我们必须通过在多台计算机上运行 Web 服务器来扩展它。

When the computer that runs the Web Server needs to scale, one method of doing so is by upgrading the computer. This upgrade — referred to as Vertical Scaling — increases the speed of the computer, which increases the speed limit of the Web Server. However, at some point, upgrading the computer becomes IMPOSSIBLE. As a result, we must scale the web server by running it across multiple computers.

添加另一台计算机进行缩放称为水平缩放，用于水平架构 (HA)。

Adding another computer to scale is referred to as Horizontal Scaling which is used in a Horizontal Architecture (HA).

以与人体细胞类似的方式，计算机必须使用信号交换信息，以在多台计算机上处理相同的操作。这种交换信息的过程称为通信，并通过计算机网络用于协调各项服务。不幸的是，通信是以处理速度为代价的，称为延迟。最佳的微服务架构实现允许开发人员使用另一台计算机为服务添加功能，同时仍保持低延迟。

In a similar manner to the cells of a human body, computers must exchange information using signals to process the same operation over multiple computers. This process of exchanging information is known as communication, and is used over a computer network to coordinate each service. Unfortunately, communication comes at a cost to processing speed called latency. An optimal microservices architecture implementation allows the developer to add power to a service using another computer, while still maintaining a low latency.

下面的问题可以用来理清微服务的概念。

The following questions can be used to clarify the concept of microservices.

我什么时候应该使用微服务？

如果您的程序尚未创建，则必须考虑微服务的实施是否值得。你的服务会变成两者兼而有之吗

1. 由于计算机的物理限制而出现瓶颈。

2. 无法通过主动-主动负载平衡（即克隆单体）进行水平扩展。

如果是这样，那么实施微服务是一个客观有效的决定。否则，如果您的程序已经存在（但未能满足上述条件），则根本不需要微服务架构。

我应该如何构建我的代码？

没关系。微服务与代码无关。这是关于架构的。

我应该使用一个存储库还是多个？

也没关系。微服务与代码无关。这是关于架构的。

话虽如此……

When Should I Use Microservices?

If your program has yet to be created, you must consider whether the implementation of microservices is worth it. Will your service become both

1. Bottlenecked due to the physical limitation of a computer.

2. Unable to be horizontally scaled through active-active load balancing (i.e cloning the monolith).

If so, implementing microservices is an objectively valid decision. Otherwise, if your program already exists (while failing to meet the criteria above), a microservices architecture is simply not necessary.

How Should I Structure My Code?

It doesn’t matter. Microservices is not about the code. It’s about the architecture.

Should I Use One Repository or Multiple?

It also doesn’t matter. Microservices is not about the code. It’s about the architecture.

With that being said…

一项服务应该依赖于另一项服务吗？

假设您将 Web Server 拆分为两个微服务，分别用于处理请求和发送页面。当用户发送请求时，它会在用户客户端加载页面（从发送服务的内容）之前发送到与处理服务通信的发送服务。在这种情况下，发送服务依赖于处理服务。

那么当处理服务宕机时会发生什么？

在最糟糕的实施中，用户停止接收页面，因为没有任何处理。但是，您可以通过在发送服务中添加逻辑以向用户发送“遇到服务器问题”页面（当处理服务关闭时）来解决此问题。这允许用户即使在处理服务关闭时也能接收页面。因此，线性依赖并不是微服务架构中的世界末日。

但是当发送服务需要处理服务的信息时，会出现以下情况。

SRE 将在半夜被传呼。用户不会收到页面，因为处理服务已关闭，即使发送服务已启动并且……发送服务也将关闭。发生了什么？您创建了服务的循环依赖。

Should One Service Depend On Another?

Let’s say that you split the Web Server into two microservices for processing requests and sending pages. When a user sends a request, it will be sent to the sending service which communicates with the processing service BEFORE the user’s client loads the page (from the sending service’s content). In this case, the sending service depends on the processing service.

So what happens when the processing service goes down?

In the worst implementation, users stop receiving pages because nothing is being processed. However, you can fix this by adding logic in the sending service to send an “experiencing server issues” page to the user (when the processing service is down). This allows the user to receive pages even when the processing service is down. Thus, a linear dependency is not the end of the world in a microservices architecture.

But when the sending service requires information from the processing service, the following scenario occurs.

The SRE will be paged in the middle of the night. Users won’t receive pages because the processing service is down, even though the sending service is up and… The sending service will go down as well. What happened? You created a circular dependency with your services.

不要那样做。

使用微服务架构要求您以与代码类似的方式管理依赖项。幸运的是，程序员已经创建了管理多个服务容器（即 Docker 和 Podman）之间依赖关系的工具。这些工具（例如 Kubernetes 和 Nomad）被称为容器编排器，因为它们编排容器。

容器和容器编排器的意义在于它们是解决微服务架构提供的复杂性的技术发展。这些复杂性是不可避免的，除非您可以开发出可以无限升级的计算机。然而，微服务技术的发展并没有止步于此。

容器（服务）之于计算机就像计算机之于集群。这样一个计算机集群管理多台计算机（称为服务器）。程序员使用云计算以虚拟方式管理这些集群中的计算机。有状态语言（例如 Terraform）的创建是为了管理云的状态。这就是为什么“云计算是为规模而生的。”

那么数据库呢？

您的数据库是一项服务。所以遵循上面建立的规则是有意义的。不要实现循环依赖，即使这样做需要使用多个数据库和/或重复数据。实际上，您不太可能为两个单独的服务得到相同的架构。因此，推荐每个微服务使用自己的数据库。

Don’t do that.

Using the microservices architecture requires you to manage your dependencies in a similar manner to your code. Fortunately, programmers have created tools which manage dependencies among multiple containers of services (i.e Docker and Podman). These tools — such as Kubernetes and Nomad — are called container orchestrators because they orchestrate containers.

The significance of the container and the container orchestrator is that they are technological developments that solve complexities provided by the microservices architecture. These complexities are not avoidable unless you can develop a computer that is infinitely upgradeable. However, the development of microservice technologies hasn’t stopped at this point.

A container (of services) is to a computer as a computer is to a cluster. Such that a computer cluster manages multiple computers (called servers). Programmers use Cloud Computing to manage the computers within these clusters in a virtual manner. Stateful languages — such as Terraform — were created to manage the state of the cloud. So that’s why “Cloud Computing is made for scale.”

So What About The Database?

Your database is a service. So it makes sense to follow the rules established above. Don’t implement circular dependencies, even if doing so requires the usage of multiple databases and/or duplicate data. In practice, you are NOT likely to end up with the same schema for two separate services. Hence, the database per service recommendation.

无需争论

围绕微服务的争议可以通过对开发人员进行概念化教育并谨慎实施来解决。微服务架构是开发人员可以用来解决技术问题的另一种工具：它不应该应用于现有的每个项目。展望未来，我们必须鼓励开发人员了解特定技术存在的原因，而不是仅仅关注它的工作原理。

No Need For Controversy

The controversy surrounding microservices can be addressed by educating developers on its conceptualization and being cautious in its implementation. The microservices architecture is another tool developers can use to solve technological problems: It should NOT be applied to every project that exists. Going forward, we must encourage developers to learn about the reason a given technology exists as opposed to focusing solely on how it works.