Hi That's great.
Does this mean users need to have a clear understanding of how each plugin works? Thanks. On 2020/06/20 02:12:02, YuanSheng Wang <membp...@apache.org> wrote: > This new way is very different from the old one. > > I love this new way. > > According to this idea, plug-ins will be more like micro-plug-ins, and we > can execute these micro-plug-ins one by one by way of arrangement. > > And will make these micro plug-ins become more independent and simple. > > > On Fri, Jun 19, 2020 at 5:26 PM Ming Wen <wenm...@apache.org> wrote: > > > Hello, > > I want to discuss a new idea about plugins, and let me start by explaining > > the existing plugin mechanism, plugins works according to the following > > rules: > > - plugins are executed after the administrator binds them to a route, > > service, unless they are modified again by the admin API > > - plugins are executed in order of priority which hard code > > - plugins are independent of each other, the results of a plu-in will not > > affect another plugin > > > > So, some scenarios are not handled very gracefully by Apache APISIX, such > > as: > > - limit-count for some IPs, and others are unrestricted > > - throw the failed authentication logs to kafka topic A, and others to > > kafka topic B > > - request which block by limit-req need to go through the fault injection > > plugin > > > > For these scenarios, we can now only handle them by creating multiple > > routes, or creating new plugins. > > > > So I think it's time to take `brain` to APISIX to orchestrate plugins. We > > can add an additional plugin orchestrator without any modifications to the > > existing plugins, then we can use decision tree to control plugins. > > > > What do you think? > > > > Thanks, > > Ming Wen, Apache APISIX & Apache SkyWalking > > Twitter: _WenMing > > > > > -- > > *MembPhis* > My GitHub: https://github.com/membphis > Apache APISIX: https://github.com/apache/incubator-apisix >
