聊聊微服务集群当中的自动化工具

本篇博客主要介绍了自动化工具这个概念，在微服务集群当中的做用，算抛砖引玉，欢迎你们提出本身的看法。

写在前面

在了解自动化工具的概念以前，咱们先了解一下微服务和集群的概念。

什么是微服务

这个概念其实有些普遍，而个人知识广度也有限，我会尽可能用通俗的语言来描述什么是微服务，什么是集群，以及为何咱们须要微服务集群 。为何须要集群能够去看看《小强开饭店-从单体应用到微服务》，这篇文章用很是通俗的语言和配图，经过一个漫画故事简单的解释了为何咱们须要微服务集群。

微服务

传统的后端服务多为单体应用，例如使用Sprint Boot或者Node又或者Gin搭建的简单的后端服务，在此基础之上，实现了基本的业务以后再部署到服务器上运行起来，这就成为了一个单体应用。

随着业务需求的增长、业务代码慢慢的累加，单体应用变的也愈来愈大。同时各个模块的大量业务代码相互纠缠在一块儿，开发以及维护变得尤为困难。想象一下一个刚刚加入项目的新人看到相互纠缠的、逻辑复杂的业务代码的绝望。

这个时候咱们就须要了解微服务的概念了。若是想要讲这个庞大的单体应用可维护、可扩展以及高可用，咱们就须要对单体应用按照模块进行业务拆分 。

例如将用户相关的全部逻辑单独搞成一个服务，又例如订单、库存能够搞成一个单独的服务。这样一来，业务代码被分散到几个单独的服务中，每一个服务只须要关心、处理本身这个模块的业务逻辑。这样一来，业务代码的逻辑清晰，对开发人员来讲，条理以及思路都很清晰。即便是后加入的项目开发人员，面对业务逻辑清晰的代码也十分容易上手。

微服务的拆分

其实我看到不少的文章关于微服务的介绍就基本到这了，可是还有个值得提的概念。首先，微服务怎么拆分实际上是没有一个标准的。

你按照什么样的粒度去拆分你的服务实际上是跟业务强相关的。并非说一个服务的代码必定就不多，根据你的业务的量度，例如你的系统用户量特比的大，那么一个用户服务的代码量上千上万行我以为都很正常。

固然我也见过用户不是不少，只是为了高可用和快速定位，而将系统拆分的很是细的系统，有好几十个服务。那么问题来了，有这么多服务，前端须要去维护的后端API的地址就至关的庞大了。

咱们暂且先不讨论全部拆分的服务是否运行在同一个服务器上，就算是，那也得是不一样的端口。前端也须要根据后端拆分的服务模块，去维护这样一张API的映射表。因此咱们须要提出一个BFF，AKA Backend For Frontend.

BFF

其实BFF层最初被提出来，其实不是为了微服务拆分模块中提到的目的。其设计的目的是为了给不一样的设备提供不一样的API。例如一个系统的后端服务，同时须要支持不一样的终端，例如移动端的iOS和Android，PC端。

这样一来，能够根据不一样设备上的需求来提供对应的API，并且不须要更改咱们现有的微服务。

这样一来，咱们的底层服务群就具备了很强的扩展性，咱们不须要为一个新增的客户端来更改底层的服务代码，而是新增一层BFF层，来专门针对该终端类型去作适配。

你们从上面的图能够看出来，客户端都没有直接访问咱们的底层服务。而是都先通过BFF层提供的接口，再由BFF层来根据不一样的路由来调用不一样的底层服务。总结一下，加了BFF层的优势以下。

• 扩展性强，能够适应不一样的客户端
• 统一的API管理，客户端无须再维护API的映射表
• 可作集中鉴权，全部的请求都会先通过BFF，可在这一层对调用接口的合法性进行验证

固然，BFF也有缺点。

• 处理不当会有大量的代码冗余
• 因须要调用不一样底层的服务而增大开发的工做量

固然在实际的生产环境下，咱们也不多会将BFF层直接暴露给客户端。咱们一般会在BFF层上再加一层网关。网关能够在请求尚未到BFF的时候，实现权限认证，限流熔断等等其余的功能。

集群

上面简单的聊了一下什么是微服务，如今咱们来聊聊什么是集群。咱们知道，当一个单体应用大的已经很难维护的时候，最好的办法就是将其拆分红微服务。这样有什么好处呢？

• 便于维护。每一个微服务专一于本身这个模块的业务逻辑，不会存在各个模块的业务逻辑缠在一块儿的情况。
• 提升可用性。当单体应用挂掉的时候，咱们系统的全部模块都将不可用。而拆分红微服务就能够尽可能的避免这个问题。单个服务挂掉了，不会影响到其余服务的正常运行。
• 便于运维。单体应用从新部署的时候，会使整个系统不可用。而在微服务中，单个服务从新部署的代价明显要小的多。

概念

说了这么多，咱们来给集群一个概念吧。集群就是将同一套服务部署在不一样的服务器上，对外提供服务。

例子

我举个具体的例子。例如咱们使用Docker Swarm来提供容器的集群服务。

在Docker Swarm中有节点这样一个概念，凡是运行了Docker的主机均可以主动的建立一个Swarm集群或者加入一个已经存在的集群，一旦加入，这个主机就成为了这个集群中的一个节点。在集群中节点分为两类，分别是管理节点（manager）和工做节点（worker）。咱们能够用Portainer来管理Docker主机和Swarm集群。

咱们以一个集群中的请求来举个例子。

