Lazy export will start multi server / Making all export/refer process serial.

[bohrqiu]

What is the purpose of the change

fix some dubbo bug

Brief changelog

1. lazy export will start multi server
2. tuning spring event performance
3. clean FailbackRegistry resouces

Verifying this change

XXXX

Follow this checklist to help us incorporate your contribution quickly and easily:

• Make sure there is a GITHUB_issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
• Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
• Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test to make sure integration-test pass.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

[CLAassistant]

All committers have signed the CLA.

[chickenlj]

tuning spring event performance

I've fixed this with commit 89b4771

lazy export will start multi server

We're considering solve this by turning all export/refer process serial.
also see this issue #677

[chickenlj]

clean FailbackRegistry resouces

The thread here is daemon, and this is not a critical operation that have to wait.

[bohrqiu]

We're considering solve this by turning all export/refer process serial.

why do this？

when there are hundreds of providers/consumer，the startup performance will be slow.

in our internal version:

[bohrqiu]

in our internal version,i have enhance dubbo includes the following：

1. hessian data compress for across datacenter invokes.

2. export/refer concurrent

3. dubbo local cache .

dubbo consumer invoke redis first,when cache missing,invoke remote serivce. it use spring el compute key.

[chickenlj]

Your project cost more than 147s to finish start? Is there any time costing initialization process in your service bean?
Is the cost mainly on the consumer side, waiting for the registry notification of providers and establish connection? If so, maybe we can make the notification process(time costing) asynchronous.

[chickenlj]

dubbo local cache .

You used dubbo's Cache SPI to achieve this?

[bohrqiu]

Is the cost mainly on the consumer side, waiting for the registry notification of providers and establish connection? If so, maybe we can make the notification process(time costing) asynchronous.

yes,when consumer side refer service,it will establish connection and access registry center,it be better async refer

[bohrqiu]

You used dubbo's Cache SPI to achieve this?

it use filter,spring el+redis .

[ralf0131]

Please resolve the conflicts.

[beiwei30]

@bohrqiu I checked all your changes, and found the similar changes have been made for ServiceBean and FailbackRegistry, and because there's conflict, I manually submit your change made against DubboProtocol, see #1916.

[beiwei30]

@bohrqiu for other enhancements you mentioned on this PR, would you mind to submit more PRs?

[bohrqiu]

@beiwei30 , I will open new PRs, close this PR ,thanks

[beiwei30]

looking forward to