微服务、容器、DevOps的三角恋

0 前言

容器的普及，带来了微服务架构和DevOps的高速发展。

1 微服务的弊端

1.1 测试、发布工作量剧增

单体应用拆分成多个微服务后，虽能实现快速开发迭代，但带来更大测试和运维部署的成本。

1. 很多业务早期就是一个大的单体Web应用，测试和运维时，只需把Web应用打WAR包，部署到Tomcat完事
2. 拆成微服务后，很多业务需求就需同时修改多个服务的代码，那么这些服务都要打包、测试和发布上线，还要测试这些服务接口的功能，最后发布上线多个系统，测试和运维工作量增都剧增。这个时候就需要有办法能够减轻测试和运维的负担，我在上一讲给出的解决方案是DevOps。

DevOps可理解为开发和运维的结合，服务的开发者不再只负责服务的代码开发，还要负责服务的测试、上线发布甚至故障处理等全生命周期过程，就能把测试和运维从微服务拆分后所带来的复杂工作中解放。
DevOps要求开发、测试和发布流程自动化，这就需保证开发人员将自己本地部署测试通过的代码和运行环境，能够复制到测试环境，测试通过后再复制到线上环境发布。虽然看上去就是复制代码，但实际上本地环境、测试环境及线上环境往往是隔离，软件配置环境差异很大，导致开发、测试和发布流程割裂。

1.2 机器初始化复杂度剧增

弹性扩缩容时不同微服务所要求软件运行环境差异带来的机器初始化复杂度的提升。拆分后的微服务相比原来大单体应用更灵活，经常要根据实际访问量做在线扩缩容，而且通常会采用在公有云上创建的ECS扩缩容。
这又给运维带来挑战，因为公有云上创建的ECS通常只包含基本os环境，微服务运行依赖的软件配置等需运维单独初始化，因不同微服务的软件配置依赖不同，比如Java服务依赖JDK，就需在ECS安装JDK，而且可能不同微服务JDK版本也不同，服务部署的初始化工作十分繁琐。

2 还好有你:容器

容器技术解决了本地、测试、线上环境的隔离，解决部署服务初始化繁琐的问题。
容器，即Container可翻译成集装箱，在港口把货物用集装箱封装起来，然后经过货轮从海上运输到另一个港口，再在港口卸载后通过大货车运送到目的地。如此货物便可在任何地方流转时，都封装在集装箱，无需根据是在货轮还是大货车而对货物重新装配。
软件的容器也就这么个作用，它封装的是软件的运行环境。容器本质是Linux里的进程，但容器通过Namespace和Cgroups，可有自己的root文件系统、网络配置、进程空间，甚至自己的用户ID空间，如此容器里的进程就像运行在宿主机上的另外一个单独的os内，从而实现与宿主机os里运行的其他进程隔离。

Docker即是基于Linux内核的Cgroups、Namespace实现进程的封装和隔离。
虽然容器解决了应用程序运行时隔离问题，但要想实现应用能从一台机器迁移到另外一台机器上还能正常运行，就必须保证另外一台机器上的os一致，而且应用程序依赖的各种环境也必须一致。Docker镜像就解决了这个痛点。
即Docker镜像不仅可打包应用程序本身，而且还可打包应用程序的所有依赖，甚至包含整个os。这样在本机上运行通过的应用程序，就可使用Docker镜像把应用程序文件、所有依赖的软件以及os都打包成一个镜像，可在任何一个安装了Docker的地方运行。

Docker镜像解决了DevOps中微服务运行的环境难以在本地环境、测试环境以及线上环境保持一致的难题。如此一来，开发就可以把在本地环境中运行测试通过的代码，以及依赖的软件和操作系统本身打包成一个镜像，然后自动部署在测试环境中进行测试，测试通过后再自动发布到线上环境上去，整个开发、测试和发布的流程就打通了。

无论使用内部物理机还是公有云的机器部署服务，都可利用Docker镜像封装微服务运行环境，从而屏蔽机器内部物理机和公有云机器运行环境的差异，实现同等对待，降低运维复杂度。

3 微服务容器化实践

Docker解决服务运行环境迁移问题，因为在使用Docker镜像时并非把：

• 业务代码
• 依赖的软件环境
• os

直接打包成镜像，而是利用Docker镜像的分层机制，在每层编写Dockerfile逐层打包镜像。因为虽不同微服务依赖软件环境不同，但还是存在相同部分。因此打包Docker镜像时，可分层设计、逐层复用，减少每层镜像文件大小。

4 业务案例

某Docker镜像分四层：

• 基础环境层：定义os运行的版本、时区、语言、yum源、TERM等
• 运行时环境层：定义业务代码的运行时环境，如Java代码的运行时环境JDK的版本
• Web容器层：定义业务代码运行的容器的配置，如Tomcat容器的JVM参数
• 业务代码层：定义实际的业务代码的版本，如是V4业务还是blossom业务

如此，每层镜像都基于上层再添新内容，如V4业务的Dockerfile：

# FROM代表上层镜像文件为tomcat_feed:jdk8.0.40_tomcat7.0.81_g1_dns，可见该层包含JDK和Tomcat及其版本和JVM参数等
FROM registry.intra.xxx.com/xxx_rd_content/tomcat_feed:jdk8.0.40_tomcat7.0.81_g1_dns

# ADD，要在该层镜像添加的文件，主要包含业务的代码和配置
ADD confs /data1/confs/
ADD node_pool /data1/node_pool/
ADD authconfs /data1/authconfs/
ADD authkey.properties /data1/
ADD watchman.properties /data1/
ADD 200.sh /data1/xxx/bin/200.sh
ADD 503.sh /data1/xxx/bin/503.sh
ADD catalina.sh /data1/xxx/bin/catalina.sh
ADD server.xml /data1/xxx/conf/server.xml
ADD logging.properties /data1/xxx/conf/logging.properties
ADD ROOT /data1/xxx/webapps/ROOT/

# RUN，该层镜像启动时需要执行的命令
RUN chmod +x /data1/xxx/bin/200.sh /data1/xxx/bin/503.sh /data1/xxx/bin/catalina.sh

# WORKDIR，该层镜像启动后的工作目录。如此便可通过Dockerfile基于上层镜像完成该层镜像制作
WORKDIR /data1/xxx/bin

5 总结

正因Docker可做到一处通过、到处运行，对业务价值极大，解决以前应用程序在开发、测试及生产环境间移植难，提高运维自动化水平，也为DevOps理念流行和业务上云提供基础。

当然Docker也带来新问题，如旧的针对物理机的运维模式无法适应，需要新的容器运维模式。

本文已收录在Github，关注我，紧跟本系列专栏文章，咱们下篇再续！

作者简介：魔都架构师，多家大厂后端一线研发经验，在分布式系统设计、数据平台架构和AI应用开发等领域都有丰富实践经验。

各大技术社区头部专家博主。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。

负责：

• 中央/分销预订系统性能优化
• 活动&券等营销中台建设
• 交易平台及数据中台等架构和开发设计
• 车联网核心平台-物联网连接平台、大数据平台架构设计及优化
• LLM Agent应用开发
• 区块链应用开发
• 大数据开发挖掘经验
• 推荐系统项目

目前主攻市级软件项目设计、构建服务全社会的应用系统。

参考：

• 编程严选网