你看得起劲的斗鱼直播，已经在 GitHub 开源了自家项目！

为什么选择 Go

Go 语言是由谷歌于 2009 年推出的一门相对比较新的编程语言，因其原生支持高并发的特性，被誉为云原生时代的容器语言。但 Go 在国内的起步较晚，目前 Go 相关的生态在国内还并不完善，甚至还有很多开发者仍对这门所谓的云原生时代新语言持观望态度。在与吕超的交流中我们得知，成立于 2014 年的斗鱼最开始使用的也不是 Go 。

“ 斗鱼 Web 部门一开始使用的是 PHP，一直到 2016 年底，为应对业务规模的快速增长，逐步引入 Go、Java 从而形成了多技术栈的局面。” 吕超介绍说，“ 引入 Go 也是看中了 Go 在高并发应用开发和容器化上的优势，事实上在随后两年的服务化工程中，Golang 确实也展现了这种优势。”

然而迁移到 Go 的过程并不容易。据吕超回忆，“ 由弱类型语言转向强类型语言，类库的匮乏，以及 Go 在包管理功能上的混乱都给我们造成了不少的困难。但 Go 语言机制比较简单和直观，没有那么多花里胡哨的东西，这也带来一个潜在优势就是 Go 应用的重构和迭代成本是非常低的，这一定程度上降低了迁移的难度。”

也正是为了提高 Go 应用的开发效率，斗鱼的团队开发了 Jupiter 。“ 随着应用规模的增大，Jupiter 也非常关注治理效率。服务化做的差不多的时候，也开始承担多机房建设、云化、容器化、混沌工程等基础建设的一些工作，以保障业务逻辑与这些基建的无缝对接。当然这里更多的是需要治理平台和运维的 PaaS 平台的支持，幸运的是，我们的服务治理平台 Juno 也开源了。通过 Jupiter 和 Juno，可以实现比较完整的服务治理体验。”

与其它微服务框架的区别

由于 Go 语言支持高并发特性，一些已经比较成熟的微服务架构也在近期推出了 Golang 重构版本，比如我们前段时间报道的 Dubbo Go 。吕超表示，他们的团队也一直在关注 Dubbo Go 这个项目，同时也很乐见 Golang 生态里有这样优秀的 RPC 框架。实际上，Jupiter 与 Dubbo Go 等这些优秀的 RPC 框架相比，更多的是一种互补的关系。

首先，相比于 RPC 框架，Jupiter 更侧重于微服务治理。斗鱼内部的 Jupiter 深度定制了 echo, gRPC 框架，并支持公司内部自研的 RPC 框架。一方面是为了解决公司内部多技术栈 (php/Go/java/cpp) 的数据通信，另一方面也是为了解决早期一些开源框架功能不足的问题。

但是随着公司内部 RPC 框架的整合，以及开源框架的持续完善，这两个问题得到了很大的缓解。“ 所以我们也在逐步简化 RPC 框架，专注于服务治理。开源的 Jupiter 也延续了这个理念，通过简单的适配，gin/Goframe 等优秀框架都可以很方便的集成进来，这里的适配主要指一些基于管理和治理需要的必要封装。”

其次，Jupiter 不只是一个 RPC 框架。Jupiter 关注的是应用的服务治理，除了 RPC，应用还有缓存、存储、消息队列、任务编排等。这些都是需要治理的，除了可观测性的三驾马车: 日志埋点、指标采集、链路追踪外，Jupiter 还支持统一错误码、在线 profiling、开发模式、动态配置等基础功能，治理精度更高，维度更丰富。

我们知道，微服务架构中的一个关键点是服务之间的通信，特别是多技术栈场景下的跨语言通信。在斗鱼内部，Java 团队采用的就是 Dubbo 框架，为了实现 Go 应用与 Java 应用通信，团队采用了一种折中的办法是:

• Java 团队的 Dubbo 框架采用 Dubbo-gRPC 作为通信协议，实现通信协议上的互通。

• Go 团队的 Jupiter 框架通过多注册键的方式，支持 Dubbo 基于接口的注册协议，实现服务注册和发现上的互通。

“ 这个方法虽然能用，但不那么优雅。真正要解决问题，还是需要打通服务注册协议。我们注意到了 Dubbo 和 Dubbo Go 基于应用注册方面的进展，我们对此非常期待，也在研究怎么把 Jupiter 和 Dubbo Go 做一个结合，从而优雅的与 Dubbo 互通。” 吕超表示，让 Jupiter 与 Dubbo 架构更好的互通，是团队下一步要努力解决的问题。

