yzeng25 commented on code in PR #1405: URL: https://github.com/apache/apisix-website/pull/1405#discussion_r1021250002
########## blog/zh/blog/2022/11/10/what-is-service-in-microservice-discovery.md: ########## @@ -0,0 +1,122 @@ +--- +title: "微服务中的服务发现是什么" +author: "罗泽轩" +authorURL: "https://github.com/spacewander"; +authorImageURL: "https://github.com/spacewander.png"; +keywords: +- 微服务 +- 服务发现 +- 开源 +- APISIX +- Nacos +description: 本文通过服务发现的相关背景和 APISIX 对于服务发现的应用与实践，来介绍微服务中的服务发现内容。 +tags: [Ecosystem] +--- + +> 本文通过服务发现的相关背景和 APISIX 对于服务发现的应用与实践，来介绍微服务中的服务发现内容。 + +<!--truncate--> + +## 服务发现是什么？为什么需要？ + +在互联网刚开始出现的年代，人们要想访问某个在线服务，需要输入一长串的 IP 地址。IP 地址虽然不长，但是作为一串无意义的数字，要求记住特定服务的特定地址还是很考验人的记忆力。所以后来人们就发明了域名系统。每个在线服务会到域名商注册一个域名，然后通过 DNS 建立域名和具体 IP 的联系。这样一来，人们只需要输入一个好记的域名，就能访问到具体 IP 上的在线服务。这就是最早的服务发现。 + +当一个公司内部的服务数到了一定的规模（比如在做了微服务拆分之后），也会遇到 IP 实在不好记的问题。这时候就需要有一套服务发现系统。公司里面各个服务在该系统上注册，然后想要访问这些服务的其他服务会从该系统上查询对应的 IP 地址，这样就不需要让某个服务“记住”复杂多变的 IP 地址了。 + +如下图，IP 地址的变更，会让访问者无所适从。 + + Review Comment: You need to update the image, the current one has a grey line on the left side. Just crop that out. <img width="912" alt="image" src="https://user-images.githubusercontent.com/36651058/201622311-fb4483e8-0078-49ba-8110-c21c54f0c342.png";> ########## blog/zh/blog/2022/11/10/what-is-service-in-microservice-discovery.md: ########## @@ -0,0 +1,122 @@ +--- +title: "微服务中的服务发现是什么" +author: "罗泽轩" +authorURL: "https://github.com/spacewander"; +authorImageURL: "https://github.com/spacewander.png"; +keywords: +- 微服务 +- 服务发现 +- 开源 +- APISIX +- Nacos +description: 本文通过服务发现的相关背景和 APISIX 对于服务发现的应用与实践，来介绍微服务中的服务发现内容。 +tags: [Ecosystem] +--- + +> 本文通过服务发现的相关背景和 APISIX 对于服务发现的应用与实践，来介绍微服务中的服务发现内容。 + +<!--truncate--> + +## 服务发现是什么？为什么需要？ + +在互联网刚开始出现的年代，人们要想访问某个在线服务，需要输入一长串的 IP 地址。IP 地址虽然不长，但是作为一串无意义的数字，要求记住特定服务的特定地址还是很考验人的记忆力。所以后来人们就发明了域名系统。每个在线服务会到域名商注册一个域名，然后通过 DNS 建立域名和具体 IP 的联系。这样一来，人们只需要输入一个好记的域名，就能访问到具体 IP 上的在线服务。这就是最早的服务发现。 + +当一个公司内部的服务数到了一定的规模（比如在做了微服务拆分之后），也会遇到 IP 实在不好记的问题。这时候就需要有一套服务发现系统。公司里面各个服务在该系统上注册，然后想要访问这些服务的其他服务会从该系统上查询对应的 IP 地址，这样就不需要让某个服务“记住”复杂多变的 IP 地址了。 + +如下图，IP 地址的变更，会让访问者无所适从。 + + + +通过引入域名系统作为服务发现机制，现在可以灵活对待 IP 的变更了。 + + + +## 常见服务发现系统介绍 + +鉴于本人的能力有限，本文内容仅介绍了与 APISIX 相关的，还请各位多多见谅。 + +作为一个服务发现系统，它需要满足至少四个功能： + +1. 提供注册的 API +2. 提供查询的 API +3. 高可用，毕竟服务发现系统是整个系统的神经，不能麻痹甚至瘫痪。 +4. 生态。众所周知，程序员是一群很懒惰的人，最好希望有个库，引入进来就能跟 API 完成对接。 + +下面让我们来看看市面上主流的几个开源服务发现系统： Review Comment: ```suggestion 下面让我们来看看市面上主流的几个开源服务发现系统。 ``` ########## blog/zh/blog/2022/11/10/what-is-service-in-microservice-discovery.md: ########## @@ -0,0 +1,122 @@ +--- +title: "微服务中的服务发现是什么" +author: "罗泽轩" +authorURL: "https://github.com/spacewander"; +authorImageURL: "https://github.com/spacewander.png"; +keywords: +- 微服务 +- 服务发现 +- 开源 +- APISIX +- Nacos +description: 本文通过服务发现的相关背景和 APISIX 对于服务发现的应用与实践，来介绍微服务中的服务发现内容。 +tags: [Ecosystem] +--- + +> 本文通过服务发现的相关背景和 APISIX 对于服务发现的应用与实践，来介绍微服务中的服务发现内容。 + +<!--truncate--> + +## 服务发现是什么？为什么需要？ + +在互联网刚开始出现的年代，人们要想访问某个在线服务，需要输入一长串的 IP 地址。IP 地址虽然不长，但是作为一串无意义的数字，要求记住特定服务的特定地址还是很考验人的记忆力。所以后来人们就发明了域名系统。每个在线服务会到域名商注册一个域名，然后通过 DNS 建立域名和具体 IP 的联系。这样一来，人们只需要输入一个好记的域名，就能访问到具体 IP 上的在线服务。这就是最早的服务发现。 + +当一个公司内部的服务数到了一定的规模（比如在做了微服务拆分之后），也会遇到 IP 实在不好记的问题。这时候就需要有一套服务发现系统。公司里面各个服务在该系统上注册，然后想要访问这些服务的其他服务会从该系统上查询对应的 IP 地址，这样就不需要让某个服务“记住”复杂多变的 IP 地址了。 + +如下图，IP 地址的变更，会让访问者无所适从。 + + + +通过引入域名系统作为服务发现机制，现在可以灵活对待 IP 的变更了。 + + + +## 常见服务发现系统介绍 + +鉴于本人的能力有限，本文内容仅介绍了与 APISIX 相关的，还请各位多多见谅。 + +作为一个服务发现系统，它需要满足至少四个功能： + +1. 提供注册的 API +2. 提供查询的 API +3. 高可用，毕竟服务发现系统是整个系统的神经，不能麻痹甚至瘫痪。 +4. 生态。众所周知，程序员是一群很懒惰的人，最好希望有个库，引入进来就能跟 API 完成对接。 Review Comment: ```suggestion 4. 生态，众所周知，程序员是一群很懒惰的人，最好有一个库，引入进来就能跟 API 完成对接。 ``` ########## blog/zh/blog/2022/11/10/what-is-service-in-microservice-discovery.md: ########## @@ -0,0 +1,122 @@ +--- +title: "微服务中的服务发现是什么" +author: "罗泽轩" +authorURL: "https://github.com/spacewander"; +authorImageURL: "https://github.com/spacewander.png"; +keywords: +- 微服务 +- 服务发现 +- 开源 +- APISIX +- Nacos +description: 本文通过服务发现的相关背景和 APISIX 对于服务发现的应用与实践，来介绍微服务中的服务发现内容。 +tags: [Ecosystem] +--- + +> 本文通过服务发现的相关背景和 APISIX 对于服务发现的应用与实践，来介绍微服务中的服务发现内容。 + +<!--truncate--> + +## 服务发现是什么？为什么需要？ + +在互联网刚开始出现的年代，人们要想访问某个在线服务，需要输入一长串的 IP 地址。IP 地址虽然不长，但是作为一串无意义的数字，要求记住特定服务的特定地址还是很考验人的记忆力。所以后来人们就发明了域名系统。每个在线服务会到域名商注册一个域名，然后通过 DNS 建立域名和具体 IP 的联系。这样一来，人们只需要输入一个好记的域名，就能访问到具体 IP 上的在线服务。这就是最早的服务发现。 + +当一个公司内部的服务数到了一定的规模（比如在做了微服务拆分之后），也会遇到 IP 实在不好记的问题。这时候就需要有一套服务发现系统。公司里面各个服务在该系统上注册，然后想要访问这些服务的其他服务会从该系统上查询对应的 IP 地址，这样就不需要让某个服务“记住”复杂多变的 IP 地址了。 + +如下图，IP 地址的变更，会让访问者无所适从。 + + + +通过引入域名系统作为服务发现机制，现在可以灵活对待 IP 的变更了。 + + + +## 常见服务发现系统介绍 + +鉴于本人的能力有限，本文内容仅介绍了与 APISIX 相关的，还请各位多多见谅。 + +作为一个服务发现系统，它需要满足至少四个功能： + +1. 提供注册的 API +2. 提供查询的 API +3. 高可用，毕竟服务发现系统是整个系统的神经，不能麻痹甚至瘫痪。 +4. 生态。众所周知，程序员是一群很懒惰的人，最好希望有个库，引入进来就能跟 API 完成对接。 + +下面让我们来看看市面上主流的几个开源服务发现系统： + +### Consul + +[Consul](https://github.com/hashicorp/consul) 是由著名的开源项目孵化公司 Hashicorp 开发的服务发现系统。作为一个在 2014 年 4 月 17 日就发布了第一版的老牌软件，Consul 有着最为丰富的生态，甚至有第三方开发者为它开发了 Haskell 的 SDK。大部分 Consul 的 SDK 只是对其 HTTP API 的封装，所以其实开发量并不大。 + +Consul 支持通过 HTTP API 来完成服务的注册和查询。它支持在查询时通过 HTTP long polling 来实现及时的数据推送，避免轮询。此外 Consul 也支持通过 DNS 的方式查询对应服务的实例。 + +Consul 的部署方式比较有趣。Consul 的每个实例叫做 agent，它既可以是客户端，也可以是服务端。在客户端，Consul 会维持一个客户端的状态；对于服务端， Consul 通过一致性算法 Raft，支持分布式部署，以此来实现高可用。 + +### Eureka + +[Eureka](https://github.com/Netflix/eureka) 是由 Netflix 开源出来的项目。它也是相当地古老 —— 有迹可循的[提交](https://github.com/Netflix/eureka/commit/53939453474e39a8a68236f940c72de043ea20bd)可以追溯到 2012 年。不过这个项目已经有 1 年不维护了。许多用户迁移到下文会提到的 Nacos 上面。 Review Comment: ```suggestion [Eureka](https://github.com/Netflix/eureka) 是由 Netflix 开源出来的项目。它也是相当的古老 —— 有迹可循的[提交](https://github.com/Netflix/eureka/commit/53939453474e39a8a68236f940c72de043ea20bd)可以追溯到 2012 年。不过这个项目已经有 1 年不维护了。许多用户迁移到下文会提到的 Nacos 上面。 ``` ########## blog/zh/blog/2022/11/10/what-is-service-in-microservice-discovery.md: ########## @@ -0,0 +1,122 @@ +--- +title: "微服务中的服务发现是什么" +author: "罗泽轩" +authorURL: "https://github.com/spacewander"; +authorImageURL: "https://github.com/spacewander.png"; +keywords: +- 微服务 +- 服务发现 +- 开源 +- APISIX +- Nacos +description: 本文通过服务发现的相关背景和 APISIX 对于服务发现的应用与实践，来介绍微服务中的服务发现内容。 +tags: [Ecosystem] +--- + +> 本文通过服务发现的相关背景和 APISIX 对于服务发现的应用与实践，来介绍微服务中的服务发现内容。 + +<!--truncate--> + +## 服务发现是什么？为什么需要？ + +在互联网刚开始出现的年代，人们要想访问某个在线服务，需要输入一长串的 IP 地址。IP 地址虽然不长，但是作为一串无意义的数字，要求记住特定服务的特定地址还是很考验人的记忆力。所以后来人们就发明了域名系统。每个在线服务会到域名商注册一个域名，然后通过 DNS 建立域名和具体 IP 的联系。这样一来，人们只需要输入一个好记的域名，就能访问到具体 IP 上的在线服务。这就是最早的服务发现。 + +当一个公司内部的服务数到了一定的规模（比如在做了微服务拆分之后），也会遇到 IP 实在不好记的问题。这时候就需要有一套服务发现系统。公司里面各个服务在该系统上注册，然后想要访问这些服务的其他服务会从该系统上查询对应的 IP 地址，这样就不需要让某个服务“记住”复杂多变的 IP 地址了。 + +如下图，IP 地址的变更，会让访问者无所适从。 + + + +通过引入域名系统作为服务发现机制，现在可以灵活对待 IP 的变更了。 + + + +## 常见服务发现系统介绍 + +鉴于本人的能力有限，本文内容仅介绍了与 APISIX 相关的，还请各位多多见谅。 + +作为一个服务发现系统，它需要满足至少四个功能： + +1. 提供注册的 API +2. 提供查询的 API Review Comment: follow the pattern ```suggestion 1. 提供注册的 API。 2. 提供查询的 API。 ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
![https://github.com/spacewander.png"](https://github.com/spacewander.png"){kind=link}
![https://user-images.githubusercontent.com/36651058/201622311-fb4483e8-0078-49ba-8110-c21c54f0c342.png"](https://user-images.githubusercontent.com/36651058/201622311-fb4483e8-0078-49ba-8110-c21c54f0c342.png"){kind=link}
