consul控制台改造方案

[Ygwww]

现状（why）

原有consul的控制台功能缺失部分功能

1. 权限管理（对consul的api的访问做权限判断）
2. 服务下线
3. 英文显示不友好等等

目标（what）

控制台改造

Feature List

• 原控制台已有功能
  • 服务列表查看
  • 服务详情查看
  • KV存储
  • 数据中心列表
  • 数据中心详情
  • 节点列表
  • 节点详情
  • acl
• 缺失的功能
  • 下线服务
  • 重启服务等等
• 扩展功能（consul-api不存在的功能）
  • 权限系统

consul-api提供的所有api

方案 (How)

方案-1

ATLAS企业服务

待考证，是否满足上述所有需求

• 购买企业服务，不用自己开发维护
• 扩展困难
• 出问题只能被动的atlas的人来解决
• 这种做法对系统有预设，需要公网环境
• 之后会废弃掉，官方不推荐用。链接

方案-2

基于原本控制台进行改造

• consul控制台启动时，可以指定UI文件目录，可以试着替换原本的UI目录文件，consul的api-server自己不用再开发。
• 控制台的权限可以通过代理服务器来做, 在代理服务器进行代理之前进行权限判断。

方案－3

做法类似方案-2

• 前端和server部分全部自己来处理，自己处理每一个对应的consul api
• 改造程度最大, 开发量也是最大的
• 扩展和维护都由自己来完成

可行性分析

1. atlas在17年3月7号之后，官方便不再推荐使用，故不采纳方案1。

2. 基于原本控制台改造，不修改server部分，这样前后端交互的数据格式会受consul提供的HTTP API的返回数据格式。若要进行进一步改造，可采用方案3.

3. 采纳方案3，由自己开发整个系统。

   • 前端部分

     • 根据需求可以有更加合理的设计

   • 后端部分

     • consul提供了基于多种语言的获取api的client(链接),可以在此基础上开发。java版的consul-client有所有consul提供出的http api。

     • 调用请求顺序:

       当api-server接受到从前端发起到请求时，自己调用consul-client获得相关数据。相当于对consul-client提供出的服务做一次包装。

   • 全部代码由自己维护，可控行更强

结论

采用方案3，基于consul-client做进一步开发。

[Ygwww]

系统分析

• 列出详细的api列表
• 要做哪些功能