三年打磨，几百线上服务验证，斗鱼开源Go微服务框架Jupiter-InfoQ



 写点什么

Jupiter 是斗鱼开源的，面向服务治理的 Golang 微服务框架，以开发效率和治理效率为核心目标，从统一开发规范、完善监控埋点、降低开发难度等多个维度来帮助 Gopher 开发高性能、高可靠性的微服务框架。

Jupiter 在斗鱼内部经过三年打磨、几百个服务的线上验证，在多种应用场景中适配、历经多次基础架构迭代，有效地保障了服务应用的快速迭代、精确监控，并在异地多活、容器云、混沌工程等基础建设中，支撑服务的平滑迁移、平稳变更。近期，Jupiter Go v0.5.0 正式发布，与之同步发布的还有治理平台 Juno。两者相得益彰，帮助开发者快速落地、并具备服务治理能力的微服务架构。我们致力于将 Go 微服务框架标准化，统一错误码、日志、监控、注册、流控的 Schema。做到微服务的各个模块可观测、可治理，管理微服务研发侧的全套生命周期。以下是 Jupiter 的架构图。

微服务基础框架

现代微服务架构是分布式的，业务逻辑被拆分到不同的服务中，服务之间通过 RPC 相互调用。随着业务规模的增大，服务的数量也随之增加，当增加到一定程度的时候，开发和运维效率将面临严重挑战。

斗鱼 Web 服务在服务化过程中为应对这种挑战，逐步形成了以 Jupiter 为核心的基础框架和以 Juno 为核心的治理平台。

Jupiter 是作为面向服务治理的微服务基础框架，有四个核心关注点:

开发效率: 提升开发效率、加速软件生命周期的迭代。
治理效率: 提升治理效率，实现规模化治理。
多场景应用: 识别通用场景，形成公共知识，持续提升团队开发效率。
演进式架构: 保证服务在自建机房、容器云、网格化等基础架构变更和基础设施变更过程中的平滑迁移。

开发效率

开发效率是 Web 框架的核心关注点，好的 Web 框架融合了代码规范、最佳实践和安全编码，并能显著提高编码效率。如果是自研的框架，还承担着把组织内部的知识，进行抽象和提取，形成公共知识的责任。

同时，Golang 作为一门“新”语言，生态相对也较“新”，实际使用还将面临一些“额外”风险：

开源类库的质量和维护力度参差不齐，如果有 bug 或者不兼容问题，其修复难度较大。
Golang 去中心化的依赖管理会导致类库管理困难，开发人员可以随意“引入”或“升降级”依赖库。
不同类库的代码风格差异大，有一定使用成本。
Golang 历经了多种包管理方式，对国内的开发者而言，俨然一部血泪史。目前 gomod 大有改善，但仍有个别老旧类库存在问题。

Jupiter 是伴随斗鱼服务化一步步实践而来，经历了 go1.7 到 go1.14 既平滑（完美向前兼容）又剧烈（生态、依赖管理）的成长。针对业务的开发效率以及“额外”风险，Jupiter 有一些基本的认识:

以 monorepo 的方式整合核心框架、自研类库并包装第三方类库。长期看，这将极大减少维护成本。
利用语言机制如 type alias/type embedding 等，封装常用的第三方类库，尽量减少直接引用第三方类库。这提供了一种缓冲机制，避免依赖被随意“升降级”，第三方 bug 也可以被方便管控。
通过包装，一些关键类库万不得已的时候可以切到自研，也可以由自研切换到开源，降低维护成本。
统一所有包的使用方式，包括配置驱动、统一错误码、统一日志埋点、指标埋点等，减少开发人员心智负担。

当然，上述很多问题不能仅仅依赖于基础框架来解决，并且随着 Golang 语言和生态的发展，一些问题也在不断缓解。但核心的需求还在，即通过整合基础框架，降低风险，提高效率。

除了针对主要开发环境的效率提升外，Jupiter 针对调试、测试、CI 流程等方面也做了一些工作，以提高整个软件周期的效率。

治理效率

治理效率是微服务架构的关键需求。微服务架构中，应用数总是不断上升，人均应用维护数增加到一定数目以后，维护效率将大幅度下降。如果碰到突发事件，将产生严重后果。因此，微服务架构非常强调服务治理能力和应用管理能力。一般来说，微服务治理包括：

