部署

批注 2020-06-20 084736

微服务生产环境

批注 2020-06-20 084255

持续集成

持续集成的一个主要作用是保证新提交的代码与已有代码进行集成

真正的持续集成

  • 代码应该频繁地被集成
  • 应该有测试来验证正确性
  • 构建失败后的第一任务时修复失败

微服务与持续集成

有三种方式来分别管理微服务代码库与CI服务器

  • 所有微服务存于一个代码库,一个CI服务器

这种方式在项目初期可以行得通,但是会造成每次提交代码都会对所有服务进行集成,而且可能一个服务集成失败也会影响到原来正常的服务

  • 所有微服务共享一个代码库,但是每个服务拥有一个独立的CI构建过程

这样的情况下,跨服务修改会变得困难

  • 所有微服务拥有自己的代码库,以及自己的CI构建过程

构建流水线与持续集成

把一个复杂的构建流程分成许多个阶段,称之为构建流水线,不仅能更早地发现错误,而且可以很好地反映软件的质量

批注 2020-06-20 091325

  • 持续交付(CD)基于以上概念

平台特定构建物

不同的技术栈最后的构建物使用、安装不尽相同,所以很需要一种通用的技术来对这些构建物进行处理

  • 操作系统构建物

一种屏蔽这种技术栈差异的方式是使用操作系统构建物,也就说操作系统能直接执行的文件

  • 镜像

通过虚拟化平台,创建一个包含软件所需环境的镜像,这样就可以快速进行部署,并且屏蔽底层细节

甚至可以直接将镜像作为构建物,最后只需启动镜像即可

有时候,如果机器修改了一些配置,就会造成实际配置与源代码管理中的配置不一致,这称为 配置飘逸 ,所以需要有一种技术,能够禁止对部署镜像服务器的所有修改,也就是不可变服务器

服务配置

对服务的配置,可以使用一个专用系统来处理,称之为 配置中心

服务与主机

  • 单主机多服务

    由于虚拟化基础设施本身也会占用一定的资源,所以这种方式本身虽然能提高资源的利用率,但会造成一些问题:

    1. 监控变得更加困难
    2. 放弃了微服务能独立部署不同服务的好处
    3. 不利于团队的自治性
    4. 增加了扩展的复杂性
  • 应用程序容器

    诸如tomcat等的容器可以让多个服务运行在同一个进程里,但这种方式不仅会限制技术栈的选择,而且还会使监控、分析等变得更加困难

  • 一台主机一个服务

代表技术是虚拟机与容器

这种方式虽然浪费了一些资源,但是可以减少潜在的单点故障以及拥有更多的技术栈选择

  • 调度模型

批注 2020-06-20 085322

  • 平台即服务(paas)

属于serverless,近些年越来越受青睐

将底层机器的管理全部交给云,只需要提供一个软件,就能帮你运行

部署方式

蓝绿部署

有时候,某些问题只有在特定环境下才能出现,蓝绿部署就是部署新版本服务后,不停止老版本服务,先对新服务运行一些测试,如果没问题就把流量从老服务转发到新服务,一旦出现问题,快速切换回老服务。

但需要你能切换生产流量到不同的主机以及拥有足够的主机来部署两个服务

金丝雀发布

金丝雀发布则是将部分生产流量从老服务切换到新服务,来验证系统是否按预期执行,金丝雀发布与蓝绿部署的区别在于,金丝雀发布老旧版本共存时间较长,而蓝绿部署一旦确定新系统没问题,就会关停老系统

批注 2020-06-20 090146

自动化

微服务的引入,主机数量肯定会上升,如果手动管理这些机器,恐怕没那么容易,引入自动化能很好地提升工作效率

虚拟化

传统的虚拟化

传统的虚拟化技术,运行在操作系统之上的一个虚拟机软件,这个虚拟机软件再虚拟出硬件给操作系统运行

轻量级虚拟化

  • Hypervisor
  • vagrant
  • linux容器
  • docker

容器化部署

批注 2020-06-20 090357

容器化集群部署

通过软件工具管理共享主机资源池,屏蔽主机层

批注 2020-06-20 085322

部署接口

使用一个统一的部署接口来部署服务

构建这样的一个系统工作量很大,但是到后期,这些都是值得的

results matching " "

No results matching " "

results matching " "

No results matching " "