Nacos 开源、自研、商业化三位一体战略背后的思考

阿里云原生三位一体战略解读Aliware阿里巴巴开源、自研、商业化技术三位一体，用公有云支持阿里集团上云，以开源为内核做内部扩展，以商业化为基础做内部定制；后端 BaaS 化，客户端轻量化...

阿里巴巴中间件

334人浏览 · 2021-09-10 08:00:00

阿里巴巴中间件 · 2021-09-10 08:00:00 发布

阿里云原生三位一体战略解读

Aliware

阿里巴巴开源、自研、商业化技术三位一体，用公有云支持阿里集团上云，以开源为内核做内部扩展，以商业化为基础做内部定制；后端 BaaS 化，客户端轻量化，业务侧 Serverless 化。

Nacos 作为整个阿里云原生三位战略中的核心组成部分，我们在 2018 年以

Configserver/VIPServer/Diamond 为基础通过 Nacos 开源输出阿里十年沉淀的注册中心和配置中心能力，并且快速成为国内首选。并且通过云产品 MSE 以 BaaS 模式输出解决方案能力。

Nacos 开源三年以来，打造了完整的云原生技术生态，成为国内的事实标准，并且通过社区推动开放共建，通过阿里丰富产品打磨产品性能和可用性，通过商业化打造产品极致体验，更安全的产品能力，满足企业用户的生产要求。从而全方位锤炼 Nacos 各个维度的能力，正循环持续增强产品竞争力！下面将从开源、自研、商业化三个维度进行更深入的分享。

Nacos 生态&规划

Aliware

Nacos 生态

Nacos 几乎支持所有主流语言，其中 Java/Golang/Python 已经支持 Nacos 2.0 长链接协议，能最大限度发挥 Nacos 性能。阿里微服务 DNS（Dubbo+Nacos+Spring-cloud-alibaba/Seata/Sentinel）最佳实践，是 Java 微服务生态最佳解决方案；除此之外，Nacos 也对微服务生态活跃的技术做了无缝的支持，如目前比较流行的 Envoy、Dapr 等，能让用户更加标准获取微服务能力。

Nacos 规划

自从 Nacos 2.0 发布以来，凭借 10 倍性能提升激发社区活力，进入国内开源项目活跃度 Top 10，并且成为行业首选。随着 Nacos 2.0 的成熟，后续 Nacos 1.X 将进入维护状态，Nacos 2.0.X 将做 1.X 到 2.X 的过度，从 2.1.0 版本我们将去掉过度升级逻辑，让 Nacos 2.0 代码更加清爽，性能更加卓越，并且加速插件化和服务网格生态的进化速度，期望对此感兴趣小伙伴一起共建！！！

Nacos 阿里落地实践

Aliware

Nacos 阿里百万实例微服务架构

由于阿里巴巴已经发展到百万实例级的超大集群，为了更高的性能和扩展性，我们按照职能将 Nacos 切分成注册中心和配置中心两个集群；建议超过 10w 实例规模公司从早期做好拆分。小的时候部署到一起运维和部署代价是最小的。统一接入按照流量网关和微服务网关做了两层拆分，Tengine 负责流量网关，主要抗连接，证书卸载和弱七层流量控制；Envoy 负责微服务网关部分，负责服务治理，协议转化，跨域互通等场景；建议超过 100w/s 建议做两层，不超过一层具有最佳性价比。阿里在国际化业务中将服务路由和异地多活切流能力下沉到 Sidecar，并且大规模落地中，以便通过异地多活体系按照 Region 级别扩展集群。

目前为止，阿里云原生网关，注册中心和配置中心所有单元环境全部切到公有云产品 MSE 中，并且经过了 99 大促的验证，并且以此支持今年双十一。

Nacos 服务发现实践

