这篇文章是来拓展自己知识面的, 在我读高中那会 (08 年), 我身边就有沉迷电脑技术的同学, 那个时候我想着做一个自己的网站, 肯定是非常牛逼的事了. 从最开始接触的服务, 依次来排个序. 永硕 E 盘 -> 免费空间建站 (国外居多) -> 虚拟空间 -> 虚拟服务器 (VPS) -> 独立服务器. 看完这篇文章后, 我总算对这方面知识有了一个比较系统性的认识了. 一起来学习一下.

引子

文章开始之前, 我觉得还是有必要把这些专有名词先科普一下, 不要觉得很高大上, 简称而已.

  • IaaS - 基础设施即服务
  • PaaS - 平台即服务
  • CaaS - 容器即服务

本文介绍了 Web 托管服务进化的历史, 从专用服务器到虚拟化到 IaaS、PaaS 和最新的 CaaS; 说明了每种方式的优点和缺点. 着重阐述了构建 PaaS 应用的各个组件, 以及在选择 CaaS 提供商时应该考虑的问题. 最后从成本和功能性的角度论述了 PaaS 用户应该迁移到 CaaS 平台.

读完这篇博文, 你应该可以清楚的理解:

  • 这些名词到底指什么
  • 这为什么对你很重要
  • 对于你的使用场景,哪种方式最适合

当然没有一种方式能够适合所有的 Web 基础设施的场景, 你的特殊场景或许需要特殊的考虑.

从头开始——专用服务器

Web 托管的本质还是在一个数据中心里布满了服务器、交换机、路由器、存储阵列和其它网络组件. 我们所讨论的每一个选项不管它是 PaaS、IaaS 还是 CaaS, 它底层使用的基础设施都是相同的, 即在一个大屋子里的很多独立服务器. 他们只是上面增加了很多抽象层使得管理变得更简单, 和使用自动化的方式处理以前很慢或者需要手动步骤的任务.

专用服务器, 或者叫做 “裸机” 有它的优点和缺点.

优点

  • 性能——你在直接使用一个服务器, 没有任何抽象层例如虚拟化带来的性能开销.
  • 可靠性——没有抽象层和虚拟化, 出错的可能性会降低.
  • 资源利用率——使用专用服务器, 你的进程不需要跟其它的虚拟机或者进程竞争资源例如 CPU、内存和带宽.

缺点

  • 管理复杂性——你无法容易地克隆专用服务器来产生更多的实例, 专用服务器没有 AMI(译者注: Amazon Machine Image)或者镜像的概念. 想扩展你的基础设施到多个服务器上?我希望你用配置管理, 或者使用可信赖的老朋友 rsync.
  • 成本——使用专用服务器, 在大多数情况下你需要预先支付服务器的硬件价格, 然后再付租用场地的成本, 或者你从一个服务提供商那里租赁它们. 无论哪种方式, 你都没法在不使用时终止服务器的租赁来节省成本, 因此你需要更加谨慎的对待你的财务计划.
  • 你所有的进程和应用都运行在专用服务器上, 因此运行在相同的操作系统上. 为了可扩展性的目的, 你往往希望服务器只运行单一的进程, 例如 Web 服务或者数据库服务. 在一个服务器上运行所有的应用使得操作系统的调优变得更困难.

使事情变得更容易——虚拟化

尽管专用服务器有很多优点, 但是它的缺点在大多数情况下会远远超过其优点. 公司为了能够迅速进入市场赢得竞争, 对于部署的速度提出了更高的要求, 虚拟化就很自然的成为了数据中心进化中的下一个步骤.

什么是虚拟化

简而言之, 虚拟化就是将物理服务器分成更小的虚拟机, 这些虚拟机只能访问物理机的部分资源. 例如你有一个 8CPU 核以及 16GB 内存的物理服务器, 则可以将它分成 8 个虚拟机, 每个虚拟机有 1 个 CPU 和 2GB 内存. 你或许已经听说过一些虚拟化技术如 Xen, KVM, VMware 和 Hyper-V, 其实很有更多.

优点

  • 你可以在需要更多虚拟机实例或者想要虚拟机共享时进行虚拟机的克隆.
  • 你可以备份虚拟机镜像作为安全保护或者灾备.

