标签： discovery

发布于

解析 Service Discovery（服务发现）：对比 Consul, Etcd 与 DNS 在一致性与及时性上的平衡

各位同仁，下午好！ 今天，我们将深入探讨分布式系统中的一个核心且至关重要的问题：服务发现（Service Discovery）。随着微服务架构的普及，服务数量呈爆炸式增长，服务实例的生命周期也变得高度动态化。如何让这些服务高效、可靠地找到彼此，成为了构建弹性、可伸缩系统必须解决的挑战。 我们将聚焦于当前业界广泛使用的三种服务发现机制：传统的 DNS、以及更现代的分布式键值存储系统 Etcd 和全功能的解决方案 Consul。我们的核心目标是解析它们在一致性（Consistency）与及时性（Timeliness）这对矛盾体上的平衡与取舍。 1. 服务发现的基石：理解其必要性 在单体应用时代，服务间的通信通常通过直接的方法调用或本地进程间通信完成。然而，在微服务架构中，服务被拆分成独立的进程，部署在不同的机器上，甚至跨越不同的数据中心。这些服务的实例数量可能动态伸缩，IP 地址也可能随时变化。 想象一下，一个订单服务需要调用支付服务。如果订单服务硬编码了支付服务的 IP 地址和端口，那么当支付服务实例扩缩容、故障转移或升级时，订单服务将无法找到正确的地址，导致服务中断。服务发现机制正是为 …

继续阅读“解析 Service Discovery（服务发现）：对比 Consul, Etcd 与 DNS 在一致性与及时性上的平衡”

发布于

Java `Service Discovery` (`Eureka`, `Consul`, `Nacos`) 与 `Load Balancing` 策略

各位观众老爷，大家好！今天咱们来聊聊微服务架构里两个密不可分的好基友：服务发现（Service Discovery）和负载均衡（Load Balancing）。这俩哥们儿，一个负责找人，一个负责分活儿，配合得那叫一个天衣无缝，让咱们的微服务集群跑得又稳又快。 一、啥是服务发现？ 想象一下，你开了一家小饭馆（一个微服务），想让顾客（其他微服务）找到你，你得干嘛？ 贴广告（注册）： 在大街上贴个“好吃不贵，欢迎光临”的广告，告诉大家你在哪儿，卖啥。 有人指路（发现）： 有人问路，得有热心群众指路，告诉他们饭馆的具体位置。 服务发现就是干这个事的。它负责： 服务注册（Service Registration）： 微服务启动时，把自己注册到服务注册中心，告诉大家自己的地址（IP地址和端口号）。 服务发现（Service Discovery）： 其他微服务需要调用你的时候，去服务注册中心查你的地址。 为啥要服务发现？ 在传统的单体应用里，服务之间的调用都是硬编码的，直接写死IP地址和端口号。但微服务架构下，服务数量多，实例经常变化（扩容、缩容、重启），硬编码就Hold不住了。服务发现能动态地找到 …

继续阅读“Java `Service Discovery` (`Eureka`, `Consul`, `Nacos`) 与 `Load Balancing` 策略”

发布于

PHP `Service Discovery` (`Consul`/`Etcd`) 与 `Load Balancing` (负载均衡) 策略

各位亲爱的PHPer们，晚上好！我是你们的老朋友，今晚我们来聊聊PHP中的“服务发现”和“负载均衡”这两个好基友。想象一下，你开了一家餐厅，生意火爆，一个厨房根本忙不过来，这时候你是不是要多开几个分店，多请几个厨师？ 服务发现和负载均衡，在微服务架构中，就扮演着“分店管理”和“厨师调度”的角色。 它们确保你的应用能够平稳地应对海量流量，并且在某个服务挂掉的时候，还能优雅地继续提供服务。 一、 什么是服务发现？ 服务发现，顾名思义，就是让服务能够自动找到其他的服务。 在传统的单体应用中，各个模块之间的调用关系是固定的，写死在代码里。 但是在微服务架构中，服务数量众多，IP地址和端口号经常变动，如果还是用写死的方式，维护起来简直是噩梦。 服务发现，就像一个“电话簿”，记录了所有服务的地址信息。 当一个服务需要调用另一个服务时，它会先查阅这个“电话簿”，找到目标服务的地址，然后再发起调用。 1.1 为什么需要服务发现？ 动态性： 微服务架构中，服务实例的数量和位置经常变化。 服务发现可以动态地跟踪这些变化，避免硬编码带来的问题。 弹性： 当某个服务实例挂掉时，服务发现可以自动将其从可用列表中 …

继续阅读“PHP `Service Discovery` (`Consul`/`Etcd`) 与 `Load Balancing` (负载均衡) 策略”

发布于

服务发现（Service Discovery）：Consul, etcd, Kubernetes Native

各位亲爱的程序员朋友们，大家好！我是你们的老朋友，BUG终结者，代码魔法师（其实就是个普通的码农啦🤣），今天我们来聊一个在微服务架构中至关重要，又常常被我们忽略的小可爱——服务发现（Service Discovery）。 想象一下，你经营着一家美食城，里面有各种各样的餐厅，比如川菜馆，粤菜馆，火锅店等等。顾客想吃饭，总不能一家一家敲门问：“请问你家今天卖什么？菜品怎么样？价格如何？” 这效率也太低了吧！ 这时候，你需要一个“美食城导览图”，告诉顾客： 谁在提供什么服务？ (比如：川菜馆提供麻婆豆腐、回锅肉) 他们的地址在哪里？ (比如：川菜馆在A区3号) 他们的健康状况如何？ (比如：川菜馆今天生意兴隆，食材新鲜) 顾客只需要看看导览图，就能快速找到自己想吃的餐厅，这，就是服务发现的雏形！ 在微服务架构中，我们的服务就像这些餐厅一样，数量繁多，地址动态变化，随时可能上线或下线。如果没有一个靠谱的服务发现机制，各个服务之间就无法互相找到对方，整个系统就会陷入一片混乱。 一、没有服务发现的世界：一场噩梦😱 想象一下，如果没有服务发现，我们的微服务们该如何交流呢？ 硬编码： 简直是灾难！每个 …

继续阅读“服务发现（Service Discovery）：Consul, etcd, Kubernetes Native”