宗教、法律和惯例都是为了解决社会问题而产生的，正如新技术是为了解决技术问题而产生的一样。微服务架构是针对技术问题的一种新的技术发展。不幸的是，由于对微服务的历史缺乏了解，这一概念在软件开发界仍有争议。
当开发者不能理解微服务的历史时，他们就会在其实施中浪费时间和金钱。这导致了许多文章的产生，这些文章诅咒微服务架构及其容器（即Docker和Podman）、协调器（即Kubernetes和Nomad）以及虚拟计算管理系统（云计算）。当然，工程师们在使用这些工具时所面临的问题可以通过了解微服务的目的来消除。
微服务的概念化
微服务架构是对计算机的物理限制的一种解决方案。换句话说，物理定律--与光速一起--在物理上限制了单个计算机的运行速度。那么，当你需要运行超过单个计算机物理极限的软件时，会发生什么？
可扩展性是指增加一个服务所能处理的操作量的能力。举个例子，一个网络服务器软件向用户的客户端发送（服务）网页。它通过处理用户的请求（一个操作），然后将页面发送给用户（另一个操作）来实现。扩展这个网络服务器意味着增加它在给定时间段内（即每秒）所能提供的页面数量。
当运行网络服务器的计算机需要扩展时，一种方法是通过升级计算机来实现。这种升级--被称为垂直扩展--提高了计算机的速度，从而提高了网络服务器的速度限制。然而，在某些时候，升级计算机变得不可能了。因此，我们必须通过在多台计算机上运行Web服务器来扩展它。
增加另一台计算机的规模被称为水平扩展，这在水平架构（HA）中使用。
与人体的细胞类似，计算机必须使用信号交换信息，在多台计算机上处理相同的操作。这种交换信息的过程被称为通信，并通过计算机网络来协调每项服务。不幸的是，通信是以处理速度为代价的，称为延迟。一个最佳的微服务架构实现允许开发者使用另一台计算机为服务增加动力，同时仍然保持低延迟。
下面的问题可以用来澄清微服务的概念。
我什么时候应该使用微服务？
如果你的程序还没有创建，你必须考虑实施微服务是否值得。你的服务是否会变得既
由于计算机的物理限制而陷入瓶颈。
无法通过主动-主动负载平衡（即克隆单片机）进行横向扩展。
如果是这样，实施微服务是一个客观上有效的决定。否则，如果你的程序已经存在（同时未能满足上述标准），微服务架构根本没有必要。
我应该如何构造我的代码？
这并不重要。微服务不是关于代码的。它是关于架构的。
我应该使用一个代码库还是多个库？
这也不重要。微服务不是关于代码的。它是关于架构的。
一个服务应该依赖另一个服务吗？
假设你把Web服务器分成两个微服务，用于处理请求和发送页面。当用户发送请求时，它将被发送到发送服务，发送服务在用户的客户端加载页面之前与处理服务进行通信（来自发送服务的内容）。在这种情况下，发送服务依赖于处理服务。
那么，当处理服务发生故障时，会发生什么？
在最糟糕的实现中，用户停止接收页面，因为没有任何东西被处理。然而，你可以通过在发送服务中添加逻辑来解决这个问题，向用户发送一个 "正在经历服务器问题 "的页面（当处理服务停机时）。这允许用户在处理服务中断时也能收到页面。因此，在微服务架构中，线性依赖并不是世界末日。
但是当发送服务需要处理服务的信息时，就会出现以下情况。
SRE将在半夜被呼出。用户不会收到页面，因为处理服务已经停机，即使发送服务已经启动，而且......发送服务也会停机。发生了什么？你用你的服务创建了一个循环依赖关系。
不要那样做。
使用微服务架构需要你以类似于代码的方式管理你的依赖关系。幸运的是，程序员们已经创造了一些工具，可以管理多个服务容器之间的依赖关系（即Docker和Podman）。这些工具--如Kubernetes和Nomad--被称为容器协调器，因为它们协调了容器。
容器和容器协调器的意义在于，它们是解决微服务架构所提供的复杂性的技术发展。这些复杂性是无法避免的，除非你能开发一台可以无限升级的计算机。然而，微服务技术的发展在这一点上并没有停止。
容器（的服务）对计算机来说，就像计算机对集群一样。这样，一个计算机集群管理着多台计算机（称为服务器）。程序员使用云计算，以虚拟的方式管理这些集群内的计算机。有状态的语言--如Terraform--是为了管理云的状态而产生的。所以这就是为什么 "云计算是为规模而生"。
那么，关于数据库呢？
你的数据库是一种服务。因此，遵循上面的规则是有意义的。不要实施循环依赖，即使这样做需要使用多个数据库和/或重复的数据。在实践中，你不可能为两个独立的服务使用相同的模式。因此，每个服务的数据库建议。
不需要争论
围绕微服务的争议可以通过教育开发者了解其概念和谨慎实施来解决。微服务架构是开发者可以用来解决技术问题的另一个工具。它不应该被应用于每一个存在的项目。展望未来，我们必须鼓励开发者了解某项技术存在的原因，而不是仅仅关注它是如何工作的。