第1章　架构基础

从20 世纪90 年代的由贝尔实验室主导的Chroot Jail，到2000 年的FreeBSD Jails，再到2008 出现的Linux Container（LXC），容器技术经历了几代技术革新，其核心目标从未改变：如何将应用进程限制在独立的运行环境中，以满足封装和隔离的需求。量变引发质变是永恒的真理，2013 年，行业颠覆者Docker 的出现，彻底改变了容器技术乃至云计算行业的格局。Docker 引入了容器镜像的概念，将应用、应用的全部依赖、甚至操作系统打包存储和分发，彻底解决了软件交付的方式，简化了应用部署的复杂性。

谷歌借势推出了开源项目Kubernetes，它开源之初依托于Docker 技术，着力于集群管理、容器编排与服务发现。Kubernetes 将基础架构层面的计算、网络、存储，以及运行在技术架构之上的应用和服务都进行了抽象，通过统一的模型来管控云计算中涉及的所有要素，并将它们由点变线，理出一组独立的、可组合的控制流程。这些流程从对象创建开始持续将其推向所需状态，此过程无须应用程序开发者介入，从而减少了应用程序开发者在计算、网络和存储等基础平台上的工作量，使他们能够更加专注于自身服务的工作流和操作。

谷歌自Kubernetes 诞生之日起即开始容器云的标准化工作，其目标不仅仅是维护一个开源项目，而是联合众多厂家，形成强大的联盟，定制云计算标准以求行业统一。巧妙的业务抽象和强大的扩展性，使其在短短数年时间，已然成为云计算行业的事实标准。

Kubernetes 是基础平台，运行在其之上的应用需要做适度的改造和适配，才能充分利用其提供的故障转移、负载均衡、自动扩缩容等功能，云原生（Cloud-Native）就是运行在Kubernetes 平台之上的应用需要追求的目标。云原生是将应用程序构建为微服务，并将其运行在完全动态地利用云计算模型优势的容器编排平台上的方法。云原生主要关注的是如何创建和部署应用程序，而不是运行在哪里。不是只要将应用程序运行在容器编排的云平台（如Kubernetes、Mesos 等）上，它就是云原生程序，也并不意味着此应用程序将拥有云原生平台提供的各种优势。真正的云原生应用程序，无须重新配置就能够在现代化的动态环境（如公共云、私有云和混合云）中自由构建和可伸缩地运行，也只有这样才能真正受益于云原生平台。作为容器化应用程序的开发者，只有充分了解和利用云原生平台，才能设计、架构出真正的云原生应用程序。设计云原生应用程序可以从以下几个方面考虑：

● 松耦合的微服务：将单个应用程序开发为一组微服务，每个微服务都在各自的进程中运行，并使用轻量级协议（例如HTTP）进行通信。这些服务是围绕业务功能构建的，但又可以全自动地独立部署某个微服务。

● 无状态且可规模化部署：将其状态存储在数据库或其他外部实体中，无论是集群内还是跨集群的实例都可以访问并同时处理请求。它们不依赖于基础架构，从而允许应用程序以高度分布式的方式运行，并且仍保持其状态，而与基础架构的弹性无关。

● 故障的容忍性和弹性：应用程序跨多个物理数据中心部署，各个服务可以在各个云供应商之间自由启动、关闭和迁移。当硬件发生故障或者部分网络中断，以至单个服务的部分实例不能继续提供服务时，也不会影响整体服务的质量。

对企业而言，应用程序迁移成云原生架构，是需要经过长期过渡和增量改进的。长远来看，这是降低和规避运维风险的标准策略。