首先进入系统以后会先进入一个统一鉴权的系统去鉴权，鉴权成功以后就会到咱们的微服务网关，若是这个地方还有系统本身的特殊鉴权的话，再次进行鉴权。以后网关这边会将咱们的请求根据配置的路由来分发到具体的某个服务器上的某个容器中。

自动化工具

自动化工具的都包含了哪些技术呢？

其中的Java只是一个类比，表明你的编程语言。微服务中其实不是很关心具体用的什么语言，甚至每一个服务都用不一样的技术栈都行。

那么自动化工具是什么呢？其做用是什么？在集群中扮演了什么样的角色呢？咱们经过一张图来简单的了解一下。

构建

简单的梳理一下逻辑。

• 首先自动化工具将Jenkins构建所须要的参数组织好，调用Jenkins的构建API，并记录构建操做到自动化工具的数据库
• 而后Jenkins用配置好的凭证去Gitlab的对应的项目的分支拉取代码，根据配置好的构建脚本开始构建，记录构建记录到自动化工具的数据库
• 构建好后再推送到docker的仓库中，并记录到自动化工具的数据库

到此构建的逻辑结束。

其余的功能

自动化工具还能够直接在项目列表中，选择查看当前项目的日志，而不须要每次从新打开Kibana而后再加筛选filter。

自动化工具的项目设置中，咱们还能够更改docker容器的配置，而不须要再去portainer中或者经过命令行去修改；若是想要命令行进入容器，首先咱们得找到对应的service，而后找到对应运行的service实例，而后才能进入，而若是咱们直接使用portainer的Api，在endpoint已知的状况下，能够直接将这个功能作到自动化工具中，直接使用webshell一键链接。

其好处是什么呢？

• 对大部分开发屏蔽Swarm集群。对项目中非管理员的开发屏蔽Portainer，由于这个权限很是大，一旦不熟悉致使了误操做，那么有可能直接影响到线上的服务
• 统一权限控制。在自动化工具里作权限以及环境的统一控制
• 上手成本低。比起直接操做portainer和Jenkins和Kibana，本身搭建的自动化工具十分容易上手

功能总结

总结一下，其功能主要为如下几个。

• 构建
• 部署
• 回滚
• 查看elk日志
• 更改docker配置
• 管理集群的环境、项目和容器
• 命令行链接具体项目的容器
• …...

看到这你们可能会有疑问。

• 构建？你的意思是我Jenkins是摆设咯？
• 部署？更改 docker配置？命令行链接具体项目的容器？个人Iterm2也是个摆设？
• 回滚？等因而我以前的docker镜像的tag白打了？
• elk日志？个人Kibana是拿来看新闻的吗？

功能详解

构建

其实在构建这块，我我的认为自动化工具和Jenkins都很方便。并且自动化工具自己就是用的Jenkins，只不过是调用了Jenkins的API，传递了构建的参数，最终真正去构建的仍是Jenkins。

只不过对于刚刚加入项目的测试来讲，本身开发的Web UI对新人更加的友好，并且能够在自动化工具中作到权限控制。

部署和回滚

部署在自动化工具的后端经过docker-client实现。首先咱们根据配置，建立docker client。而后若是已经有在运行的服务了，就调用update service更新服务，不然就建立服务。

回滚与其本质相同，只不过是用了以前的参数和不一样的tag。

elk日志

首先，每一个环境的配置中，会配置上kibana_host以及kibana_index，而后根据系统的projectKey，拼接成相应的Kibana日志的url，而后使用iframe嵌入到自动化工具中。这样一来就不用再手动的打开Kibana再去设置对应的filter了。特别是当你系统特别多的时候，添加和删除filter是很废时间的。

更新容器配置

这里也一样是调用对应的API更新对应服务的配置，而不用登陆portainer去修改。

同时，在自动化工具中还能够针对不一样的环境配置不一样的Base Setting。后续在该环境下添加的应用不用再单独配置，直接继承环境的Docker Setting便可。

管理集群的环境、项目和容器

能够经过自动化工具统一的来建立和管理环境，一样有三种环境，研发、测试、生产环境。而后能够在自动化工具中建立角色和用户，分配给不一样的角色不一样的权限来达到控制权限的目的。

命令行链接具体项目的容器

一般咱们由于某个需求，须要进入到容器中查看，然而此时咱们就面临两种选择。

• 经过portainer进入对应service，找个某个具体的container，点击链接
• 命令行到容器具体运行的某个服务器上，而后再经过命令行链接

可是有了自动化工具，咱们就有了第三种选择。

• 点击链接

怎么实现的呢？实际上就是经过endpointId去获取到全部的container的信息，而后遍历全部的container，找到与当前选中的containerId相同的容器，获取到其NodeName，这样一来咱们就知道当前这个容器到底运行在哪一个节点上的了。

而后经过已有的信息，构建WebSocket的url，最后前端经过xterm来创建ws链接，就这样直接链接了正在运行的容器实例。

总结

自动化工具只是一种思路，一种解决方案，它的好处在上面也列出了不少。固然，它确定也有坏处，那就是须要专门投入人力和资源去开发。

这对于人手紧缺和项目周期较短的项目组来讲，十分的不现实。可是若是一旦有精力和时间，我以为值得一试。同时，基于portainer的API，咱们还有可能将更多与集群相关的功能，集成到自动化工具上。

往期文章：

• 什么？你居然尚未用这几个chrome插件？
• 手把手教你从零开始搭建SpringBoot后端项目框架
• 用go-module做为包管理器搭建go的web服务器
• WebAssembly彻底入门——了解wasm的前世今身
• 小强开饭店-从单体应用到微服务

相关：

• 微信公众号： SH的全栈笔记（或直接在添加公众号界面搜索微信号LunhaoHu）