Hi community,
I took some time to dig into `orchestrator`.
Here are some of my thinkings about this product. I'd like to share them with
you.
1. The primary language for this project is `go`. On the other hand,
ShardingSphere is programmed by `JAVA`.
2. The license of `orchestrator` is Apache 2.0, which is friendly to
collaborate.
3. `orchestrator` is a standalone application that provides web service or
command line for discovery, refactoring, and recovery.
4. The feature of the key-values stored Consul or ZooKeeper is just for master
discovery currently.
Here is my conclusion,
In short, `orchestrator` is not the best solution as I expected. Still, we
welcome volunteers to take part in this contribution.
If we want to empower ShardingSphere with HA governance, `orchestrator` is not
the best solution as I expected.
My reason is that `orchestrator` is independent of ShardingSphere and deployed
as a standalone service to provide replication information.
Moreover, kv-store based on Zookeeper only has the master information, not the
whole relationship among the master node and all the slaves.
Otherwise, the server API can do that instead.
Consequently, ShardingSphere will have a firm rely on its web API (Or KV-values
on ZK If we just need master info).
I can not think of a graceful approach to bring it into ShardingSphere
ecosystem.
So, what do you think? Please let me know your innovative ideas.
Best wishes,
Trista
Juan Pan (Trista)
Senior DBA & PMC of Apache ShardingSphere
E-mail: [email protected]