微服务架构的意义

分布式的微服务架构从诞生之日起就受到不少争议，网上也有人认为很多企业继续沿用统一部署的传统架构即可，无需盲目追求新技术。吕超结合斗鱼的业务经验，分享了他对于微服务架构应用前景的看法：“ 我觉得技术架构都是一个演进过程，遵从康威定律：组织架构决定技术架构。”

斗鱼是随着业务的发展，组织架构的变迁，导致原有的单体应用架构在维护和治理上存在一定问题，因此逐步迁移到微服务。微服务帮斗鱼解决了以下问题：

• 服务的可维护：子系统的内聚性，明确了子系统的职责和边界，可以有效降低各个系统的沟通成本和对接成本，架构上可以更加合理高效

• 服务的高可用：子系统的 SLA 划分，根据不同 SLA 等级，能够对核心服务做优化和灾备，提升服务可用性

• 服务的可伸缩：子系统的 QPS 划分，根据不同 QPS 量级，能够对服务的容量进行估算，服务做到可伸缩

总的来说，微服务在业务

【一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

规模、组织架构达到一定程度的时候，有很多不错的维护和治理优势。“ 换言之，**不是我们选择将单体换成微服务，而是业务发展到一定程度需要微服务。**评价一个企业是否需要微服务架构有个最简单的方式，就是两个披萨的理论。如果维护一个单体应用代码，超过了两个披萨的团队，就有可能人数太多导致沟通问题，这个时候，我们可能就需要做一些拆分。”

拥抱开源的斗鱼

国内大厂拥抱开源的例子不在少数。作为一家国内知名的网络直播平台，斗鱼在开源界尚属新面孔。我们请吕超为我们分享了斗鱼的技术团队对于开源的看法。

“ 在开源 Jupiter 之前，我的许多同事也都在不同程度的参与到开源社区，贡献代码。早期参与开源社区的目的，主要是因为因为内部需要，我们二开了很多开源类库。如果及时的把改动反馈到社区，能极大减轻我们的维护成本。随着参与次数的增多，逐渐产生了开源的想法。同时，Go 原生的面向微服务治理的集成方案比较匮乏。非原生的、从其他语言生态搬过来的框架又有一定的理解成本。种种原因促使我们考虑把微服务框架 Jupiter 和治理平台 Juno 同时开源，为微服务架构方案贡献一点点力。”

通过开源 Jupiter，吕超和他的团队全面的梳理了基础框架的架构设计，总结了服务治理的经验，“ 这对未来我们内部的服务架构和治理体系都有非常大的帮助。” 同时，开源社区的积极反馈也给斗鱼的团队带来了很多有价值的意见和建议。

“ 贡献者的反馈也还是比较多的，有讨论服务治理方案的、有询问架构设计的，甚至还有讨论到具体某行代码的。作为一个刚刚开源的新项目，这些反馈对我们都无比宝贵。” 距离项目开源短短半个月的时间，目前 Jupiter 已经获得了 1066 个 Star 。同时，随着 Jupiter 社区的持续完善，以及与其它开源社区的互动，吕超相信这一定会让 Jupiter 和斗鱼内部的治理体系更加健壮。

“ 之前更多的是个人参与，项目也比较分散。借着这次开源的机会，我们会整合一些开发资源，瞄准我们正在使用或将要使用的一些开源项目，参与进去。然后，推动这些项目在我们内部的使用，形成一个良性的互动。”

吕超总结了自己对参与开源的看法。从个人的角度来讲，参与开源能有效提升个人的代码质量。从公司的角度来讲，能更有效的利用共享资源提升效率。总体上，是一件非常有益的事情。

关于未来

斗鱼未来是否还会开源更多的项目？吕超向我们透露，目前团队计划是围绕微服务框架 Jupiter 和服务治理平台 Juno，持续的推动开源。过去两年，斗鱼内部积累了许多类库，比如基于内存的对象存储 bigmap，高并发的 redis 客户端 redix，对全链路压测的支持等，因为含有一些内部定制的特性，暂时没有开源。但之后团队会进一步整理，逐步通过 Jupiter 把这些内部的项目释放出来。“ 作为 Jupiter 配套的后台系统 Juno，我们后续计划会持续完善配置中心、注册中心、监控中心、治理中心等等，Juno 不仅会兼容 Jupiter，也会兼容其他开源的框架，为 Go 微服务生态添砖加瓦。”