小公司的应用服务部署历程

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

一.常见服务部署架构

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里是容器,PodReplicaSet管理,ReplicaSet控制pod的数量;

ReplicaSetDeployment管理,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镜像的升级

点赞