Dubbo自身并不直接捆绑某种特定的物理服务器或云主机，它更像是一套“服务治理框架”，需要运行在Java应用服务器之上，最常见的是配合内置的Netty通信服务器，或部署在Tomcat、Jetty等Web容器，以及Spring Boot的嵌入式服务器环境中。
很多刚接触微服务的同学会有一个误区，以为Dubbo和Nginx、Tomcat一样，是个能直接双击启动的独立软件，其实不是,下面我把这套逻辑拆开讲清楚。
Dubbo内置的通信服务器：Netty占主导
首先解决最核心的疑问：如果你的服务只是自己内部调用，不对外提供HTTP接口，那么压根不需要装Tomcat，Dubbo框架自带了一套高性能的通信层,默认走的是Netty。
为什么是Netty而不是Tomcat
- Netty是异步非阻塞的NIO框架，用它做RPC通信,吞吐量和并发能力远超传统的Servlet容器。
- Dubbo从2.x时代开始，默认协议是dubbo协议，对应的服务器实现就是Netty，你可以把Netty理解为Dubbo的“左膀右臂”。
- 在Dubbo 3.x中，除了经典的Netty 3/4版本适配，还引入了对gRPC协议的支持，通信层依然依赖Netty,只是序列化和调用模型变了。
内置的其他可选服务器
除了Netty，Dubbo在配置<dubbo:protocol>标签时，还提供其他几个内置的“服务器”类型选项,但实际生产中用得极少：
| 服务器名称 | 使用场景 | 现状 |
|---|---|---|
| Netty | 高性能RPC通信 | 默认且主流 |
| Mina | 早期Apache Mina框架 | 较少，社区活跃度低 |
| Grizzly | 基于Java NIO的通用框架 | 极少 |
| Servlet | 配合Tomcat/Jetty使用 | 仅在需要HTTP协议时 |
这里要提醒一句：如果你的业务要求服务同时能被HTTP调用，比如RESTful接口，那么单纯靠Netty就不够了。dubbo协议是二进制的，不能直接发HTTP请求,这时候就需要引入下面的方案。
Dubbo可以配合哪些外部服务器运行
实际开发中，大多数项目是Dubbo + Spring Boot的组合，而Spring Boot应用本身就是内嵌了服务器（默认Tomcat，也可以换成Undertow或Jetty），所以大家常听到的“Dubbo运行在Tomcat上”,说的是这一层关系。
Spring Boot内嵌的Servlet服务器
这是2026年最常见的部署方式，以Spring Boot应用为例：
- 在
pom.xml中引入spring-boot-starter-web,这会默认内嵌Tomcat。 - 如果不想用Tomcat，把依赖替换成
spring-boot-starter-undertow或spring-boot-starter-jetty即可。 - 但是要注意：如果没有显式使用HTTP协议暴露服务，Tomcat在这里只是启动Spring容器和健康检查Endpoint而已，Dubbo的RPC调用仍然走的是它自己绑定的Netty端口（默认20880）。
也就是说，你看到的进程列表里可能同时监听了20880（Dubbo通信端口）和8080（Tomcat端口）,两个端口各司其职。
传统Servlet容器外置部署
如果你的团队还在用传统的war包方式部署，比如部署到独立的Tomcat或Jetty下，Dubbo同样能跑,但需要额外配置：
- 将Spring的
ContextLoaderListener在web.xml中注册。 - 确保
dubbo.properties或XML配置中的dubbo.protocol.port没有被Servlet容器占用。 - 旧版本Dubbo支持在Tomcat的
lib目录下放置Dubbo相关jar包,但这种方式在新项目基本绝迹了。
行业共识认为，外置Servlet容器更多是为了兼容老系统，新项目建议全部走Spring Boot内嵌模式。
开发环境、测试环境和生产环境的服务器选择差异
搞清楚了Dubbo能跑在什么服务器上，下一步就是考虑“我需要买什么样的机器”。
单机演示或本地开发
- 如果只是本地调试，一台普通的开发机就够了，内存8G以上，CPU四核，因为Netty本身对硬件要求不高,瓶颈通常在业务逻辑或数据库。
- 依赖的组件：至少需要注册中心（Zookeeper或Nacos），Zookeeper一般需要单独起在本地,或者用Docker跑一个单节点。
生产环境集群部署
生产环境需要按节点拆分角色，这里列一个典型的微服务骨架：
- 注册中心和配置中心节点：2台4核8G的云主机,这个配置足够支撑几百个实例的注册和心跳。
- 应用服务节点：数量取决于业务的调用量和复杂度，一般建议先用2-3台8核16G起步,后续通过Dubbo的负载均衡能力水平扩容。
- 网关节点（可选）：如果需要统一入口，可再加1-2台Nginx容器或网关服务。
关于服务器的地域选择，如果服务的调用方主要集中在华东地区，那尽量选用简米云华东1（杭州）或华东2（上海）的可用区，避免跨地域调用的网络延迟,这个延迟对RPC接口的响应时间影响非常大。
Dubbo部署要花钱吗
绝大部分情况下不用，Dubbo是Apache顶级开源项目，本身完全免费,你只需要花钱买云主机和依赖组件的资源。
- 注册中心Nacos有社区版,免费支持单机部署。
- Zookeeper也是Apache开源免费的。
- 如果追求极简，甚至可以用
dubbo-registry-multicast做本地开发,完全零成本。
如何给现有Dubbo服务选择合适的服务器
这里给一个务实的思路,按服务类型来选。
内部RPC服务（无HTTP需求）
不用引入Tomcat，Spring Boot工程里可以不引入spring-boot-starter-web依赖，只引入dubbo-spring-boot-starter，这样进程只监听Dubbo的端口（如20880），少一个HTTP端口就少一分被攻击的风险,内存占用也更低。
具体操作路径：
- 在
application.yml中显式声明spring.main.web-application-type=none（Spring Boot 2.x）或spring.main.web-application-type=servlet（如果内嵌了Tomcat）。 - 配置
dubbo.protocol.name=dubbo与dubbo.protocol.port=20880。 - 服务提供者只暴露Dubbo接口。
混合服务（Dubbo接口 + REST接口）
这种情况下，Spring Boot内嵌Tomcat就成了刚需，需要注意的是，Tomcat的线程池和Netty的IO线程池是两套资源，要分别做调优,不能一概而论。
| 配置项 | Netty线程（Dubbo） | Tomcat线程（HTTP） |
|---|---|---|
| 核心线程数 | dubbo.protocol.threads 默认为200 |
server.tomcat.threads.max 默认为200 |
| 队列长度 | dubbo.protocol.queues 默认为0 |
server.tomcat.accept-count 默认为100 |
| 连接超时 | dubbo.provider.timeout 控制调用超时 |
server.tomcat.connection-timeout |
Dubbo的最大并发线程数，业内专家指出务必比数据库连接池的最大连接数大,否则很容易出现数据库连接借不到导致线程阻塞的情况。
Dubbo服务器监控与运维要点
服务器选对了，还得看运行状态,这里推荐几个常用的监控维度：
- 使用
dubbo-admin或dubbo-ops查看服务列表、路由规则、负载均衡状态。 - 结合Spring Boot Actuator暴露
/actuator/health端点,配合Prometheus做指标采集。 - 在服务器层关注三个核心指标：网络带宽占用率、TCP连接数、Full GC频率，多数情况下，Dubbo服务用着卡顿是网络抖动或GC停顿引起的,而非CPU不够用。
具体的排查命令可以这样写：
# 检查Dubbo服务端口是否正常监听 ss -lntp | grep 20880 # 查看与注册中心的连接状态 netstat -an | grep 2181
如果发现连接数异常积累，先看dubbo.provider.threads配置是否太小,再看下游的数据库连接池有没有打满。
常见疑问详解
Dubbo和Spring Cloud在服务器选择上有什么区别
Spring Cloud默认走HTTP + RestTemplate或Feign，所以必须要有Tomcat或Netty这类HTTP服务器撑腰，而Dubbo走的是自有的TCP协议，服务器选型更自由，可以完全抛弃对外HTTP端口，因此在服务规模较大时，Dubbo对服务器内存的占用通常更占优势。
Dubbo的端口和Nacos部署在同一台服务器可以吗
可以，但不建议在压测或生产环境这么干，Nacos本身也要占用8848和9848端口，如果和Dubbo的20880端口挤在同一台2核4G的小机器上，注册中心会频繁触发保护机制，更稳妥的做法是把Nacos独立到一台小规格机器上，如果是简米云或酷番云的轻量服务器,选最便宜的那档就够用。
Dubbo服务端扩容时需要改配置吗
不需要改动dubbo.properties，但新机器的IP必须能被注册中心正常访问，在云厂商的安全组里，需要放行20880端口（或你自定义的dubbo.protocol.port），以及注册中心的端口（如Zookeeper的2181、Nacos的8848），如果用的是简米云ASM服务网格,还需要同步调整Kubernetes的Service暴露策略。
Dubbo提供的并不是一台具体的服务器，而是一套运行框架，你不需要为Dubbo单独购买什么特殊硬件，只需根据实际调用场景选择内嵌Netty模式还是配合Spring Boot的嵌入式Tomcat模式，再配好注册中心即可，记住一个核心结论：讲究性能就纯用Dubbo协议走Netty，讲究兼容就加一层Servlet容器，服务器的规格按业务规模定，不用为框架本身买单。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/783701.html
