微服务基建：服务、配置与API网关的逻辑

97 浏览量更新于2024-08-28 收藏 420KB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

资源详情

资源推荐

浅谈微服务基建的逻辑浅谈微服务基建的逻辑

起点

首先，我们得有一个“服务”。根据定义，我们可以把每个服务实例都视作一个黑盒。这个盒子有着明确的输入点和输出点，并

且（理想情况下）仅通过这些输入和输出点和外界产生关联。每个服务实例会拥有专属的网络地址、独立的计算资源，并且独

立部署。客户端通过访问服务实例的地址来调用服务 API。不同服务也可以相互调用。

配置管理器：统一管理配置

在微服务体系中，每个服务都独立部署和运行，团队可以根据需要自行选择增加和减少计算资源。一个服务可能会跑多个实

例，每个服务实例都会需要做配置。为了方便统一调整配置，我们可以把配置中心化，每个服务实例都去找配置管理器

（Configuration Manager）拿配置。当配置更新的时候，我们也可以让服务实例再去拿新的配置。

服务名册：解耦主机地址

这也引出了一个问题：网络地址（比如 IP）很容易因为扩容、维护而变动，调用者难以实时获知可用的地址。

鉴于此，我们可以把网络地址抽象成不容易变动的概念，比如给每个服务一个固定的名字。互联网使用 DNS 来解决这个问

题，对应到微服务基建里面就是服务名册（Service Registry）。

每个服务实例在运行期间，都会以心跳的形式向服务名册发送注册信息，包括服务的 ID 、访问地址以及健康状况。这样，需

要访问服务的时候，客户端就可以先问服务名册拿可用的实例地址，然后再访问实例来调用服务。除了更好地定位实例地址，

服务名册还可以在某些实例下线、维护或升级的时候把其临时从名册中去掉，让服务不断线。

服务之间的调用也是如此，先找名册拿网络地址，再进行调用。

下载后可阅读完整内容，剩余5页未读，立即下载

weixin_38665449