yeedomliu
《微服务设计》第 6 章 部署
关注作者
前往小程序,Get
更优
阅读体验!
立即前往
腾讯云
开发者社区
文档
建议反馈
控制台
首页
学习
活动
专区
工具
TVP
最新优惠活动
文章/答案/技术大牛
搜索
搜索
关闭
发布
登录/注册
首页
学习
活动
专区
工具
TVP
最新优惠活动
返回腾讯云官网
yeedomliu
首页
学习
活动
专区
工具
TVP
最新优惠活动
返回腾讯云官网
社区首页
>
专栏
>
《微服务设计》第 6 章 部署
《微服务设计》第 6 章 部署
yeedomliu
关注
发布于 2019-09-28 12:58:30
738
0
发布于 2019-09-28 12:58:30
举报
文章被收录于专栏:
yeedomliu
yeedomliu
第 6 章 部署
在众多相互依赖的微服务中,部署却是完全不同的情况。如果部署的方法不合适,那么其带来的复杂程度会让你很痛苦
6.1 持续集成简介
CI(Continuous Integration,持续集成)已经出现很多年了,但还是值得花点时间来好好复习一下它的基本用法,因为在微服务之间的映射、构建及代码库版本管理等方面,存在很多不同的选择
CI 能够保证新提交的代码与已有代码进行集成,从而让所有人保持同步。CI 服务器会检测到代码已提交并签出,然后花些时间来验证代码是否通过编译以及测试能否通过
你真的在做CI吗
如果没有持续集成,向微服务架构进行转型就会非常痛苦
即便如此,很多宣称自己在做 CI 的团队并没有真正在做。他们认为使用了 CI 工具就算是采用了 CI 这个实践,事实上,只有工具是远远不够的
用来测试别人是否真正理解 CI 的三个问题
你是否每天签入代码到主线?
你是否有一组测试来验证修改?
当构建失败后,团队是否把修复CI当作第一优先级的事情来做?
6.2 把持续集成映射到微服务
如果从最简单的做法开始,我们可以先把所有东西放在一起。现在我们有一个巨大的代码库,其中包括所有的代码,并且只有一个构建。然后产生多个构建物,所有这些都在同一个构建中完成
一般来讲,我们绝对应该避免这个模式,但在项目初期是个例外
我比较喜欢的方法是,每个微服务都有自己的 CI,这样就可以在将该微服务部署到生产环境之前做一个快速的验证
6.3 构建流水线和持续交付
将构建分解成为多个阶段,从而得到我们熟知的构建流水线。在第一个阶段运行快速测试,在第二个阶段运行耗时测试
CD(Continuous Delivery,持续交付)基于上述的这些概念,并在此之上有所发展。CD 能够检查每次提交是否达到了部署到生产环境的要求,并持续地把这些信息反馈给我们,它会把每次提交当成候选发布版本来对待
我们可以看到一个熟悉的示例流水线
不可避免的例外
在最开始的阶段,把所有服务都放在一个单独的构建中,可以减轻跨服务修改所带来的代价
当服务的 API 稳定之后,就可以开始把它们移动到各自的构建中。如果几周(或者几个月)之后,你的服务边界还是不够稳定,那么再把它们合并回单块服务中(当然还可以在边界内部保持模块性),然后花些时间去了解领域。这也是我们 SnapCI 团队的经验
6.4 平台特定的构建物
但是从微服务部署的角度来看,在有些技术栈中只有构建物本身是不够的。所以为了部署和启动这些构建物,需要安装和配置一些其他软件,然后再启动这些构建物。类似于 Puppet 和 Chef 这样的自动化配置管理工具,就可以很好地解决这个问题
6.5 操作系统构建物
有一种方法可以避免多种技术栈下的构建物所带来的问题,那就是使用操作系统支持的构建物
使用 OS 特定构建物的好处是,在做部署时不需要考虑底层使用的是什么技术。只需要简单使用内置的工具就可以完成软件的安装。这些操作系统工具也可以进行软件的卸载及查询,甚至还可以把 CI 生成的构建物推送到软件包仓库中。其缺点是,刚开始编写构建脚本的过程可能会比较困难
6.6 定制化镜像
使用类似 Puppet、Chef 及 Ansible 这些自动化配置管理工具的一个问题是,需要花费大量时间在机器上运行这些脚本。比如,可能需要使用 collectd 来收集操作系统的状态,使用 logstash 来做日志的聚合,还可能需要安装 nagios 来做监控(
一种减少启动时间的方法是创建一个虚拟机镜像,其中包含一些常用的依赖,
这个方法也有一些缺点。首先,构建镜像会花费大量的时间;其次,产生的镜像可能会很大
6.6.1 将镜像作为构建物
我们可以更进一步,把服务本身也包含在镜像中,这样就把镜像变成了构建物。现在
然后把精力放在镜像创建和部署的自动化上即可。这个简洁的方法有助于我们实现另一个部署概念:不可变服务器
6.6.2 不可变服务器
但是如果部署完成后,有人登录到机器上修改了一些东西呢?这就会导致机器上的实际配置和源代码管理中的配置不再一致,这个问题叫作配置漂移
为了避免这个问题,可以禁止对任何运行的服务器做手动修改。相反,无论修改多么小,都需要经过构建流水线来创建新的机器
6.7 环境
当软件在 CD 流水线的不同阶段之间移动时,它也会被部署到不同的环境中。这些环境之间的不同可能会引起一些问题
6.8 服务配置
服务需要一些配置。理想情况下,这些配置的工作量应该很小,而且仅仅局限于环境间的不同之处,比如用来连接数据库的用户名和密码。应该最小化环境间配置的差异
一个在应对大量微服务时比较流行的方法是,使用专用系统来提供配置
6.9 服务与主机之间的映射
我倾向于使用“主机”(host)这个词来做通用的隔离单元,也就是能够运行服务的一个操作系统
6.9.1 单主机多服务
在每个主机上部署多个服务是很有吸引力的
首先,从主机管理的角度来看它更简单;其次是关于成本。但这个模型也有一些挑战。首先,它会使监控变得更加困难;这个模型对团队的自治性也不利;这个方法会限制部署构建物的选择;会增加对单个服务进行扩展的复杂性
6.9.2 应用程序容器
如果你对基于 IIS 的 .NET 应用程序部署,或者基于 servlet 容器的 Java 应用程序部署比较熟悉的话,那么应该非常了解把不同的服务放在同一个容器中,再把容器放置到单台主机上的模式
这种设置也可以节省语言运行时的开销。比如,在一个 Java servlet 容器中部署五个 Java 服务的话,只需要启动一个 JVM 即可。
我还是认为这种应用程序容器的做法存在很多问题,所以在使用时需要非常谨慎
它会不可避免地限制技术栈的选择
还会限制自动化和系统管理技术的选择
会影响服务的可伸缩性
其中的很多容器启动时间也特别长,这会影响开发人员的反馈周期
6.9.3 每个主机一个服务
这种模型避免了单主机多服务的问题,并简化了监控和错误恢复。这种方式也可以减少潜在的单点故障
但主机数量的增加也可能是个问题。管理更多的服务器,运行更多不同的主机也会引入很多的隐式代价。尽管存在这些问题,但我仍然认为在使用微服务架构时这是比较好的模型
6.9.4 平台即服务
当使用 PaaS(Platform-as-a-Service,平台即服务)时,你工作的抽象层次要比在单个主机上工作时的高。大多数这样的平台依赖于特定技术的构建物
6.10 自动化
想要游刃有余地应对复杂的微服务架构,自动化是必经之路
关于自动化好处的两个案例研究
6.11 从物理机到虚拟机
6.11.1 传统的虚拟化技术
虚拟化技术允许我们把一台物理机分成多台独立的主机,每台主机可以运行不同的东西
6.11.2 Vagrant
Vagrant 是一个很有用的部署平台,通常在开发和测试环境时使用,而非生产环境。Vagrant 可以在你的笔记本上创建一个虚拟的云。它的底层使用的是标准的虚拟化系统(通常是 VirtualBox,但也可以使用其他平台)。你可以使用文本文件来定义一系列虚拟机,并且可以在其中定义网络配置及镜像等信息
但它的缺点是,开发机上会有很多额外的资源消耗。如果一个服务占用一台虚拟机,你可能就很难在本地机器上搭建起整个系统
6.11.3 Linux容器
Linux 用户可以使用另外一种虚拟化的替代方案。相比使用 hypervisor 隔离和控制虚拟主机的方法来说,Linux 容器可以创建一个隔离的进程空间,进而在这个空间中运行其他的进程
6.11.4 Docker
Docker 是构建在轻量级容器之上的平台。它帮你处理了大多数与容器管理相关的事情。你可以在 Docker 中创建和部署应用,这些基于容器的应用与 VM 世界中的镜像很类似。Docker 也能管理容器的配置,并帮你处理一些网络问题,甚至还提供了自己的 registry 概念,允许你存储 Docker 应用程序的版本
另一个基于 Docker 的有趣的工具是 Deis(http://deis.io/),它试图在 Docker 之上,提供一个类似于 Heroku 那样的 PaaS
6.12 一个部署接口
使用统一接口来部署给定的服务都是一个很关键的实践。在很多场景下,都有触发部署的需求,从本地开发测试到生产环境部署。这些不同环境的部署机制应该尽量相似,我可不想因为部署流程不一致,导致一些只能在生产环境才能发现的问题
6.13 小结
首先,专注于保持服务能够独立于其他服务进行部署的能力,无论采用什么技术,请确保它能够提供这个能力。我倾向于一个服务一个代码库,对于每个微服务一个 CI 这件事情,我不仅仅是倾向,并且非常坚持,因为只有这样才能实现独立部署
无论你采用什么技术,自动化的文化对一切管理来说都非常重要
书
《持续交付》
工具
Chef
Puppet
Ansible
本文参与
腾讯云自媒体分享计划
,分享自微信公众号。
原始发表:2019-09-26,如有侵权请联系
cloudcommunity@tencent.com
删除
容器
微服务
容器镜像服务
本文分享自
yeedomliu
微信公众号,
前往查看
如有侵权,请联系
cloudcommunity@tencent.com
删除。
本文参与
腾讯云自媒体分享计划
,欢迎热爱写作的你一起参与!
容器
微服务
容器镜像服务
评论
登录
后参与评论
0 条评论
热度
最新
推荐阅读
LV.
关注
文章
0
获赞
0
目录
第 6 章 部署
6.1 持续集成简介
6.2 把持续集成映射到微服务
6.3 构建流水线和持续交付
6.4 平台特定的构建物
6.5 操作系统构建物
6.6 定制化镜像
6.6.1 将镜像作为构建物
6.6.2 不可变服务器
6.7 环境
6.8 服务配置
6.9 服务与主机之间的映射
6.9.1 单主机多服务
6.9.2 应用程序容器
6.9.3 每个主机一个服务
6.9.4 平台即服务
6.10 自动化
6.11 从物理机到虚拟机
6.11.1 传统的虚拟化技术
6.11.2 Vagrant
6.11.3 Linux容器
6.11.4 Docker
6.12 一个部署接口
6.13 小结
书
工具
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
产品介绍
产品文档
精选特惠 用云无忧
领券
问题归档
专栏文章
快讯文章归档
关键词归档
开发者手册归档
开发者手册 Section 归档
0
0
0
推荐