首先介绍一下云原生升级的挑战。目前大部分公司里基本上都有 CICD、DevOps 来帮助开发、测试、运维提升开发的效率与质量，也会有容器化来帮助提升产线运维的效率与质量。但在云原生时代，大规模容器的频繁变更会带来很多稳定性的问题。这些稳定性问题，包含了很多我们可以提前规避掉的已知的异常，也包含了很多我们无法避免的异常，比如网络故障、机器宕机等系统无法提前避免的的问题。 如果我们能提前发现这些问题，其实是可以规避掉很多风险的。通过可观测系统及时的感知问题，高效的分析异常，快速的恢复系统。因此可以判定，在云原生时代，可观测系统的建设是非常重要的。
微服务架构已经是后端架构领域老生常谈的话题了，微服务治理、发现等技术已经在业界有了很多成熟的解决方案，Dubbo 作为一个社区认可度较高的微服务治理框架也在这个方面颇有建树。但是在微服务架构中，服务的数量和复杂度都远超过之前的单体架构，如何保证服务的稳定和高效运行呢？这时候，可观测性就显得尤为重要。 我们都知道 Dubbo 自身有指标监控[1]，但仅聚焦在应用代码层面，同时指标只是可观测性主要的数据之一，我们还需要联合日志、追踪等数据共同去观测服务，才能去多维度保证服务的稳定性和可靠性，而 DeepFlow 具备在应用、网络及系统等多个层面采集指标、日志及追踪等数据的能力，同时可基于 AutoTagging 能力，为所有的数据注入上统一的标签，解决数据孤岛的问题。 所以我们基于 DeepFlow 构建了一个针对 Dubbo 协议的可观测性 Dashboard，分别提供在应用、网络及系统三个层面的监控视角，通过分析时延、错误及访问量，可快速定位突发性能瓶颈和异常流量，帮助我们快速排查故障。
随着微服务技术的快速发展，其在各个领域都形成了一系列事实标准，在 Kubernetes 和容器技术加持下，云原生微服务已经成为了主流解决方案。而 Go 语言作为云原生领域最受欢迎的开发语言，正被越来越多的企业作为微服务开发的首选语言，其中比较流行的包括 Go-micro、Go-zero、Dubbo-go 等。作为 Dubbo 微服务体系中多语言实现的一员，在 2022 年 Dubbo-go 以微服务领跑者的角色积极拥抱云原生标准，探索了 Proxyless Mesh 形态，配合适配 Pixiu 云原生网关，形成了完善的 Dubbo-go 微服务生态矩阵。 以 Dubbo-go 为中心的微服务体系在多个知名企业中成功落地和实践，框架的稳定性在实际场景下经受住了考验。截止今年已有 60+ 家企业在我们的用户列表中登记，其中较为典型案例请参考文章《小米电商 Apache Dubbo-go 微服务实践》。小米电商选用了 Dubbo-go + Nacos + sidecar + etcd + mirpc 为核心的微服务体系
不少人曾问于某，到底是 dubbogo 还是 dubbo-go 才是正确拼写，个人通常的回答是，两个都对。 于雨 2016 年 3 月在位于上海张江的 张衡路与华佗路 交叉口的 盛大研发中心 工作时，公司大部分项目使用了 Java 技术栈，其中相当数量的服务使用了已经无人维护的 Dubbo v2.5.4-snapshot。公司老板陈大年【内部称呼 年总】觉得云原生时代来了，让大家用 Go 语言改造公司的 Java 项目。于是公司新项目纷纷使用 Go 进行构建，但面临一个很重要的问题：Go 语言服务与 Java 服务之间如何进行通信？
我们公司从 2015 年开始就使⽤ Dubbo 作为微服务框架，当社区推出 Dubbo 3 时，我们也⽴刻跟进并做了深⼊调研，发现 Dubbo 3 的应⽤/实例级服务注册和发现模式能够在一定程度上解决我们当前注册中⼼⾯临的压⼒，解决稳定性和安全性问题。同时 Dubbo 3 在服务治理上也做了升级，契合云原⽣架构，⽽且 Dubbo 3 能够向下兼容 Dubbo 2，这也将降低升级的成本和⻛险。 升级项目有了阶段性的进展，目前仍然在进行中。通过本⽂，我们对公司内部的 Dubbo 3 升级过程及收益等做了深⼊总结。