服务注册与发现: 服务注册、负载均衡等
可观测性: 拓扑关系、指标、日志、链路等
流量管理: 流量特征识别、流量导向等，以及基于此的灰度、蓝绿发布、A/B Test 等细分应用
安全策略: 访问控制、限流熔断等
生命周期: 发布、下线管理，版本控制等

微服务治理是一项基础能力，需要代码规范、治理平台、基础框架甚至组织架构等多个方面协作，才能达到比较好的效果。

我们近期还会将治理平台 juno 开源部分微服务治理能力，未来还将整理和开源更多的治理能力，并与社区共建，进一步完善微服务治理。这部分，我们将在单独的文档中进行更详细说明。

在基础框架的部分，我们认为基础框架是沟通业务与治理平台的关键，一定程度上也定义了服务治理流程。在 Jupiter 中，针对服务治理，有几个关键点：

增强核心模块可观测性：完善的日志、指标、链路埋点，并形成规范，从而实现报表、报警直出。
统一错误码: 规范的错误码和错误收敛机制，能够极大的提升错误定位和排查速度。
拦截器支持: 针对 http/grpc 的 server/client 以及 redis/mysql/mongo/rocketmq 等 IO，全部支持拦截器机制，以进一步支持更丰富的治理策略。
安全策略内置: 主要模块内置限流熔断、访问控制、慢查询监测等安全策略。
流量路由和管理: 提供多种负载均衡和流量路由策略，以及针对 A/B Test、影子流量等细分场景的流量策略。

多应用场景

支持多应用场景前，需要准确的识别应用场景，而识别的过程就是一个规范代码、探索实践的过程。应用场景的定义可以很宽泛，这里举几个例子简单说明：

缓存策略。缓存的策略有很多种，在 Web 开发领域也经常使用。我们注意到业务实现中，经常会有数据过期时，一个请求穿透、多个请求原地 block 的场景。通过引入滑动窗口和半衰期，让一个请求穿透、多个请求正常返回，从而实现更高效的缓存策略。
与 Java Dubbo 流量互通。dubbo 支持 gRPC 协议，因此在协议层，dubbo 与 grpc-go 是可以流量互通的。Jupiter 通过增加一个基于接口(dubbo 的默认注册方式)的服务注册键，从而实现服务注册与发现层面上的流量互通。

类似的例子在 Jupiter 中还有很多，如任务编排、流程编排、redis 的并发 pipeline、在线压测的 mysql 影子流量等。

应用场景的识别是形成公共知识、加速团队开发效率的重要手段。

演进式架构

Web 开发和运维技术在不断的发展，短短几年已涌现出了非常多的计算形态，如云计算、边缘计算、容器化、网格化、Serverless 等。服务保障技术方面，异地多活、混沌工程也在不断发展。语言栈方面，很多公司也在从早期单一的 PHP、Java 栈扩大到多语言栈并存的局面，特别是近年来 Golang 因在容器化和运维效率上的优势，越来越多的被应用到 Web 服务开发。但每次技术迭代，享受效率提升的同时，也在不断经历应用改造和迁移的痛苦。

从应用的角度来看，面对的是一个不断变化的外部环境，新的问题不断产生。以斗鱼 Web 服务部为例，可以通过一个时间线管中窥豹:

应用开始服务化: 这个阶段开始构建大量的基础治理平台，包括发布中心、监控中心、注册中心及各个管理细分平台。同时，一些新的基础设施开始引入，如 etcd，prometheus、jaeger 等。
语言栈从单一的 PHP 扩展为 Golang、Java、PHP 的多语言栈。API 规范、服务互通在这个阶段凸显。
多机房建设: 流量管控、服务质量、安全策略的要求凸显。
容器化: 传统基于 IP/Port 的治理方式、流量管理和分发、服务监控需要做出相应改变。
Service Mesh: 基于 SDK 的服务注册、发现，监控需要适配。

总体上，基础架构的变更将对整个治理体系产生影响，特别是治理平台。正视变化，并前瞻性和针对性的优化，将有助于减少外部环境变化对业务逻辑的影响，并享受整个生态进步带来的效率提升。