I found that my `Architecture design` above was formatted correctly in the mailbox, but was messed up on the mailing list page. So I provide a screenshot https://s2.loli.net/2022/03/12/JxStYqnEmi758dA.png
Jintao Zhang <zhangjin...@apache.org> 于2022年3月12日周六 00:25写道： > Thanks. > > > Is this the repo for the project: github.com/api7/apisix-mesh-agent > <https://github.com/api7/apisix-mesh-agent> ? > > No, that project can be understood as directly putting APISIX into > sidecar. But in fact, no changes have been made in APISIX. > > This is what I want to differentiate in this Proposal as well. I used > `native ability` to differentiate. > > Navendu Pottekkat <navendupottek...@gmail.com> 于2022年3月11日周五 21:05写道： > >> This is great to see. It makes a lot of sense to not build a separate >> service mesh but instead be a replacement to Envoy in Istio. >> >> I think this will make Istio much more extensible and will provide a lot >> of value to the user if we could build and use custom APISIX Plugins in >> the data plane. >> >> Is this the repo for the project: github.com/api7/apisix-mesh-agent >> <https://github.com/api7/apisix-mesh-agent> ? >> >> Looking forward to see this in action. >> >> - Navendu >> >> On 11/03/22 5:47 pm, Jintao Zhang wrote: >> > Background introduction >> > >> > Service mesh is currently the most popular architectural pattern. >> > Especially for the microservice architecture, it is very effective. It >> can >> > be used to manage east-west traffic, improve security, etc. >> > >> > Apache APISIX is a cloud-native high-performance API Gateway that can >> also >> > be used to manage north-south and east-west traffic. >> > >> > However, if the deployment scenario is limited to the Kubernetes >> cluster, >> > we will find that the service mesh solution is more natural and >> flexible. >> > >> > So I want to *bring Apache APISIX to the service mesh world*. >> > >> > There are already multiple solutions for service meshes, and there is >> not >> > much value in implementing a completely new solution. >> > >> > I would like to choose Istio[1], the most popular service mesh >> solution, as >> > the control plane. >> > >> > Uses Apache APISIX as its data plane[2]. >> > *Value* >> > >> > This will generate a lot of value. >> > For APISIX *Community* >> > >> > Introducing Apache APISIX to the service mesh world allows it to have >> more >> > use cases, especially in east-west traffic management, security, and >> > observability. >> > >> > Integrating with Istio is also easier to adopt. >> > For Istio *Community* >> > >> > It can enrich the ecology of Istio. Currently, the default data plane of >> > Istio is Envoy[3], but the learning cost of Envoy is high, and it is >> more >> > complicated to expand and maintain it. >> > >> > In addition, we have done a comparison, APISIX's performance is better >> than >> > Envoy. >> > >> > APISIX and Istio integration, allowing users to have more choices. >> > For end-user >> > >> > We choose Istio as the control plane and only replace the data plane, >> so it >> > is insensitive to user migration. Of course, we will also conduct >> > compatibility testing to make this process more secure and reliable. >> > Architecture design >> > >> > ``` >> > >> |Control-plane--------------------+ >> > | >> | >> > | >> | >> > | Istio >> | >> > | >> | >> > >> +----------------+----------------+ >> > | >> > | >> > >> +-------------------------+-----------------------+ >> > | Discovery >> | >> > | Configuration >> | >> > | Certificates >> | >> > | >> | >> > | >> | >> > +-------------v------------------+ >> > +------------------v-------------+ >> > | | | >> > | >> > | +----------------------------+ | | >> > +----------------------------+ | >> > | | | | | | >> > | | >> > | | +--------------+---------+ | | | | >> > +--------------+---------+ | | >> > Ingress | | | | | | | | | | >> > | | | | Egress >> > --------------+-> | | Amesh | +-+-----------+-> | >> > | Amesh | +-+--------------> >> > Traffic | | | +---------+ | | | | | >> > +---------+ | | Traffic >> > | | |APISIX | | | | | |APISIX >> > | | | >> > | | +------------------------+ | | | | >> > +------------------------+ | | >> > | | | | | | >> > | | >> > | +-----+--------------^-------+ | | >> > +-----+---------------^------+ | >> > | | | | | | >> > | | >> > | +-----v--------------+-------+ | | >> > +-----v---------------+------+ | >> > | | Service A | | | | >> > Service B | | >> > | | | | | | >> > | | >> > | +----------------------------+ | | >> > +----------------------------+ | >> > | | | >> > | >> > +--------------------------------+ >> > +--------------------------------+ >> > ``` >> > >> > >> > >> > concept: >> > >> > - Amesh： It is a Go program that interacts with Istio for the xDS >> > protocol. Will be compiled into a .so file and embedded in APISIX. >> And the >> > configuration will be written directly to the shdict of APISIX. >> > - APISIX: It will read configuration from shdict and no longer need >> to >> > rely on storage like etcd. >> > >> > *Deliverables* >> > >> > When this goal is achieved, we can deliver the following two parts >> > Amesh >> > >> > As mentioned above, this is a Go program that will do the mapping of >> Istio >> > functionality and APISIX configuration >> > APISIX >> > >> > APISIX will modify how the configuration is read. Allows getting >> > configuration information from shdict. >> > *Development Roadmap* >> > >> > TBD >> > > >
