DevOps是一种强调开发团队，运维团队以及其他团队之间增强协作与沟通，以达到软件产品快速成熟以及安全可控的文化。通过自动化软件交付和变更的流程，来使得构建，测试，发布软件能够更加地快捷，频繁和可靠，它能用最小化的代价帮助企业应用开发进入高效的协作模式和快速的迭代进程。
企业在落地DevOps体系过程中，自动化持续交付流水线的建设是核心挑战，要想打造高效的自动化持续交付流水线，开发，测试到发布的各个环节缺一不可。
容器技术最重要一点是标准化。它的理念是“BUILD SHIP RUN”，也就是说构建出来的镜像包含了依赖第三方软件，操作系统以及代码构建后的制品，它可以在任意安装了相同版本容器服务的操作系统上执行。并具备相同的行为。
现代化应用架构，尤其是微服务应用架构（springboot,springcloud），都会采用分布式的应用架构。而分布式的应用架构则会带来复杂性，从而增加交付和运维的难度。因此容器技术(k8s)，包含编排，调度等能力，恰好能够很好的满足分布式应用交付的需求。容器技术因此被广泛采用。
如下是一个典型的DevOps流程会涵盖的内容。
微服务是一个新兴的术语，用来描述这样的系统：三层架构的业务层由许多小的服务组成，它们之间 使用语言无关的协议来通信。一般来说，这种语言无关的协议是基于HTTP的，通常是JSON REST，但是并不强制。协议层还是有 选择余地的。这种架构设计非常适用于持续交付方案，因为就像我们看到的那样，部署一些小而独立的服务比部署 一个单块系统来说要更加容易。下面这张图描述了一个微服务的部署看起来是什么样子的：
如何保持服务接口向上兼容
服务接口需要不断向前发展。这是很自然的，因为企业也需要向前发展，而在相当程度上它是服务接 口的反映。我们怎么才能实现呢？一个办法是使用有时被称为ToIerant Reader的模式。它的含义很简单：服务的 消费端应该忽略那些它无法识别的数据。这是一个非常适用于REST的办法。SOAP是个基于XML的定义服务的方法，它非常缜密。用SOAP的话，你一般是不会改变 一个现有接口的。接口被视为必须不变的契约。作为改变接口的替代方案，你可以定义一个新 的版本。现有消费者实现新的协议再重新部署，或者是服务提供方并行提供多种版本的接口。这种方法比较烦琐并且在服务提供端和消费端造成了讨厌的紧耦合。DevOps和持续交付并不强制应该怎么做事情，所以最有效率的方法更令人中意。在我们的例子里，可以说把变更的实现分摊到生产者和消费者里是代价最小的办法。不管怎样，生产 者需要变化，而消费者需要接受实现Tolerant Reader的一次性开销。通过SOAP和XML来实现也是可以的， 但是相比REST来说显得不那么自然。这也是为什么在拥抱DevOps和持续交付的企业里，REST的实现更加 流行的一个原因。如何实现Tolerant Reader模式在实践中因平台而异。对JsonRest来说，通常把JSON结构转换成同等的语 言结构就足够了。你的程序需要哪些部分，你就用哪些部分。所有的其他部分，不管是旧的还是新的，通 通忽略掉。这种办法的局限是，生产者不能移除消费者依赖的部分。增加新部分没有问题，因为它们将会 被忽略。这样又给生产者增加了负担，它必须记住哪些是消费者需要的。在企业的高墙内，这并不是什么大问题。生产者可以知道消费者最新的代码并在构建生产者的阶段进 行测试。而对于那些暴露在因特网上的服务，这种方法并不那么实用，这时会倾向于使用更为严格的SOAP方 式。
微服务和数据层 一种看待微服务的方式是每个微服务都是一个隐式的三层独立系统。不过我们通常不为每一个微服务 都实现所有的层。了解之后，我们便能发现每个微服务都可以实现自己的数据层。这样的优势在于增加了各服务之间的隔离。
以我的经验看，把企业的所有数据都放在一个单独的数据库或至少相同的数据库类型里 更加普遍。这种做法更常见，但不见得更好。
两种方式各有利弊。若是系统之间的隔离很明显，部署变更就会更简单。反之，把所有数据都存在同 一个数据库会让数据模型更为简单。
DevOps、架构和弹性
我们已经从DevOps的角度看到微服务架构有许多值得拥有的特质。DevOps的一个重要目标是更快地 为用户交付新特性。这是微服务提供的大量模块化所带来的结果。那些担心微服务会提供一个毫无瑕疵的完美解决方案从而让生活变得没意思的人可以解脱了。微服务 有它自己的挑战。我们想要能够尽快部署新代码，但是我们也想要可靠的软件。微服务在系统间有更多的集成点，比起单块系统来说更有可能失败。DevOps的自动化测试非常重要，这样我们部署的变更才能有更好的质量，才能令我们更加信赖。然 而，这并不是一个可以解决服务由于不明原因突然宕机的方案。由于在微服务模式中我们有更多的服务， 从统计学上来说服务宕机的概率更高。我们可以通过努力监控服务并在出状况时采取适当的行动来部分缓解这个问题。最好是自动化的方 式。在我们的客户数据库例子里，可以采用以下策略：使用两个应用服务器同时运行应用程序。应用程序通过JsonRest提供特定的监控接口。监控后台定时调用监控接口。如果服务器停止工作，负载均衡便会重新配置以将其从服务器池中移除。显然这是一个简单的例子，但它有助于描述我们面临的挑战，那就是设计由许多动态部分组成的弹性 系统以及它们如何影响架构决策。
为什么要针对不同的应用程序来提供监控接口？这是因为监控的目标是让我们全面了解当前系统的健 康状态。我们一般监控应用程序栈的许多方面。监控服务器的CPU没有过载，还有足够的磁盘和内存空间 可用，基础的应用服务器还在运行，等等。尽管通过这些，可能还不足以断定服务运行正常。例如，可能 由于某些原因，服务的数据库配置错误。一个针对服务的健康检查接口可以尝试连接数据库并在结果中返 回连接的状态。
