微服务、容器和DevOps之间的关系
1.微服务与DevOps
1.1 测试、发布工作量剧增
单体应用拆分成多个微服务后，虽能实现快速开发迭代，但带来更大测试和运维部署的成本。
1.很多业务早期就是一个大的单体Web应用，测试和运维时，只需把
Web应用打WAR包，部署到Tomcat完事，
2.拆成微服务后，很多业务需求就需同时修改多个服务的代码。测试
和运维要把这些服务打包、测试、发布上线，同时还要测试这些服
务接口的功能，最后发布上线多个系统，工作量增剧增。
3.这个时候就需要减轻测试和运维的负担，我在上一讲给出的解决方
案是DevOps。
DevOps可理解为开发和运维的结合。服务的开发者不再只负责服务的代码开发，还要负责服务的测试、上线发布和故障处理等全生命周期过程，这样就能把测试和运维从微服务拆分后所带来的复杂工作中解放出来。
DevOps要求开发、测试和发布流程自动化，这就需保证开发人员将自己本地部署测试通过的代码和运行环境，能够复制到测试环境，测试通过后再复制到线上环境发布。虽然看上去就是复制代码，但实际上本地环境、测试环境和线上环境往往是隔离的。软件配置环境差异很大，会导致开发、测试和发布流程割裂。
1.2 机器初始化复杂度剧增
弹性扩缩容时，不同微服务所要求的软件运行环境差异，带来了机器初始化复杂度的提升。拆分后的微服务相比原来大单体应用更灵活，需根据实际访问量做在线扩缩容，并且通常会采用在公有云上创建的ECS扩缩容。
这意味着又给运维带来了挑战。因为公有云上创建的ECS通常只包含基本os环境，微服务运行依赖的软件配置等需运维单独初始化，因不同微服务的软件配置依赖不同，服务部署的初始化工作十分繁琐。比如J ava服务依赖J D K，就需在ECS安装J D K，而且不同微服务J D K版本也可能不同。
2.容器
分布式和微服务的关系容器技术解决了本地、测试、线上环境的隔离，解决部署服务初始化繁琐的问题。
容器，即Co n ta in e r，可翻译成集装箱。在港口用集装箱把货物封装起来，然后通过货轮从海上运输到另一个港口，再在港口卸载后通过大货车运送到目的地。如此货物便可在任何地方流转时，都封装在集装箱，无需根据是在货轮还是大货车而对货物重新装配。
软件的容器也是这个原理。它封装的是软件的运行环境。容器本质是Linux里的进程，但容器通过N amespace和C gr o u ps，可有自己的r oot文件系统、网络配置、进程空间，甚至自己的用户I D空间，如此容器里的进程就像运行在宿主机上的另外一个单独的os内，从而实现与宿主机os里运行的其他进程隔离。
Doc k e r即是基于Linux内核的C gr o u ps、N amespace实现进程的封装和隔离。
虽然容器解决了应用程序运行时隔离问题，但要想实现应用从一台机器迁移到另外一台机器上还能正常运行，就必须保证另外一台机器上的os一致，而且应用程序依赖的各种环境也必须一致。Doc k e r镜像就解决了这个痛点。
即Doc k e r镜像不仅可打包应用程序本身，而且还可打包应用程序的所有依赖，甚至包含整个os。这样在本机上运行通过的应用程序，就可使用Doc k e r 镜像把应用程序文件、所有依赖的软件以及os都打包成一个镜像，可在任何一个安装了Doc k e r的地方运行。
Doc k e r镜像解决了DevOps中微服务运行的环境难以在本地环境、测试环境以及线上环境保持一致的难题。如此一来，开发就可以把在本地环境中运行测试通过的代码，以及依赖的软件和操作系统本身打包成一个镜像，然后自动
部署在测试环境中进行测试，测试通过后再自动发布到线上环境上去，整个开发、测试和发布的流程就打通了。
无论使用内部物理机还是公有云的机器部署服务，都可利用Doc k e r镜像
封装微服务运行环境，从而屏蔽机器内部物理机和公有云机器运行环境的差异，实现同等对待，降低运维复杂度。
3.微服务容器化
Doc k e r解决了服务运行环境迁移问题，因为在使用Doc k e r镜像时并非把
业务代码、依赖的软件环境以及os直接打包镜像，而是利用Doc k e r镜像的分
层机制，在每层编写Doc k e rfil e逐层打包镜像。
因为虽然不同微服务依赖的软件环境不同，但还是存在相同，因此打包
Doc k e r镜像时，可以分层设计、逐层复用，减少每层镜像文件大小。
4.案例
生产环境如何使用Doc k e r镜像。某Doc k e r镜像分为四层。
•基础环境层
定义操作系统运行的版本、时区、语言、yu m源、TER M等
•运行时环境层
定义了业务代码的运行时环境，比如J ava代码的运行时环境J D K的版本。 •Web容器层
定义了业务代码运行的容器的配置，比如Tomcat容器的JVM参数
•业务代码层
定义了实际的业务代码的版本，比如是V4业务还是b l ossom业务。
如此每层镜像都基于上层添加新内容，比如V4业务的Doc k e rfil e。
•F RO M代表上层镜像文件为：tomcat_f ee d:jdk8.0.40_tomcat7.0.81_g1_dn s，可见该层包含了J ava
运行时环境J D K和Web容器Tomcat及Tomcat版本和JVM参数等；
•ADD，即要在该层镜像添加的文件，主要包含业务的代码和配置R UN，该层镜像启动时需要执行的命令；
•WOR K D I R，该层镜像启动后的工作目录。如此便可通过Doc k e rfil e基于上层镜像完成该层镜像制作。
5.小结
正是因为Doc k e r可做到一处通过、到处运行，对业务价值极大，解决了以前应用程序在开发环境、测试环境及生产环境间移植难，提高了运维自动化水平，也为DevOps理念的流行和业务上云提供了基础。
当然Doc k e r也会带来新问题，如旧的针对物理机的运维模式就无法适应了，需要一种新的针对容器的运维模式。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。