随着业务规模和业务域扩大，大公司基本都会遇到跨域互通的问题，阿里巴巴通过云原生网关打通多个业务域，如钉钉和其他集团业务域互通，通过 MSE 的云原生网关互通，通过 Dubbo 3.0 的 Triple 协议互调，没有任何协议转化的消耗，效率高，rt 低，还可以通过网关配置简单的路由切分逻辑提升整体高可用。在阿里巴巴落地服务网格过程中 Istio 不能满足阿里规模要求，因此服务链路直接跟 Nacos 注册中心打通，路由规则通过 Istio 对接 Nacos 配置中心打通，以便能够大规模生产落地。

Nacos配置管理实践

阿里能够喝着咖啡搞大促的一个底层技术就是动态配置管理+预案系统（定时修改规则配置）。Nacos 作为动态配置管理的基础支撑着整个双十一的核心业务。如阿里巴巴混部快速交付一个单元环境后，会动态推送单元化规则引流到新的混部环境，大促开始前会对日志采样率规则进行调整，防止过多日志对系统性能造成影响。

Nacos 解决方案

Aliware

微服务解决方案

微服务引擎（Micro Service Engine，简称 MSE）是一个面向业界主流开源微服务生态的一站式微服务平台。

用户可以在注册&配置中心、服务框架、云原生网关、服务治理四个模块随意组合，可以选择商业化产品，也可以选择自建产品，如果全部选择我们解决方案，可以直接获得阿里十年沉淀的核心竞争力。

服务网格解决方案

阿里服务网格（简称 ASM）是一个统一管理微服务应用流量、兼容 Istio 的托管式平台。

Nacos 用户可用通过 MSE + ASM 两个产品快速组合直接进入服务网格时代。ASM 中 Istio 通过标准 MCP 协议跟 MSE 中 Nacos 打通服务，MSE 服务治理基于 ASM 流量治理原子 API 做服务治理，我们的云原生网关也是基于 Envoy 构建，这样就可以通过 Istio 标准的控制东西南北流量，进而提升整个微服务高可用能力。

跨域互通解决方案

一般大公司都会有跨业务域、网络域、安全域、跨云等场景服务互通的需求，MSE 云原生网关打通多个业务域，几乎所有用户都能用此方式解决，该模式通用，可管控，安全；如果是一个网络域内，并且业务交集多，流量大，可以用 Nacos-Sync 组件做跨注册中心服务互通，跨域流量超过 100w/s 建议再考虑此种模式，该模式管控代价比较大，只能在网络互通、协议一致场景使用。当然还有很多用户采用多注册和多订阅完成跨域互通，这样更无法管控跨域互通，风险无法识别，并且对研发有代价。

微服务高可用解决方案

随着数字化进程的演进，很多公司跟阿里巴巴一样会搞大促活动，这样峰值流量可能压垮整个系统，导致巨大经济损失，如果准备过多资源会导致资源浪费。这种场景下可以采用阿里巴巴的 PTS+MSE+AHAS+ARMS+ACK 产品组合，边压、边限流、边看，边弹。通过 PTS 模拟用户流量做全链路压测，通过 MSE 中云原生网关做入口限流，并且通过 Nacos 发现后端服务转发，通过 ARMS 做服务可用性和服务治理观测，通过链路追踪分析超时、异常等问题，容量不够通过 ACK 弹性，从而在性能、高可用和资源利用率之间做最大平衡。

异地多活解决方案

对于快递、政府、医疗、金融等国际民生的领域，对业务可用性要求极高，需要具备异地多活的能力。阿里云 MSHA 提供同城多活和异地多活两种多活模式，底层采用 MSE 为微服务基础。MSE 在一个 Region 内提供同 AZ 访问能力，具备同城容灾能力，单 AZ 故障，MSHA 从入口将流量切到可用 AZ 快速恢复。Region 之间通过 MSE 云原生网关互通，解决服务部署不对等的跨域访问问题，MSHA 通过全局控制流量入口，一个区域不可用从入口开始切流恢复业务。