I suggest APISIX abstract config-center interface. The APISIX implementation is based on this config-center.
The config-center supports a variety of implementation methods. Which can be implemented by etcd, redis, or even MySQL(consider supporting DB that do not support push). In addition, because the implementation of APISIX itself is LUA, the basic components are relatively small. Combined with Chao Zhang’s proposal, APISIX can also consider design own’s protocal for the agent service. The agent connect the DB, which lua is difficultal connecting. Ming Wen <[email protected]> 于2021年4月28日周三 下午4:08写道： > I agreed with Sheng. > In the long term, Apache APISIX should have an independent protocol, > so that other data storage components can adapt to Apache APISIX, > not only Apache APISIX to adapt others. > > Thanks, > Ming Wen, Apache APISIX PMC Chair > Twitter: _WenMing > > > Sheng Wu <[email protected]> 于2021年4月27日周二 上午10:17写道： > > > I know this. So, I just said suggest reconsidering > > This is a typical style of a top-level open source project doing. > > Protocol is the key to a community, once you(APISIX) lead on both sides, > it > > is better the protocol is something we could make decisions when changes > > are required in the future. > > > > Sheng Wu 吴晟 > > Twitter, wusheng1108 > > > > > > Chao Zhang <[email protected]> 于2021年4月27日周二 上午10:12写道： > > > > > Hi, > > > > > > We want to pretend the agent is an ETCD cluster so that we don't need > > > any modifications on APISIX side, and actually etcd v3 API is based on > > > gRPC. > > > > > > Best regards > > > Chao Zhang > > > > > > https://github.com/tokers > > > > > > On Tue, Apr 27, 2021 at 9:58 AM Sheng Wu <[email protected]> > > > wrote: > > > > > > > > Basically, I like this idea, just suggest reconsidering whether keep > on > > > > etcd API, especially gRPC tech stack is already there. > > > > APISIX works with its agent but using etcd protocol? This seems > > strange. > > > > > > > > Sheng Wu 吴晟 > > > > Twitter, wusheng1108 > > > > > > > > > > > > Chao Zhang <[email protected]> 于2021年4月27日周二 上午9:46写道： > > > > > > > > > Hi, there > > > > > > > > > > Below is the proposal about how to support multiple data centers > for > > > > > Apache APISIX. Please review it and your advice will be > appreciated. > > > > > > > > > > Background > > > > > > > > > > So far, APISIX only supports fetching configurations like Route, > > > > > Upstream from ETCD, although it’s capable of integrating a couple > of > > > > > service registries (e.g. Consul, Nacos) to discover backend service > > > > > endpoints (aka upstream nodes) dynamically. > > > > > > > > > > For some users, ETCD is not their optimal solution as they may > > already > > > > > have another similar data center or they don’t master the skill for > > > > > ETCD cluster maintenance. In such a case, introducing APISIX to > their > > > > > platform will be stumbling, even letting them give up on using it. > > > > > > > > > > So from this perspective, making APISIX decouple from ETCD is > > > > > important, it also enriches the ecosystem of APISIX. > > > > > > > > > > Self Adjustment > > > > > > > > > > The most intuitive way is evolving APISIX itself, letting it as the > > > > > client of the target data center, so no extra components will be > > > > > deployed, what administrators need to do is configuring the data > > > > > center in the configuration of APISIX, including address, > > > > > authentication and so on. > > > > > > > > > > That’s good but the overheads to change APISIX is huge, firstly, > the > > > > > protocol used in each data center might vary, considering the weak > > > > > ecosystem of OpenResty/Nginx, we may need to implement the data > > center > > > > > SDK manually, and it will be tracky for some multiplexing protocols > > > > > (due to the connection pool model of OpenResty); On the other hand, > > > > > The APISIX internal is tightly coupled with ETCD, it’s not easy to > > > > > decouple them from the code level, what’s more, these part of codes > > > > > now are very stable, changing them might influence the stability of > > > > > APISIX. > > > > > > > > > > Agent Mode > > > > > > > > > > > All Problems in Computer Science can be solved by another level > of > > > > > indirection. > > > > > > > > > > Since it’s not easy to support this from APISIX itself, why not > > > > > introducing another component, it supports to communicate with any > > > > > data centers, and it mimics the ETCD V3 APIs and gRPC gateway, so > > that > > > > > it can pretend itself as the ETCD cluster from APISIX’s point of > > view. > > > > > With that a component, there is nothing that should be done in > APISIX > > > > > itself (You can see the architecture figure in the attachments). > > > > > > > > > > Agents can be deployed in any place as the networking is connected > > for > > > > > both the APISIX and data centers sides. It should be designed as > > > > > stateless, so APISIX can configure multiple agent instances and the > > > > > high availability can be sure. It can be even deployed for each > > APISIX > > > > > instance, that’s the famous sidecar mode. > > > > > > > > > > Problems need to be addressed > > > > > > > > > > The agent component has to solve a series of problems so it can > > > > > achieve its mission. Firstly, it should implement the server side > of > > > > > ETCD V3 APIs. Fortunately, only minor parts of features are used by > > > > > APISIX, so the implementation won’t be too complicated, also, since > > > > > APISIX relis on the ETCD gRPC gateway, the agent should also > support > > > > > it, in general, that’s not too difficult as the gRPC ecosystem is > > > > > strong. > > > > > > > > > > Secondly, the internal design of the agent should be modular as > soon > > > > > as possible, so once we need to support a new data center, the > > > > > development would be easy. Of course that’s another topic and will > > not > > > > > be detailed in this post. > > > > > > > > > > Best regards > > > > > Chao Zhang > > > > > > > > > > https://github.com/tokers > > > > > > > > > > > --
