You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@servicecomb.apache.org by "Jimin Wu (Jira)" <ji...@apache.org> on 2020/06/03 08:15:00 UTC
[jira] [Updated] (SCB-1929) provide new mechanism: Filter
[ https://issues.apache.org/jira/browse/SCB-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jimin Wu updated SCB-1929:
--------------------------
Description:
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
was:
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 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
consumer:
rest:
default: simple-load-balance, transport-client
policies:
ms-1: simple-retry, load-balance, transport-client
producer:
rest:
default: rest-server-codec, schedule, producer-operation
policies:
ms-2: qps-limiter, rest-server-codec, 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
> 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: Jimin Wu
> Priority: Major
> Fix For: java-chassis-2.1.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)