当前位置：首页 > AI > 正文内容

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

邻居的猫1个月前 (12-09)AI509

0 前语

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

1 微服务的坏处

1.1 测验、发布作业量剧增

单体运用拆分红多个微服务后，虽能完结快速开发迭代，但带来更大测验和运维布置的本钱。

许多事务前期便是一个大的单体Web运用，测验和运维时，只需把Web运用打WAR包，布置到Tomcat完事
拆成微服务后，许多事务需求就需一起修正多个服务的代码，那么这些服务都要打包、测验和发布上线，还要测验这些服务接口的功用，最终发布上线多个体系，测验和运维作业量增都剧增。这个时分就需求有方法可以减轻测验和运维的担负，我在上一讲给出的处理方案是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