前言
Kubernetes 时代基本不需要担心端口冲突了，但是像我现在公司因为历史原因很难迁移至Kubernetes, 如果一台机器上部署多个应用的情况下，依旧需要对应用端口做一个规划。 云服务器基本上都是按CPU和内存收费。我们的应用基本都是Java应用比较耗内存，开发及测试环境对CPU基本没有需求。内存是固定分配的很难分配，CPU是弹性分配。从节省成本的角度，买CPU少，内存大的服务器，尽可能的在一台服务器上部署更多的应用服务。 一个使用dubbo的Tomcat应用可能用会用到: HTTP端口， Shutdown端口, AJP端口, dubbo端口，JMX Remote 端口, JDWP端口(The Java Debug Wire Protocol)… 早期没有对应用的端口做任何规划，都是使用默认端口，默认端口不行就+1, +2。为了模拟生产环境，测试环境下也都是多节点部署，在部署到不同的服务器时，可能某些端口已经被占用了，导致同一个应用在不同的服务器下，相同的服务使用了不同的端口，毫无规律可言。这个时候就需要规划一下服务器的端口分配。
TCP协议端口的特点:
- TCP/IP端口范围是0-65535
- Linux要求只有root账号才能监听<1024的端口
- 大多数Linux发行版使用的临时端口范围是 32768–60999
- 大多数软件喜欢使用4字数字作为默认端口号:MySQL(3306), Tomcat(8080),Prometheus(9090)等等
规划方案
所以在规划应用端口时尽量避开常用的端口以减少冲突的可能。我现在应用的端口从 10000起，前四位是应用标识，最后一位是外对外开放端口标识。这样，
4位应用标识:
- 从1000到6652,理论上可以拥有5552个应用标识(6552-1000), ()。
- 可以在一定程度上和Apollo配置中心的appId相呼应
1位开放端口标识:
- 0-9，每个应用都可以分到10个端口
- 如果不够用可以通过占用多个应用标识的方式，分配到更多的端口。
- 可以根据自己的实际情况来分配端口标识
像我们公司应用基本都会提供HTTP服务，HTTP端口标识为0；HTTP Management端口就标识为1；为了跟老系统互通很多项目都引入了dubbo，dubbo端口标识为2；JMX Remote端口标志是3。 如果应用标识为1001、1002的应用对外端口如下:
应用
应用编号
HTTP
HTTP Management
dubbo
JMX Remote
JDWP
…
app1
1001
10010
10011
10012
10013
10014
1001X
app2
1002
10020
10021
10022
10023
10024
1002X
这样就可以保证在任一一台服务器部署的服务所使用的端口一致且不会冲突，方便部署运维维护。