刀耕火种 Debug？为什么不使用 Juno

我们常常会思考为什么程序员每天各种查 bug。。。

又或者各种 Debug。。。

又或者各种艰难上线

对于一个程序员而言，构建一个服务并不难，麻烦的是对服务的观测和治理。如果没有好的方法和工具，我们就只能刀耕火种，一行行 debug 或者查 bug，这样的效率不仅慢，而且很难分析到根因。服务上线则是各种人工 check 依赖，运行的稳不稳定，有没有问题，全靠知人事听天命。

俗话说工欲善其事必先利其器。我们如果没有好的工具，强行上微服务，会导致我们不得不加班加点做业务以外的事情，徒增工作内容和心智负担。我们经历过这个阶段，所以不希望同行在重复这一段经历。试问谁不想早点下班，回去学学技术，贡献一下开源Jupiter 框架？

因此为了这个目的，我们将 Juno 进行了开源。经过一个月的努力，我们完成了 Juno 0.2 版本。目前该版本在斗鱼内部开始使用。该版本的功能点如下所示：

提供 api 接口，业务方自动注册应用、机房、部署等信息
实现 form 表单、oauth2 登录
实现 casbin 权限（应用、环境、数据等权限管理）
实现 grpc unary、grpc stream、http 的代理（异地多活、消息总线）
实现 grafana proxy 内嵌到 juno，统一监控和 juno 登录用户
实现配置中心编辑器，类似 vscode、git 方式管理配置，并支持右键关联资源，加密资源。
实现 pprof 在线查看性能
实现 agent 自动上报 region、zone、hostname 和探活
实现应用和资源依赖拓扑依赖解析关系

部署

juno 是一个考虑了单机房和多机房的微服务管理系统。其结构如下。如果是单机房，那么你就不需要使用 juno-proxy。如果你使用机房，那么你需要使用 juno-proxy 做一次代理，方便 juno-admin 与不同机房数据互通。

搭建微服务管理后台 juno，依赖于如 go、mysql、etcd、prometheus、grafana、pprof、juno-agent(prometheus etcd watch) 等基础组件和设施。为了方便大家能够快速使用 juno，我们编写了juno-install ，大家可以使用脚本或者 docker 安装依赖环境，体验我们的 juno。

配置

我们内部讨论配置中心是使用表格还是文本，表格的好处是便于管理和迭代开发、但不利于研发人员使用，文本的好处是研发人员使用简单，但管理和迭代开发麻烦。这个问题我们思考了好久，最后决定还是以研发人员用户体验为主，采用文本方式。

为了让大家更好使用配置中心，就需要思考怎么使用配置中心最简单。我们认为配置中心应该是可以像我们本地 ide 开发一样，能够将配置复制粘贴，版本管理，代码对比。因此我们将配置文本变成了编辑器方式。如下所示

点击对比版本后，可以看到不同版本提交记录变化

右键可以选择插入资源中心的数据。

后期我们会在右键加入很多功能，敬请期待

监控

监控是排查问题核心手段之一。监控的服务注册与发现流程如下所示。

应用通过 jupiter 框架将服务治理端口注册到 etcd，juno-agent 会监听/prometheus/job 的前缀 key，将应用治理端口写入到 prometheus 配置里，prometheus 通过 reload 操作，感知到 jupiter 的应用，然后去对应端口，抓取该应用监控数据。我们可以访问juno-admin 应用，可以看到 juno-admin 的监控图如下所示。