Agent service discorvery

[EvanLjp]

Please answer these questions before submitting pull request

• Why submit this pull request?

• New feature provided

• Related issues
  build connection between agent client and oap server with service discover #5063

---

New feature or improvement

• Describe the details and related test reports.

[EvanLjp]

I will add unit tests later, thanks for review first

[codecov]

Codecov Report

Merging #5120 into master will decrease coverage by 0.13%.
The diff coverage is 63.88%.

@@             Coverage Diff              @@
##             master    #5120      +/-   ##
============================================
- Coverage     53.08%   52.94%   -0.14%     
+ Complexity     3166     3163       -3     
============================================
  Files           820      822       +2     
  Lines         20508    20531      +23     
  Branches       1972     1976       +4     
============================================
- Hits          10887    10871      -16     
- Misses         8739     8776      +37     
- Partials        882      884       +2     

Impacted Files	Coverage Δ	Complexity Δ
...apache/skywalking/apm/agent/core/boot/Address.java	35.71% <35.71%> (ø)	2.00 <2.00> (?)
.../agent/core/discovery/DefaultDiscoveryService.java	76.92% <76.92%> (ø)	7.00 <7.00> (?)
...king/apm/agent/core/remote/GRPCChannelManager.java	55.40% <88.88%> (-1.01%)	13.00 <1.00> (+1.00)	⬇️
...er/core/server/auth/AuthenticationInterceptor.java	0.00% <0.00%> (-61.54%)	0.00% <0.00%> (-3.00%)
...er/sharing/server/ReceiverGRPCHandlerRegister.java	30.76% <0.00%> (-46.16%)	2.00% <0.00%> (-3.00%)
...ap/server/core/server/GRPCHandlerRegisterImpl.java	62.50% <0.00%> (-25.00%)	2.00% <0.00%> (-1.00%)
...r/cluster/plugin/standalone/StandaloneManager.java	77.77% <0.00%> (-22.23%)	3.00% <0.00%> (-1.00%)
...apm/agent/core/remote/ServiceManagementClient.java	60.37% <0.00%> (-13.21%)	9.00% <0.00%> (-1.00%)
...rg/apache/skywalking/apm/agent/core/os/OSUtil.java	62.71% <0.00%> (-5.09%)	10.00% <0.00%> (-2.00%)
...ing/oap/server/library/server/grpc/GRPCServer.java	55.93% <0.00%> (-5.09%)	6.00% <0.00%> (-1.00%)
... and 5 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 118e334...1c83209. Read the comment docs.

[EvanLjp]

fixing unit test,please wait for a moment

[wu-sheng]

I think I mentioned before, neither service discovery tech should not be bounded in the agemt core level. If you want to contribute this feature, you need to put it as an optional plugin only. Take a look on Kafka transport plugin and zipkin branch.

[wu-sheng]

Don't change the backend serive url config, it will break many deployed system. Please don't do that.

[EvanLjp]

I think I mentioned before, neither service discovery tech should not be bounded in the agemt core level. If you want to contribute this feature, you need to put it as an optional plugin only. Take a look on Kafka transport plugin and zipkin branch.
@wu-sheng
it is designed as a plugin mode:

[EvanLjp]

so i cannot extension with service mode , i would be add a new extension interface ?

[wu-sheng]

The concern is, the default config changed. And new backend service path added. This would be very confused. How to write plugin doc would be an issue.

[EvanLjp]

The concern is, the default config changed. And new backend service path added. This would be very confused. How to write plugin doc would be an issue.

how about this mode:
origin backend url is as default.the extension discovery is in Service Discovery

[wu-sheng]

By thinking the PR and Kafka transport PR, I prefer you work on a new PR.
Introduce a new SPI service, called ConfigInitService. All plugins and core could provide their services. Then you could separate the current Config in the core and different plugins.
Notice, all config keys should be kept as much as possible.

What do you think? @dmsolr @kezhenxu94 @arugal @EvanLjp

Let's make that decision first, then back to this feature.

[wu-sheng]

@EvanLjp Yes, this one and #4847 show, the config of different plugins have been keeping added into the core Config. I want to remove this first. That is the reason I talked about ConfigInitService(not a BootService).

[EvanLjp]

i open a new issue first

[wu-sheng]

Once we have this feature, this plugin will be more elegant, because there will be no code changed in the agent core, purely plugin. Same as the Kafka transport plugin.

[EvanLjp]

I wonder if the plug-in configuration needs to be refactored,for example mysql

[wu-sheng]

I wonder if the plug-in configuration needs to be refactored,for example mysql

At the code level, yes. But you still could keep the config name unchanged. You just create more Config classes in different plugins.

[EvanLjp]

no porblem , i would like be to open a new issue first

[wu-sheng]

I think you could improve this PR now. I have set up the new Config initialization core.

[EvanLjp]

ok

[wu-sheng]

Do we still plan to do this? I think we discussed, cliemt load balance is not a very good way. It is hard to be balaned.

[EvanLjp]

i read the oap code and agent code. oap transform data from one oap server to another oap server is get client form a grpc client pool. so oap server can load balance.
why not we still maintain the mode in agent.
we create a grpc clients manager,when transform data ,we random get a client

[EvanLjp]

Do we still plan to do this? I think we discussed, cliemt load balance is not a very good way. It is hard to be balaned.

i don't think keep alive one by one is a good way.Don't you think this is not a skywalking's current problem?Why don't we try to optimize?

[wu-sheng]

Rechecking, whether this feature should be or is planned to continue? It has been no update for a month.

[EvanLjp]

may be close is a good choose, thx