So what about the “route” itself? Its also have upstream, plugins, etc. What’s a really service should be? It’s must provider some businesses or abilities rather than a group of route rules alright?
| | idevz | | [email protected] | Idevz.org github.com/idevz On 10/29/2019 17:18，Zhiyuan Ju<[email protected]> wrote： According to the description of Service[1] here, I would prefer keeping the current Name. Because one service of APISIX here not only includes a group of routes but also has upstream, plugins, etc. [1] https://github.com/apache/incubator-apisix/blob/master/doc/architecture-design.md#service Best Regards! @ Zhiyuan Ju zhoujingk_49 <[email protected]> 于2019年10月29日周二 下午4:36写道： I couldn’t concept your reason as “there is also `service` in Kong”, we’re ApiSix not Kong. We should not forgot that the “service” in APISix is just a truly “route set". We should face the truth. | | idevz | | [email protected] | Idevz.org github.com/idevz On 10/29/2019 16:32，YuanSheng Wang<[email protected]> wrote： Hi: I thought about it, there is also `service` in Kong, and here we are almost the same. So I prefer to continue using `service`. On Tue, Oct 29, 2019 at 10:45 AM zhoujingk_49 <[email protected]> wrote: Hi folks! As we know Apisix is one of an Cloud Native APIGateway, and one of the most important about Cloud Native is Does our Apisix is friendly enough with Kubernetes？ We all know “ service" is an important concept in Kubernetes, it's an abstraction of pods. It's truly about describing a service things, provider something ability to others. But the “Service” in Apisix, I wandering more of A router set than a Service. And a Apisix “service” would make someone confused when using Apisix in Kubernetes environment. So, what’s your opinion? | | idevz | | [email protected] | Idevz.org github.com/idevz -- *MembPhis* My github: https://github.com/membphis Our Book: OpenResty Best Practices <https://www.gitbook.com/book/moonbingbing/openresty-best-practices>
