先声明一下：我所在的公司是一个小团队，做物联网相关的，前后端、硬件、测试加起来也就五六十个人左右；本人的岗位是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镜像的升级