部署:持续集成（CI）与持续交付（CD）——《微服务设计》读书笔记

Posted 2020-09-08 西门吹牛

    系列文章目录：

    《微服务设计》读书笔记大纲

 

一.CI（Continuous Integration）简介

　　 CI规则1：尽量频繁地把代码签入到分支中以进行集成

　　CI规则2：不光要对语法进行验，也要提供一系列的自动化来验证

　　CI规则3：CI失败后，要把修复CI当做第一优先级的事情

　　说明：作为CI流程的一部分，我们提供的制品应该每次只生成一次，然后在所有的部署一切使用，这不仅避免多次重复做一件事情，还可以保证部署上线的制品与测试通过的那是同一个。

 

二.把CI映射到微服务

     这里有几种做法：

    做法1：所有的东西都放在一起，向代码库的任何一次提交都会触发构建，同时会构建出多个制品。

    一般来说，我们绝对应该避免这个模式，但在项目初期是个例外。我即使只修改一个服务的一行代码也需要进行整体的验证和构建，事实上这有可能是不需要的，这会影响CI的周期。

    做法2：将每个CI映射到代码库中不同的目录，这种做法比第一种好。

    做法3：每个服务都有自己的代码库，都有自己的CI，这样就更加独立了。

 

三.CD（Continuous Delivery）简介

     正如我们项目组正在使用的PipeLine，这就是一个CD产品，它告诉我们每个步骤是否完成，距离最终的产品交付还有哪几项，软件质量的可视化得到了极大改善。

     

 

四.制品的选择

     Java可以生成Jar包和War包，Ruby有gem，它们在运行的时候需要特定的环境，Chef、Puppet、Ansible是集中配置管理系统，支持一些通用技术栈的构建物部署。

     我们也可以选择生成与操作系统相关的制品，如RedHat或CentOS的RPM、Ubuntu的deb包、Windows的MSIqn。使用操作系统的制品好处是，不需要考虑底层使用的是什么技术，只需要简单使用内置的工具就可以完成软件的安装。

     如果使用自动化配置管理工具来管理环境问题，一个问题是，需要花费大量的时间运行这些脚本，它们会一遍遍地安装 这些重复的工具，而且还可能有新的软件加进来，其安装时间会继续被拉长。我们可以使用虚拟机镜像，在部署软件时，只需要根据镜像创建一个实例，之后在其安装最新的微服务即可，不需要再花费时间来安装依赖，因为它们已经在镜像中安装好了，这样可以节省很多时间。但安装镜像也会花费很多时间，同时不同平台的镜像是不一样的，我们可以通过Packer来解决这个问题，它可以从Chef、Ansible、Puppet中的同一套配置中生成不同平台的镜像。

     那么，我们可能将微服务也包含在镜像中，那么当你启动镜像时，微服务就已经就绪了。

     但这同时也会带来一个问题，有人会进生产服务器修改其中某一台的配置，导致配置漂移问题，怎么办？应该禁止对任何运行的服务器做手动修改。

 

五.服务的配置管理

     对于不同的生产环境有不同的配置，我们应该如何处理？应该最小化环境间配置的差异，比如用来连接数据库的用户名和密码。

    另外，配置文件应该单独管理，如IT部正在使用的JFrog制品库。

 

六.服务与主机之间的映射

      这样的形式有多种。

      第1种：单主机多服务

      这种方式简单，但是也会存在挑战，如监控困难，我们不知道哪个服务使用CPU的频率更高一点，同时服务之间会造成影响，一个服务可能会造成系统资源用尽，这样其他服务也会有相应的影响。

      第2种：应用程序容器

      这种方式，从根本上说，是想试图优化资源的使用，但现在云服务的出现使得已经没有必要了。

      这种方式将5个Java服务打包在一个容器（如Jetty）中，这样不可避免地限制了技术的选择，同时在聚合监控时也会难以支持。

      第3种：每个主机一个服务

      这种方式很容易对服务进行扩展，安全性也可以在更小的范围内进行，但主机数据的增加也会是个问题。

      第4种：使用Pass（平台即服务）

      Pass平台会提供一些特定制品（如Java Jar包或Ruby 的gem等）的支持，还会帮你自动配置机器然后运行，能够透明地对系统进行弹性管理，允许你控制运行服务的节点数量，Pass平台帮你处理其他的工作。

 

七.如何管理微服务带来的大量主机：自动化

       为了让你从众多的服务器中解脱出来，你需要自动化，你需要写一行代码来启动或开户一个虚拟机，你需要能够自动部署软件，你需要自动完成数据库的变更。

      方法1：传统的虚拟化技术

              

      如上图所示，这就是传统的虚拟化技术，在操作系统之上，存在着Hypervisor，它的任务主要有两个，对CPU和内存资源做从虚拟主机到物理主机的映射和给上层提供一个控制的层，但Hypervisor也需要一定的资源来完成自己的工作，它也会占用CPU、IO和内存等，Hypervisor主机越多，占用的资源就越多。

      方法2：Vegrant

      这是一个部署平台，通常在开发和测试环境中使用，可以在一台机器上创建一个虚拟的云，它的底层使用的是标准的虚拟化系统，比如你可以同时创建多个VM，通过关掉其中的几台来测试故障模式，并且可以把本地目录映射到虚拟机上，这样就可以在修改代码后立即查看效果。

      方法3：Linux容器

      Linux容器可以创建一个隔离的进程空间，进而在这个空间运行其他的进程。在Linux中，进程必须由用户来运行，并且根据权限的不同拥有不同的能力，进程可以创建其他进程，举个例子，如果我在终端启动了一个乾，你可以认为它是终端程序的子进行，Linux内核的任务就是维护这个进程树。

      Linux容器扩展了这一想法，每个容器就是整个系统进程树的一棵子树，内核已经帮我们完成了给这些容器分配物理资源的任务， LXC就是这样一种容器（类似的还有Solaris Zones、Open VZ），它的基本结构如下：

             

      它不再需要Hyervisor，其实尽管每个容器可以运行不同的操作系统发行版，但必须共享相同的内核，因为进程树存在于内核中，这意味着，我们的主机操作系统可以是Ubuntu,而在容器中可以运行CenOS，只要它们的内核相同即可。

      容器更轻量，所以在相同的硬件上能够运行的容器数量比虚拟机要多得多，而且启动速度更快，但容器在隔离性上也还存在一定问题。

      方法4：Docker

      Docker是构建在轻量级容器之上的平台，它帮你处理了大多数与容器管理相关的事情，你可以在Docker中创建和部署应用，这些基于容器的应用与VM镜像很类似，Docker也能管理容器的配置，并帮你处理一些网络问题。

      Docker本身并不能解决所有的问题，它只是一个在单机上运行的简单的Paas，你还需要一些工具来帮你管理多台机器上的Docker实例上的服务。比如，当你向这些工具请求一个容器时，它会帮你找到容器并运行它。Google的Kubernetes和Deis就是这样的软件。

      Docker+调度工具构成的解决方案介于IaaS和PaaS之间，我们可以称之为CaaS（容器即服务）。

 

八.使用自动化脚本

       参数化的命令行调用是任何部署的最合理方式，可以使用CI工具来触发脚本的调用，从Windows的Bash到Python Fabric脚本等，好处是一次编写后面基本不用改了，也可以使用Terraform、Salt Stack这样的工具。

 

参考

      《微服务设计》（Sam Newman 著 / 崔力强 张骏 译）