+1,
Simplify design and implements.
In general cases, zk is enough.
In cncf env cases, etcd could be another choice.

At 2021-02-20 16:08:49, "Yu Xiao" <xia...@apache.org> wrote:
>Hi, Friends from all communities:
>
>Governance Module is a very important module for ShardingSphere.
>
>In Governance Module, There are two very important roles : RegisterCenter,
>ConfigCenter  There are implemented By JAVA SPI.
>
>Today, we need to discuss whether we should remove Nacos and Apollo
>ConfigCenter   support.
>
>So, Let's  look at the current support.
>
>RegisterCenter support:
>
>1. Zookeeper
>2. Etcd (Distributed lock not implemented)
>
>ConfigCenter support:
>
>1. Zookeeper
>2. Etcd
>3. Apollo
>4. Nacos
>
>
>Yaml config api :
>
>governance:
>  name: governance
>  registryCenter:
>    type: ZooKeeper  ## etcd
>    serverLists: localhost:2181
>    props:
>      retryIntervalMilliseconds: 500
>   additionalConfigCenter:
>     type: ZooKeeper  ## etcd apollo or nacos
>     serverLists: localhost:2181
>     props:
>       retryIntervalMilliseconds: 500
>
>
>If the user used ZooKeeper and Etcd as a registryCenter and ConfigCenter,
>can not config `additionalConfigCenter` like this:
>
>governance:
>  name: governance_ds
>  registryCenter:
>    type: ZooKeeper  ## etcd
>    serverLists: localhost:2181
>    props:
>      retryIntervalMilliseconds: 500
>
>
>reason 1: To simplify configuration, we should remove Apollo and Nacos
>support?
>
>Now, registryCenter and Distributed lock, This is very important for
>ShardingSphere clusters.
>
>We couldn't and shouldn't have implemented it for Apollo and Nacos.
>
>We didn't have to do technical support for Apollo and Nacos. If the user
>wants to use them, implement By JAVA SPI.
>
>reason 2: Unsupported registryCenter function and Distributed lock , we
>should remove Apollo and Nacos support?
>
>
>My suggested solution :
>
>1. remove Apollo and Nacos ConfigCenter support. and remove
>additionalConfigCenter props.
>
>2. Apollo and Naocs Empty implementation registryCenter function, and
>Distributed lock (We need to inform users of the risks).
>
>
>Above, welcome to receive your suggestion!

Reply via email to