#859 refactor config item for 2.0

[tianxiaoliang]

进行了不兼容的配置项重构，理由是因为配置命名风格不一致，配置所处层级位置不合理，cse是商业产品的名字：

• cse统一替换为servicecomb
• 微服务描述挪到了servicecomb.service下
• 注册发现配置挪到了servicecomb.registry下
• 文档适配新配置
• cse前缀的配制方法不再支持
• rest调用不再支持cse://写法
• 删除tenant这种没用的配置项
• 删除highway example

[AngLi2]

LGTM

[xy-github-issue]

用户应该怎么样过渡到这个新的配置结构上来？貌似没有过渡方案？

[tianxiaoliang]

用户应该怎么样过渡到这个新的配置结构上来？貌似没有过渡方案？

是的，如果兼容会使工程充斥很多复杂的分支语句，后续不易维护，另外由于是2.0开发阶段，所以会推出的功能无法兼容也是符合版本管理的，比如python2.0切换python3.0。

[xy-github-issue]

用户应该怎么样过渡到这个新的配置结构上来？貌似没有过渡方案？

是的，如果兼容会使工程充斥很多复杂的分支语句，后续不易维护，另外由于是2.0开发阶段，所以会推出的功能无法兼容也是符合版本管理的，比如python2.0切换python3.0。

用户怎么升级啊？

[tianxiaoliang]

用户应该怎么样过渡到这个新的配置结构上来？貌似没有过渡方案？

是的，如果兼容会使工程充斥很多复杂的分支语句，后续不易维护，另外由于是2.0开发阶段，所以会推出的功能无法兼容也是符合版本管理的，比如python2.0切换python3.0。

用户怎么升级啊？

2.0推出后，必须有个指导，告诉开发者如何从1.x升级到2.0

[xy-github-issue]

我觉得缺少了

1. 升级指南的文档, 旧配置项与新配置项如何一一对应，是否有删除/拆分/改变语义的配置项
2. 运行使用到旧的配置项时的提示

是否可以考虑这样的过渡方案：新增一个配置源，用于将新的配置项项映射到旧的配置项上

[tianxiaoliang]

我觉得缺少了

1. 升级指南的文档, 旧配置项与新配置项如何一一对应，是否有删除/拆分/改变语义的配置项
2. 运行使用到旧的配置项时的提示

是否可以考虑这样的过渡方案：新增一个配置源，用于将新的配置项项映射到旧的配置项上

建议非常的好，感谢。只是目前社区人力有限，映射机制开发成本还是比较高的，你是否有兴趣贡献第二点的内容。

[xy-github-issue]

我觉得缺少了

1. 升级指南的文档, 旧配置项与新配置项如何一一对应，是否有删除/拆分/改变语义的配置项
2. 运行使用到旧的配置项时的提示

是否可以考虑这样的过渡方案：新增一个配置源，用于将新的配置项项映射到旧的配置项上

建议非常的好，感谢。只是目前社区人力有限，映射机制开发成本还是比较高的，你是否有兴趣贡献第二点的内容。

参与目前的 go-chassis 修改对于我来说有个非常大的问题，就是兼容。用户很忙，我又需要非常及时地修复bug。我们目前用着 v2.0.0-alpha.2 后面的一个hash 版本，我不知道后续的版本是否兼容 v2.0.0-alpha.2 , 如果不兼容，在后续的版本上提交修改的话，尤其是修复 bug 的提交，我就没有办法及时地更新给我的用户。

[tianxiaoliang]

我提供一个升级指南可否，升级一个工程（微服务）1分钟