You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@servicecomb.apache.org by "liubao (Jira)" <ji...@apache.org> on 2020/08/21 01:21:00 UTC

[jira] [Commented] (SCB-1929) provide new mechanism: Filter

    [ https://issues.apache.org/jira/browse/SCB-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17181515#comment-17181515 ] 

liubao commented on SCB-1929:
-----------------------------

This feature scheduled to 3.0.0 and will not be visible in 2.x

> provide new mechanism: Filter
> -----------------------------
>
>                 Key: SCB-1929
>                 URL: https://issues.apache.org/jira/browse/SCB-1929
>             Project: Apache ServiceComb
>          Issue Type: New Feature
>          Components: Java-Chassis
>            Reporter: Jimin Wu
>            Assignee: liubao
>            Priority: Major
>             Fix For: java-chassis-3.0.0
>
>
> currently, we have extensions:
>  # HttpClientFilter
>  # HttpServerFilter
>  # Handler
>  # ProducerInvokeExtension
> and we hard code to invoke all the extensions:
>  # consumer:
>  ## invoke all handlers
>  ## invoke all HttpClientFilters
>  # producer:
>  ## schedule to operation related executor
>  ## invoke all HttpServerFilters
>  ## invoke all handlers
> PROBLEMS:
>  # all these extensions are about invocation, just have different prototype
>  # for consumer
>  ## when a sync invocation failed, and want to retry, retry schedule is conflict to sync mechanism
>  # for producer
>  ## qps-limiter should invoke before schedule, currently we hard code it
>  ## if want to write reactive extension before schedule, to not care for controller method is sync or async, currently can not do it
>  ## if executor is a real thread pool, and a reactive extension after schedule will break thread schedule plan, that maybe will cause block event loop
>  # exception convert only avaiable for controller method invoke, but all extensions exception need convert too
> SOLUTION:
> provide new mechanism: Filter, to unify all the extensions, and change main invocation process flow from hard code to by configuration
>  # prototype:
> {code:java}
> public @interface FilterMeta {
>   String name();
>   /**
>    *
>    * @return can be used for the specific invocation type
>    */
>   InvocationType[] invocationType() default {CONSUMER, PRODUCER};
>   /**
>    *
>    * @return true to use same instance for each filter chain
>    */
>   boolean shareable() default true;
> }
> public interface Filter {
>   CompletableFuture<Response> onFilter(Invocation invocation, FilterNode nextNode);
> }
> {code}
>  # configuration
> {code:java}
> servicecomb:
>   filter-chains:
>     enabled: true
>     transport-filters:
>       #default-consumer-transport:
>       #  rest: rest-client-codec
>       #  highway: highway-client-codec
>       default-producer-tranport:
>         rest: rest-server-codec
>         highway: highway-server-codec
>     consumer:
>       default: simple-load-balance
>       #default: simple-load-balance, default-consumer-transport, transport-client
>       # samples for customize microservice filter chain
>       #policies:
>       #  ms-1: retry, load-balance, transport-client, ms-1-consumer-transport
>     producer:
>       default: default-producer-tranport, schedule, producer-operation
>       # samples for customize microservice filter chain
>       #policies:
>       #  ms-1: qps-limiter, ms-1-producer-transport, schedule, producer-operation
> {code}
>  ## customize full flow of invocation
>  ## microservice scope chain
>  ## schema or operation scope chain, if have requirements in the future
>  ## invoke exception converter when throwing a exception for all filter
> COMPATIBLE:
>  # wrap old HttpClientFilters to a Filter
>  # wrap old HttpServerFilters to a Filter
>  # wrap old consumer handlers to a Filter
>  # wrap old producer handlers to a Filter
>  # pre-define old filter chains, and default to old chains



--
This message was sent by Atlassian Jira
(v8.3.4#803005)