缺点

  • 使用虚拟化意味着额外的性能开销, 可能造成性能下降.
  • 虚拟机镜像在不同的服务提供商和虚拟化技术之间基本上是不可移植的.
  • 管理虚拟机依然是手工步骤, 需要管理的时间和专业知识.

进化——虚拟化变成 IaaS

你知道 51% 的人认为 “云” 会被天气影响吗?你知道当人们谈论 “云” 时他们实际上是在讨论基础设施即服务 (IaaS) 吗?

什么是基础设施即服务 (IaaS)

  • 通过 API 来管理硬件的虚拟化.
  • 通过编程接口访问计算、存储和网络资源和配置.
  • 当你需要是申请一个新的虚拟机, 当你完成后终止虚拟机, 你只需要为你使用的资源付费.
  • 将数据中心资源视为公共设施.

亚马逊在 2006 年发布了其 Amazon Web Services(AWS)和 EC2 产品,成为了这个领域的先驱。

为什么这个进化如此重要

在过去当你需要上线一个在线业务时, 你不得不进行复杂的计划来保证你在数据中心内有足够的机架空间、足够的服务器和存储来处理业务的增长, 足够的网络带宽来处理所有的用户流量. 这种计划并不容易, 尤其是对早期的业务来讲, 你无法预测业务的未来和增长轨迹.

  1. 它给了开发者超能量:
    • 构思一个想法立即上线.
    • 如果成功了, 可以容易的扩展规模.
    • 如果失败了, 关闭虚拟机以节约成本.
  2. 它使得数据中心自动化变得更强大:
    • 全自动基础设施管理成为可能, 出现了 “基础设施即代码” 的概念.
    • 弹性伸缩在过去是不可能实现的, 但是现在 web 基础设施可以当业务变化时自动的扩展或者收缩.
    • 在服务器的自动化管理之后, 数据中心的自动化也扩展到了存储、网络以及其它大量的需要专业知识的系统, 在代码和 API 能够处理这些自动化之后, 这给全球的开发者社区带来了新的机遇.

进一步演化——平台即服务 (PaaS)

平台即服务 (PaaS) 使得开发人员可以很容易的部署和管理应用而隐藏掉所有的实现细节例如服务器、负载均衡器、DNS 等等. 他们或多或少的去除了对运维团队的需求, 而是让开发人员去关注应用部署. 有很多 PaaS 提供商, 其中一个最流行的是 Heroku. 关于 Heroku 的一个有趣的事情是 Heroku 完全是运行在 AWS 之上并依赖 AWS 的. 如果你不愿意你的应用运行在美国东部或者欧洲西部的 AWS 上的话, 这或许是一个问题. 没有 IaaS, 像 Heroku 这样的平台可能就不会存在了. PaaS 提供商利用 IaaS 作为一个非常重要的组成部分来交付它们的服务. 在减少从想法到部署的时间、自动化流程以及减少特殊的系统知识需求的趋势中, PaaS 是合理的下一步, 就像是从专用服务器到 IaaS 一样.

构建 PaaS 是困难的

能够通过抽象而避免处理服务器相关的问题是不容易的, 需要引入很多东西才能做到.

在 PaaS 的概念之下有几个主要的模块:

  • 编译系统——把你的代码编译成可以运行的应用, 并且把它存储到某个地方作为后续使用.
  • 应用管理数据库——管理 Git 版本、build 版本和应用元数据.
  • 集群调度器——将一组服务器作为一台大的服务器来管理, 在服务器资源池的某个服务器上运行你的程序, 并检查和替换失效的作业.
  • 负载均衡——允许从 Internet 和内部程序来的业务负载被正确的路由到合适的位置.
  • DNS——在你产生和修改应用时自动配置 DNS 条目.
  • 或许是最重要的——某个形式的容器化例如  freebsd jails、solaris zones、或者 linux containers, 容器化使得某个的应用不会进入和影响到其它的应用.

