德国大神的软件架构手册( 三 ) _软件架构

按照我们的示例，之前我们只有一个服务器负责所有功能（单体架构）。实现微服务后，我们将有一个服务器负责身份验证，另一个负责支付，另一个负责流式传输，最后一个负责推荐。
当用户想要登录时，客户端应用程序将与身份验证服务器通信，当用户想要支付时与支付服务器通信，当用户想要观看时与流媒体服务器通信。
所有这些通信都是通过 API 进行的，就像使用常规的单片服务器（或通过其他通信系统，如Kafka或RabbitMQ）一样。唯一的区别是，现在我们有不同的服务器负责不同的操作，而不是一个单独的服务器来完成所有操作。
这听起来有点复杂，确实如此，但微服务为我们提供了以下好处：

您可以根据需要扩展特定服务，而不是一次扩展整个后端。按照我们的示例，当我们开始遇到性能问题时，我们垂直扩展了整个服务器——但实际上请求更多资源的功能只是流式传输。现在我们已经将流功能分离到一个服务器中，我们可以只扩展那个，只要它们继续正常工作就可以不用管其余的。
功能将更加松散耦合，这意味着我们将能够独立开发和部署它们。
每个服务器的代码库会更小更简单。这对于从一开始就与我们合作的开发人员来说是一件好事，对于新开发人员来说也更容易和更快地理解。

微服务是一种设置和管理更复杂的架构，这就是为什么它只对非常大的项目有意义。大多数项目将作为单体开始，仅在出于性能原因需要时迁移到微服务。
如果您想了解更多关于微服务的信息，这里有一个很好的解释。
什么是前端（BFF）的后端？
实现微服务时出现的一个问题是与前端应用程序的通信变得更加复杂。现在我们有许多服务器负责不同的事情，这意味着前端应用程序需要跟踪这些信息才能知道向谁发出请求。
通常这个问题可以通过在前端应用程序和微服务之间实现一个中间层来解决。这一层会接收所有的前端请求，重定向到对应的微服务，接收微服务响应，然后将响应重定向到对应的前端应用。
BFF 模式的好处是我们获得了微服务架构的好处，而不会使与前端应用程序的通信过于复杂。

文章插图

我们的 BFF 实施
如果您想了解更多信息，这里有一个解释 BFF 模式的视频。
如何使用负载均衡器和水平扩展
因此，我们的流媒体应用程序以指数级的速度不断增长。我们在全球有数百万用户 24/7 全天候观看我们的电影，而且比我们预期的更快，我们再次开始遇到性能问题。
我们再次发现流媒体服务是压力最大的服务，我们已经尽我们所能垂直扩展了该服务器。将该服务进一步细分为更多的微服务是没有意义的，因此我们决定横向扩展该服务。
之前我们提到垂直扩展意味着向单个服务器/计算机添加更多资源（RAM、磁盘空间、GPU 等）。另一方面，水平扩展意味着设置更多的服务器来执行相同的任务。
我们现在将拥有三个服务器，而不是一个负责流式传输的服务器。然后客户端执行的请求将在这三台服务器之间进行平衡，以便所有服务器都能处理可接受的负载。
这种请求的分配通常由称为负载均衡器的东西执行。负载均衡器充当我们服务器的反向代理，在客户端请求到达服务器之前拦截它们并将该请求重定向到相应的服务器。
虽然典型的客户端-服务器连接可能如下所示：