update one figure

usecases/service-discovery-in-microservices.md

@@ -9,24 +9,24 @@
 这两种架构都各有利弊，我们拿客户端服务发现软件 Eureka 和服务端服务发现架构 Kubernetes/SkyDNS + Ingress LB + Traefik + PowerDNS 为例说明。
 
 | 服务发现方案 | Pros                                                         | Cons                                                         |
-| :--------- | ---------------------------------------- | ---------------------------------------- |
+| :----------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
-| Eureka     | 使用简单，适用于java语言开发的项目，比服务端服务发现少一次网络跳转      | 对非Java语言的支持不够好，Consumer需要内置特定的服务发现客户端和发现逻辑 |
+| Eureka       | 使用简单，适用于 Java 语言开发的项目，比服务端服务发现少一次网络跳转 | 对非 Java 语言的支持不够好，Consumer 需要内置特定的服务发现客户端和发现逻辑 |
 | Kubernetes   | Consumer 无需关注服务发现具体细节，只需知道服务的 DNS 域名即可，支持异构语言开发 | 需要基础设施支撑，多了一次网络跳转，可能有性能损失           |
 
-**Eureka** 也不是单独使用的，一般会配合 ribbon 一起使用，ribbon 作为路由和负载均衡。
+**Eureka** 也不是单独使用的，一般会配合 Ribbon 一起使用，Ribbon 作为路由和负载均衡。
 
 **Ribbon**提供一组丰富的功能集：
 
-- 多种内建的负载均衡规则：
+- 多种内置的负载均衡规则：
-  - Round-robin 轮询负载均衡
+  - 轮询负载均衡
   - 平均加权响应时间负载均衡
   - 随机负载均衡
   - 可用性过滤负载均衡（避免跳闸线路和高并发链接数）
   - 自定义负载均衡插件系统
 - 与服务发现解决方案的可拔插集成（包括 Eureka）
 - 云原生智能，例如可用区亲和性和不健康区规避
-- 内建的故障恢复能力
+- 内置的故障恢复能力
 
 ## 参考
 
-- [谈服务发现的背景、架构以及落地方案](http://www.infoq.com/cn/articles/background-architecture-and-solutions-of-service-discovery)
+- [谈服务发现的背景、架构以及落地方案 - infoq.cn](https://www.infoq.cn/article/background-architecture-and-solutions-of-service-discovery/)