第一个和最后一个点是 Docker 迅速发展的非常重要的原因. Linux 容器技术已经存在了一段时间了, 但是只有某些大的公司或者 PaaS 提供商自动化了容器的使用, Docker 使 Linux 容器的使用变得非常简单, 也提供了标准化的镜像格式, 它成为了 PaaS 中重要的组成部分.

这非常强大, 因为很多公司在处理爆发式的用户增长, 来自于移动、社交和 IoT 的新的业务模式, 以及期望从传统的长的版本发布周期转变到持续交付. 他们利用基于软件的架构或者微服务. 他们需要能够自动部署和测试新的代码, 并根据业务的变化弹性伸缩. 但问题是他们没有足够的资源和经验来交付到他们的开发团队, 所以他们不得不将其外包给 PaaS 提供商. 不幸的是, 当你这么做的时候, 你就放弃了对于这个黑盒子的很多控制, 而是花很多钱并使得自己完全依赖于它. 另外一个选项是, 很多公司反复的重新发明轮子或者使用那些难于维护的、运行缓慢的和易于出错的工具.

最好的情形是在自己的数据中心或者 Cloud 帐号中运行一个 PaaS 平台, 你可以全权控制, 你的团队可以直接参与应用的部署, 因此可以形成一种真正的 DevOps 文化. Docker 及其标准化的生态系统是这种愿景成为现实的重要一步.

最后——容器托管平台 (CaaS)

什么是容器托管平台, 或者叫容器即服务呢?这就是我在上面的章节中提到的另外一种构建在 Docker 基础上的 Web 托管方式. 它是你用容器来部署复杂的多层次的应用所需要的自动化的编译系统, 集群调度器, 负载均衡, DNS 自动化以及服务发现. 这是 PaaS 的另外一部分内容, 但是你不是用一个复杂的编译系统来编译你的应用, 而是用 Docker 镜像. 镜像可以非常容易的进行编译和本地测试, 因此你在部署应用之前就确认应用可以正常工作. 现在 PaaS 用户也可以得到相同的体验, 但是不需要拥有自己的硬件或者云帐号的前提下节约大量的成本. 他们不再受限于其服务提供商所支持的环境, 可以通过将应用打包成 Docker 镜像的方式在任何地方运行.

在这个过程中, 利用诸如 ContainerShip Cloud, 你可以在任何地方, 在任何云平台上甚至是裸机上用相同的方式运行你的应用. 你不再被卡在构建复杂的应用来解决非常困难的问题, 或者卡在使用某个提供商的特殊的自动化部署工具上.

  • 但是选择一个正确的 Docker 容器托管平台并不是一件容易的事情, 有很多的问题需要你去思考和注意.
  • 有大量的选项, 因此选择其中一个进行研究就变得困难. 好消息是如果你的应用已经容器化, 你就可以轻松的测试其中的每一个.
  • 你正在使用的服务提供商例如 Triton 或者 ECS 的某个解决方案或许使得你无法脱离这个提供商, 这也使得 Docker 的最令人兴奋的可移植性变得不那么重要了.
  • 许多 CaaS 方案在他们自己的硬件上运行所有的管理系统, 你自己的服务器上只是运行某个代理程序来连接他们的 API, 因此如果他们的系统宕机后你的集群将无法工作.
  • 允许你在防火墙后运行整个系统的方案是非常复杂的, 需要一个团队去管理和升级.
  • 能够容易的在防火墙后运行整个系统的方案会使得高可用成为低优先级的事情.
  • 当你选择了一个 CaaS 提供商时, 你就可以摆脱了你的服务托管提供商的锁定, 但是你将陷入到 CaaS 提供商的锁定. 你无法不使用他们的 SaaS 管理接口而在你自己的硬件上运行整个系统包括管理系统, API 和 UI. 你一旦决定付钱, 你最好可以一直付钱.

总结

终于看完了, 真的是又臭又长啊. 回顾一下这篇文章, 总体来说是经历了这样一个过程:

  1. 专有服务器
  2. 虚拟化技术
  3. 基础设施即服务 (IaaS)
  4. 平台即服务 (PaaS)
  5. 容器即服务 (CaaS)

总结一下, 我觉得开发人员还是有必要了解一下关于产品部署相关的技术发展. 然后根据自己的业务来选择合适的服务提供商.