背景

业务说明：

• 公司面向企业现场无网，运维/实施过程中，一点点优化代码和配置文件和整体的部署架构的过程。

技术栈说明：

• 前端采用的是node,单独的服务端口。 访问都是单独的ip和端口。 而且还需要配置后端访问的ip和端口
• 后端spring-boot。
• 算法也是有对应的服务。
• 第三方开源的中间件,包装一下。

微服务docker部署

原始状况

• 涉及到的子系统和中间件比较多，需要多台机器。
• docker只是一个有jar或者python的运行环境，打完包后的内容，挂载到宿主机中，方便后续的版本迭代升级。
• 所有机器只装docker把项目的配置文件挂载出来。实施部署时人工修改对应的ip就行。（主要是这里的人力成本比较大，还易出错）

改进

1. 企业自建dns服务器： 把所有配置改成域名+端口固定形式。

管理的流程中添加： 立项后申请svn代码地址和对应服务端口的表格和统一分配之前端口冲突的还继续使用的项目
大部分项目无法协调企业网络管理处的资源，该方案停止，采用原始状况。

2. 添加nginx代理: 把所有访问入口统一,前端部署访问都是相对路径

管理的流程中添加： 分配访问资源前缀路径。
代码层改造：前端区分生产（固定相对路径）和开发（完整的url）
效果： 前后端交互无需修改配置，但是还需要修改nginx的配置。 但是后端之间交互和访问中间件还需固定ip。 约等于无效果

3. 服务器添加域名映射

域名基本可以无需修改配置，只需统一修改host文件就行。 后续改成只需要再裸机部署中添加引入备用dns就行.

4. 服务器域名映射改成主机名映射,且以k8s为主。

k8s的Service中的metadata为对应的网络标识。 为了兼容k8s的情况，放弃域名的命名规则，统一改成k8s的命名规则。 k8s的metadata：name 命名规则是最多 63 个字符，只能包含小写字母、数字，以及 ‘-’，必须以字母数字开头，必须以字母数字结尾。