先声明一下：我所在的公司是一个小团队，做物联网相关的，前后端、硬件、测试加起来也就五六十个人左右；本人的岗位是Java开发（兼DBA、运维）；我进公司时整个项目的部署架构为 简单jar包部署微服务集群形式；去年公司将部分服务使用docker进行部署；因为现在服务稍微有点多导致容器管理起来也比较难，再加上我们公司没有专门的运维人员，所以现在打算使用云商的k8s来对容器统一进行管理。因为运维相关的事情我一直在负责，上周领导让我画一下用k8s部署接口调用链路图，所以我便顺便总结了一下，以下大部分内容为我自己理解，如果有什么不对的地方还请大家多多指出。（文中画图使用软件：BoardMix）

为图木舒克等地区用户提供了全套网页设计制作服务，及图木舒克网站建设行业解决方案。主营业务为成都网站设计、成都网站制作、图木舒克网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！

一.常见服务部署架构

1.传统服务器jar运行部署（公司之前使用的部署方式）

服务部署架构图

优点

• 学习成本低：只需要掌握Linux命令即可操作，不需要掌握其他特殊命令；

缺点

• 隔离性差： 1.各个集群中所有服务共用相同运行环境，如果环境发生错误将会影响集群当前节点上所有的服务；2.如果其中某一个服务发生死锁、内存泄漏等异常，此服务部署的所有节点（服务器）的内存/CPU可能会被占满，也将影响整个集群的其他服务，导致所有应用不可用；[之前一个项目CPU占用过高进而影响到节点上所有的服务]
• 部署步骤繁琐：想要部署一个服务，必须得一台一台的进行部署；
• 有操作风险：开发人员直接操作服务器，有存在误操作的风险（sudo rm -rf /*）。
• 服务启动速度慢。

2.docker 容器化部署（公司目前使用的部署方式）

服务部署架构图

优点

• 使用方便：只需要拉取镜像、运行镜像 两步操作即可运行一个服务;
• 隔离性好：一个容器一个运行环境，互不影响，运行时分配好内存，如果某一个服务出现内存泄漏、CPU占用高等问题，只会影响当前容器，不会触及到其他容器;
• 快速回滚：当前版本如果出现问题，可以快速的拉取前一个容器的版本，如果使用上面那个部署形式则需要使用git回滚完，再重新打包部署;
• 系统利用率高：docker对系统资源的利用率更高，无论是应用执行速度，内存损耗或者文件存储速度，都要比传统虚拟机技术更高效。因此，相比虚拟机技术，一个相同配置的主机往往可以运行更多数量的应用;
• 启动服务的速度更快。

缺点

• 管理麻烦：随着业务的不断发展，微服务不断的增加，导致容器太多管理麻烦，增加运维成本；
• 误操作风险：跟上面那一张部署方式一样，开发人员直接操作服务器，有一定的风险；
• 学习成本：稍微需要一点容器相关的知识，需要学习docker常见的一些命令
• 其他的暂时没太关心。

3.k8s容器化部署（现在公司需要升级的部署方式）

服务部署架构图

名词解释

• Node：单台主机，可以是物理的或虚拟的计算机。结点分为主结点(master)和工作结点(worker) – 个人理解：一个节点就是一台服务器（实例）
• Master：k8s 集群控制节点，对集群进行调度管理，接受集群外用户去集群操作请求
• Pod：K8s中的工作单元，服务运行的最小单元。每个Pod中包含一至多个容器；一个Pod的容器在K8s集群中有相同的地址和端口范围，即容器暴露于K8s集群的端口号不可重复- 个人理解：一个每个Pod就是k8s虚拟出来的一个微型服务器，它有自己的虚拟IP、端口等等
• Deployment：无状态工作负载，个人理解：就是管理Pod的，负载Pod的扩缩容等操作。
• StatefulSet：有状态工作负载，与Deployment一样。不同点在于 Deployment的Pod名称,主机名称 ,存储等都是随机,不稳定的，所以不适合数据库等需要持久化的服务器运行，而StatefulSet就可以。

优点

• 自动部署和回滚：我们可以直接通过k8s控制台一键实现目标版本代码的回滚、部署。
• 服务发现和负载均衡：Kubernetes 可以使用 DNS 名称或自己的 IP 地址来曝露容器。 如果进入容器的流量很大， Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。
• 自我修复：Kubernetes 将重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器。
• 不需要直接操作服务器：控制台操作，简化了部署流程，减少了运维成本，开发人员无需关注服务器运维相关事情。
• 资源调度：当node节点上的CPU、内存不够用的时候，可以扩充node节点，新建的pod就会被调度到新扩充的node节点上。
• 故障迁移：当某一个node节点关机或挂掉后，node节点上的服务会自动转移到另一个node节点上，这个过程所有服务不中断
• 资源隔离：可以通过创建开发、测试、预发、生产等命名空间实现不同环境的隔离，各环境之间互不影响。
• 扩缩容方便：只需要在控制台调整每个Deployment中Pod的数量就可以实现自动扩缩容。
• 减少了公司运维成本
• Docker有的其他优点。

缺点

• 部署麻烦（自己搭建）
• 占用资源多（自己搭建）
• 运维成本高（自己搭建）

综上所述：咱们使用云商搭建好的k8s，所以说目前对我们来说没有什么缺点 -- 嘿嘿~。

二．k8s部署、服务调用链路相关

1.简介

就不介绍了，有兴趣的可以看一下官方文档：https://kubernetes.io/zh-cn/docs/concepts/overview/

2.基本概念

Pod里是容器，Pod被ReplicaSet管理，ReplicaSet控制pod的数量；

ReplicaSet被Deployment管理，Deployment控制pod应用的升级、回滚，当然也能控制pod的数量。

Service提供一个统一固定入口，负责将前端请求转发给Pod

3.调用链路

1.目前公司前后端服务调用链路

前端

1、 前端访问域名；

2、 域名DNS解析到部署前端项目的服务器（集群：则解析到集群对应的SLB负载均衡公网IP上—SLB负责具体将请求打在某一台服务器上）；

3、 被请求的服务器用Nginx通过域名加目录的形式将请求转发到不同的前端项目。

后端接口

1、 访问api接口

2、 域名DNS解析到部署网关服务器（集群：则解析到集群对应的SLB负载均衡公网IP上—SLB负责具体将请求打在某一台服务器上）；

3、 被请求的服务器用Nginx将请求转发到当前服务器的Gateway网关

4、 网关对请求接口进行鉴权、匹配路由等操作。

5、 通过Nacos自带负载均衡Ribbon负载到具体某一个应用服务

6、 返回结果请求结束。

2.使用k8s部署后，前后端调用链路

前端

1、SLB监听80和443端口。

2、请求进来进行域名DNS解析，解析到集群暴露出来的公网SLB的IP上。

3、经过nginx Ingress 转发匹配请求路径，将请求转发到不同的Server(一个Server对应一个Deployment，对应一个项目)上。

4、Server会通过k8s自身的负载均衡算法将请求负载到某一个Pod上面（这一步k8s内部有一个负载均衡选择具体服务的哪一个Pod）

5、访问到具体的Pod，返回结果。

后台接口

1、 SLB监听80和443端口。

2、 请求进来进行域名DNS解析，解析到集群暴露出来的公网SLB的IP上。

3、 经过nginx Ingress 转发到对应的gateway网关Server上。

4、 Server会通过k8s自身的负载均衡算法将请求负载到某一个网关Pod上面。

5、 网关对请求接口进行鉴权、匹配路由等操作。

6、 通过Nacos自带负载均衡Ribbon负载到具体某一个应用服务

7、 返回结果请求结束。

4.阿里云流水线 + Kubernetes 镜像升级部署实践

K8s镜像部署

先进行镜像构建 如下两步操作并运行流水线

在k8s管理界面的[工作负载]-->[无状态]目录根据需要部署的环境切换命名空间，如：测试环境(namespace-dev)

创建对应的Deployment与pod

点击右上角“使用镜像创建”、对k8s编排掌握好的可以直接使用yaml创建，推荐使用镜像创建。

a.填写对应的应用服务信息

b.选择对应的镜像和版本（刚才创建的）

其他的不需要填、如果有提示不能为空的直接删掉就可以了

c.下一步直接点击创建、完成后出来到无状态目录下找到创建的Deployment，点击去--->容器组-->点进去--->日志（进行日志查看）

k8s镜像升级

回到流水线页面在构建镜像的基础上新建一个部署任务--Kubernetes镜像升级，注意:命名空间、Deployment名称、容器名称不要填错。

这样就完成了k8s镜像的升级

网站题目：小公司的应用服务部署历程
网站URL：http://chengdu.cdxwcx.cn/article/dscgeco.html