云计算中的IAAS/PAAS/SAAS
云计算的概念提出者是IBM，但是IBM并没有很好的落地的产品，对于在线图书商店AWS，却有可以落地的场景，买了大量服务器，但是在图书销售淡季，造成了资源的浪费，因此逐渐有了目前云计算的领导者AWS，对于云计算相关工作者来说，我们
对AWS最深的印象时公有云NO.1，尝尝会忽略人家盈利最多的在线商城。
云计算刚提出的时候是提出了三个层次，即IAAS、PAAS、SAAS，这三个层次我们可以认为是云计算能力不同范围的概括，如下图所示：
但实际上这代表了云计算发展的三个阶段，更直白的说就是PAAS的发展需要在IAAS发展成熟的基础上，SAAS的发展需要在PAAS发展成熟的基础上，不可能并行发展，也不可能跳跃发展。当然对于细分领域的PAAS平台肯定就没有这个限制了，我这里主要还是指的通用的云平台，以公有云厂商的能力为准。
IAAS的发展阶段，主要包括这样的内容
1.1.各大厂商争相模仿AWS、自研底层虚拟化平台，比提供兼容AWS的接口，此时都以AWS作为需求开发的标准
1.2.底层虚拟化软件除了商业版的Vmware，出现了越来越多的开源的虚拟化软件，例如XEN、KVM、libvirt等，定位与私有云平台厂商的产品开始基于这些虚拟化软件做二次开发
1.3.出现了越来越多的不同厂家的云管理平台，以及开源的云平台，OpenStack/CloudStack/Zstack等，随后各个厂家开始基于OpenStack作为标准进行自家云平台的二次开发或深度定制，此时越来越多的云厂家基于利旧（充分发挥老旧服务器的作用）、平台不绑定、资源异构（计算资源异构、存储资源异构、网络资源异构）的标准进行产品定位和宣传
1.4IAAS尝试提出为了解决资源利用率与降低成本，自动化运维进行市场宣传，传统厂商开始逐渐接受云的能力，并逐渐将自己业务迁移到公有云平台或者私有云平台
1.6.此时，市场对PAAS的认可度不高，我觉得市场度认可不够的原因有两个，一个是技术成熟度，有基于虚拟机做的PAAS，但是不是很好用，另一方面，云厂商对这方面的市场宣传不多，大家还都是主要发力于底层IAAS建设
PAAS发展的阶段，包含这样的内容
2.1 以虚拟机为代表的PAAS平台，自动编排虚拟机+应用+服务，这个其实我们在OpenStack的发展过程中就能看到，从只包含nova、neutron、cinder组件，到现在各种基于虚拟机的编排heat、sahara等，开始基于虚拟机的编排，来做服务的自动化创建，但是这种PAAS 很笨重，侧重于服务的自动化创建，距离应用的自动化管理有不少差距
2.2以容器为代表的PAAS平台，这里的开源项目有docker、CloudFoundry+warden、Kubernetes，我做的第一个PAAS项目其实是基于CLoudFoundry+warden，这是有Privotal公司开源的业界第一个容器的PAAS平台，在当时来说还是非常先进的，但是受限于CloudFoundry中并没有像docker中镜像的概念来持久化打包应用，他里面是有一个叫buildpack的东西，需要对不同的开发语言版本、运行环境制作不同的buildpack，还是很麻烦的，跨平台迁移也比较费劲。现在最火的就是Kubernetes+docker和围绕他们的技术栈
2.3.PAAS的定位也越来越清晰，以应用为中心，为应用的自动化运维提供支撑，例如应用需要的服务（数据库、缓存、消息队列）、运维管理（监控告警、弹性伸缩）等
2.4.平台+生态，更多的服务能够集成到生态，传统厂商也希望基于云平台厂商的能力，来拿到更多的客户，逐渐兴起了平台+生态的概念，希望大的平台厂商能够给传统厂商带来客户
2.5 随着iaas的成熟，这些年在不同的行业出现了不同的paas平台，不同的细分行业的技术平台积累，也都开始叫做XX PAAS云平台
SAAS的发展阶段，SAAS更多是属于应用的范围，需要应用来支持多租户，从而可以实现一个产品来支持多个客户，通常多租户有两种方案，一种是多实例部署，即不同的客户，我给你部署一个实例，还有一种方案是基于应用改造，即应用通过分库分表，在自己的业务层进行多租户的区分。这里云平台厂商目前提供的能力有限
云原生
好多概念我们可以发现都是来自于互联网，我们先说一下传统应用与互联网应用的区别，
对于传统应用通常具有以下特征,需求比较固定，是个项目，完成以后就是运维，用户访问量可以预测，较为固定，用户访问的并发量比较低，非在线业务，允许一定时间的业务停顿，此时的开发方式通常是瀑布式，当软件开发完成时，可能就交给运维部门了，然后就是会有些打补丁的工作，项目组开发人员也可能解散了。
但是对于互联网应用，需求是持续发展的，是一个产品，持续发展，版本特性不断累加和变化，用户访问量难以预测，用户访问的并发量是万级、十万、百万，属于在线业务，业务不能停顿，互联网应用需要24小时保持稳定可靠。对于该类应用的开发人员通常会一直围绕这个产品进行开发，需要一直对这个产品的功能、稳定性进行负责并持续优化。这里对技术就提出了更高的要求，你需要支持敏捷开发、弹性伸缩，强大的监控能力，支持海量并发，灰度发布等等。
传统应用的典型架构
上图是一个常见的包含三层应用的架构，通常对于传统应用都会包含多个模块，每个模块都实现了一些功能，模块之间是紧耦合在一起的，通过对象的调用(函数级API的调用)，功能调用紧密的结合在一起。这种高耦合性最典型的表现就是，哪怕开发者改了一行代码，整个应用都要重新编译部署；应用有可能是有状态的，例如通常会在程序内存中保存一些业务数据或者在应用使用的本地存储持久化一些信息，还有例如spring中的有状态bean和无状态bean（有状态bena保存了会话信息）由于这种高耦合性以及有状态，对于提供应用服务的挑战在于，要保证应用服务的持续运行。在生产环境中，一般都是要实施HA的解决方案的，比如App的集群，数据库的HA等等，同时为了保证服务宕机的时候，要能够快速恢复服务。因此，数据库会进行定期的备份。
我们在开发传统应用时，通常会有这样的场景，在开发环境中可以运行的应用，在生产环境中会出现很多问题，因为基本上开发者是没有精力去维护一个复杂的高可用的和生产环境一样的开发环境。而对于运维人员，他们的任务是什么，不管是物理机还是虚机，都要全力保证物理机和虚机的运行。一旦物理机或虚机发生故障，对服务的影响也是灾难性的，往往需要一个手动恢复服务的过程。在开发人员和运维人员之间有一个gap。开发人员和运维人员不太喜欢进行产品的功能变更，带来的工作量很大。这里总结一下传统应用架构的问题，我觉得可以归为三类：故障运维、应用伸缩、需求变更
云原生应用的典型架构
你可能不太懂云原生，但是我们在做架构设计的时候，可能已经潜意识的去这样做了，因为现在这个DevOps、微服务、容器太火了，不管IT的什么行业，我觉得都应该听过这几个名词。我们看到图中，角色并没有太大变化，仍然是有web，app，和db。这里要说明的一点，传统应用也许是部署在物理服务器或者虚拟化平台上，但是云原生应用一定是部署在云平台上的主要的变化包括：
第一，应用被拆分成了几个小的应用，紧耦合变为松耦合；由模块变成线程级的微服务；
第二，应用由有状态变为无状态的。大家也许会问，在业务逻辑中总是会有状态产生的，应该怎么办呢？这里重要的是对状态的一个管理，就是把状态保存在有状态服务中去。这些有状态服务包括缓存，比如memcache，数据库，比如mysql，mongodb，文件系统，消息对了等等。这些有状态服务以资源的形式提供给应用。这些资源在应用部署的时候，是以显性的依赖来声明的
第三，通过container技术，打包/隔离运行环境；在虚机和应用之间增加一层来隔离，在不同执行环境之间提供最大化的可移植性
对于传统应用，我们可以发现云原生应用的几个特点：微服务、无状态、弹性伸缩、DevOps
找到一张阿里云给云原生定义的图，如下，可以看出，云原生架构 可以理解为在进行软件架构设计时，就基于云平台的能力去设计，例如DevOps、微服务、容器，能够充分发挥云平态对应用的运维管理能力，即非业务功能交给云平台去处理。
云原生定义的几个阶段
云原生十二要素
这里有一个云原生的十二要素，这个其实是最开始对云原生定义时，使用，虽然云原生的定义已经变化多次，但是这个十二要素可以作为我们进行软件设计的参考
1 | 1. 基准代码：一份基准代码，多份部署。基准代码和应用之间总是保持一一对应的关系。所有部署的基准代码相同，但每份部署可以使用其不同的版本。 |