扩展你的微服务：了解服务发现和服务网格

　　在当今时代，每个人都在谈论微服务。微服务架构的旅程始于整体。在整体中，我们将整个应用程序打包为一个单元，正在开发并将其部署为单个应用程序。单个存储库中的大量代码很难维护和扩展。为了处理与整体组件有关的问题，有一个通用的解决方案，即将整体组件拆分为可管理的独立服务，并在需要时分别缩放它们。这些较小的服务称为微服务。

　　让我们以传统的整体来看，看看有什么用。比方说，我们的整体有4个模块-A，B，C和D。现在，只要A想与B对话，就非常容易。这只是一个函数调用，因为A可以调用B的公共方法，因为它们是同一应用程序的一部分。但是这样的系统存在很多问题，例如：

　　· 如果模块A中存在错误，并且代码无法编译。 这将使我们的整个服务下降

　　· 如果模块A上的负载远大于模块B，则我们无法独立扩展模块A。

　　· 模块A的发布取决于模块B的发布

　　因此，建议将我们的整体分成较小的服务。

　　

　　> Figure 1 — Splitting a monolith into smaller services

　　但是在分布式设置中，我们必须面对许多挑战，例如模块A如何与模块B交互。

　　

　　> Figure 2 — Services communicating via a load balancer

　　解决此问题的一种简便方法是，服务A将通过负载平衡器与服务B进行通信。但是这种方法存在以下问题：

　　· 负载均衡器将成为单点故障

　　· 我们将在我们的应用程序中对负载均衡器的URL进行硬编码，这也是一个不好的做法

　　· 该请求必须经过额外的跃点，因为该请求将始终通过负载平衡器传递

　　更好的方法似乎是引入ServiceRegistry。服务注册表将保留所有服务的IP。如果存在服务B的3个实例，则服务注册表将具有服务B的3个实例的IP地址。

　　

　　> Figure 3- Introduction of ServiceRegistry

　　让我们看一下具有ServiceRegistry的基础结构：

　　· 每当服务联机时，它都会向ServiceRegistry注册自己

　　· 每当服务上线时，它都会向ServiceRegistry询问与之联系的其他服务的IP。

　　· ServiceRegistery会定期更新与其他服务相关的文凭信息的服务

　　在上图中，ServiceRegistry看起来像是单点故障，但是ServiceRegistry通常由许多服务器组成，并且数据在这些服务器之间复制。

　　为了完成所有这些，所有服务都需要一种与ServiceRegistry通信的方式。 常见的解决方案之一是使用Sidecar。 每项服务都将附带安装边车。 边车将获得有关ServiceRegistry的信息。 边车将与ServiceRegistry通信，并将为应用程序提供所需服务的IP。 边车将充当代理。 现在，所有发出并进入特定服务的请求都将通过挎斗传递。

　　

　　> Figure 4- Every Service has a sidecar along with it

　　与其他架构相比，该架构将解决以下优点：

　　· 服务A将直接与服务B交互，从而减少网络延迟

　　· 边车还将实施电路中断和重试机制

　　· 现在我们的系统中没有单点故障

　　

　　> Figure 4

　　因此，现在我们的整体图如图5所示，并且服务之间的交互也将是无缝的。

　　

　　> Figure 5

　　HashiCorp Consul，Netflix Edureka等很少有可以用来实现上述架构的常用工具。

　　> Figure 6 — How a ServiceMesh looks when having 1000's of services

　　在Uber，Amazon，Netflix等系统中，服务数量过高，即具有100个和1000个微服务的系统。因此，以上架构看起来像网格类型的结构。因此，此模式称为服务网格体系结构。