Should we divide the orange into different parts

[syhily]

Orange 我昨晚睡前還在想。當初做的 Admin API 似乎有點多餘。在集群模式下，關鍵是同步更新，一個單獨部署的管理程序，比較有意義。修改後，不要立刻生效，然後結合一些手段，依次更新。也就是，一個只修改配置的管理程序，orange 自身只有同步 API。

集群模式下，這種設計才比較合理。這個需要一個簡化版配置註冊中心。

為何要單獨同步，就是出於下面兩大考慮：

1. 不要立刻生效，防止配錯。
2. 第二，依次生效，避免同步風暴。

這些當前的設計都無法滿足。

依次生效目的有兩大考慮：

1. A/B Test
2. 集群化 Orange 同步的時候有脫離負載均衡的過程。

也就是更 Fluent 的同步變更，HTTP 同步請求是個阻塞過程，我不希望引入這種阻塞。

Orange 拆分 ->
	Orange Core (API Frontend)
	Orange Admin (A Manage API)
	Orange UI (A Visualization for Manage API)

[meyer-net]

赞同这种设计方案。也是目前线上迫切的需求。

[sumory]

• 逐步放量/小流量/灰度测试等是类似解决方案发展的必然，但我目前还没收到Orange类似生产使用场景的反馈或需求。在开发人力投入有限的情况下，我倾向于做小，而不是大而全。
• 长远来看，如果要实现“注册中心”或者说“配置中心”以及配置下发方案，那么Orange不应该再显式依赖任何存储，而是依赖API(或者说服务)来进行配置初始化和变更。
• 当然，权限是另一个问题，如果权限控制得当，admin功能、注册管理功能、普通的配置管理都可以在一个系统中实现即可。