阿里妹攻略：IaaS和PaaS有什么区别？如何利用云原生技术提升交付速度？云原生时代背景下，研发重心会有哪些变化？阿里云高级技术专家许晓斌借本文分享应用架构从IaaS云时代到PaaS云时代的演进方向，以及云原生技术与应用架构演进的关系。CloudNative已经进入PaaS为主云的阶段。阿里巴巴已经走过IaaS阶段，进入PaaS时代。去年“双11”期间，阿里巴巴已经实现了电商核心系统的全面上云，而这里的上云主要在IaaS层。所谓IaaS，主要是指计算、网络、存储的虚拟化。过了这个阶段，阿里巴巴就进入了云上PaaS阶段。在云PaaS阶段，需要用到更多的云产品，包括中间件、存储、缓存，甚至应用托管平台。IaaS阶段和PaaS阶段其实有很大的区别。在IaaS阶段，对于应用开发，关注的往往是基础设施和资源，一般来说就是虚拟机或者容器等，对应用架构几乎没有侵入性。但是在PaaS云阶段，当你使用云产品的时候，比如云Redis、云RDS、云OSS、云RabbitMQ等，会对应用架构有比较强的侵入。那么，这种入侵会对应用架构造成什么样的影响，是所有研发架构师需要思考的问题。云原生技术如果你去搜索云原生技术，你会看到GoogleCloud的定义，CNCF的定义，还有很多其他云厂商和开源软件的定义，而且这些定义各有各的说法。简单总结一下，可以分为几类如下图所示。纵向上分为应用架构、生命周期管理、流量管理、基础设施与依赖四个维度；横向分为微服务、12FactorApps、容器、BaaS、GitOps/IaC、ServiceMesh几个维度。今天大家要讲的是基于微服务架构的云原生，而不是基于单体应用架构或者简单的CS架构。Quarkus提出了12FactorApps，意思是如果你想在今天的Quarkus这些应用托管平台上运行应用，对应用有一定的要求，大约12个原则，比如配置和代码分离等。当然，遵循——up有很多扩展名。其中很多原则意味着只要你满足这些原则，应用托管平台就可以为你提供更多的能力，比如免费运维。容器的核心是通过一种标准的交互方式，使平台能够管理应用的生命周期，包括发布、扩展和自愈。BaaS-BackendasaService，可以尽可能利用已有的服务来构建应用。ServiceMesh的本质是管理流量。现在的应用都是在接收流量，在提供服务的时候流量需要出去。如何在这个过程中管理服务发现和流量路由规则，就需要ServiceMesh技术。最后要关注的是GitOps和IaC（基础架构即代码）。这些技术越来越受到业界的关注。虽然没有事实上的标准，但很多云计算公司都在不断努力。这意味着今天在使用基础设施时，您可以使用代码来声明这些基础设施的要求。总而言之，上述内容围绕着应用架构、生命周期管理、流量管理、基础设施与依赖四个维度展开。商家最关心的是发货速度对于商家来说，最关心的往往是发货速度。如果你跟业务总监或者CTO聊天，他们会问你，拥有这么多技术对业务有什么好处？他们可能会谈论成本优势和管理优势，但对于几乎所有企业而言，核心都是研发效率的提升。所以我们应该思考云原生技术如何帮助实现更快的交付。利用云原生技术提升服务交付速度大致可以分为三个步骤。Standardizetheprotocolsofplatforms/servicesandapplications标准化平台/服务与应用程序之间的协议。如果IaaS层使用云，协议就是机器，也就是虚拟机、容器等。对于业务应用来说，你看到的是一个操作系统，让应用可以使用运行上的各种资源系统。这样做的好处是你不需要关心物理机器和机器故障。独立于业务的功能进一步与平台分离。对于业务应用，你看到的不是操作系统，而是会提供更高层的协议，让平台帮助应用实现自动伸缩和自愈等，也可以帮助应用实现自动搬迁。当底层基础设施出现故障时，可以将应用程序从一台机器迁移到另一台机器，即生命周期管理。基于以上协议，可以降低平台的很多能力。比如，原本需要人工管理的东西，只需要通过代码声明就可以很好地实现。通过这些协议，业务应用程序可以管理相关的生命周期管理。到平台。除了以上两点升级应用架构外，第三步是通过升级适配应用架构，将相关能力迁移到云平台。进一步细化从IaaS上云阶段到云原生上云阶段的转变，会发现在原来的IaaS上云阶段，除了业务逻辑，还需要关心生命周期管理和流量管理的业务应用程序。自己搭建和配置中间件，比如在云环境下搭建Redis、Kafka等，意味着大量的时间花在了应用的依赖管理上，而云平台无法管理。在PaaS或者云原生云迁移的今天，我们要做的是尽可能的利用云平台提供的能力，更多的关注业务本身，把不具备的通用技术能力交出来与云有关的业务。管理。核心问题：如何将与业务无关的能力与平台解耦？如何定义平台与业务（应用）之间的协议？在PaaS云化阶段的今天，这样的协议应该是什么，需要重新定义。另外，如何基于这样的协议实现能力下沉，也是包括阿里云在内的很多云厂商都在做的事情。例如，阿里云基于RocketMQ开发了RocketMQService，并提供了基于一些容器协议的容器服务。当然，这只是开始，未来这部分内容会更加丰富和完善。示例1：ServiceMesh将服务发现和流量与业务分离。同时，应用架构也需要适配。这里我们以ServiceMesh为例。以前，应用程序内部的流量采用SDK的形式。那么在演进过程中，如何从业务SDK中分离出服务发现和流量，放到Sidecar中，然后交给云平台处理。这是应用架构演变的一个例子。服务注册&发现流量路由流量播放和发布流程流控示例2：轻量级容器将日志采集与业务分离在做日志采集之前，需要在每个虚拟机中启动一个日志采集进程，并将采集到的日志传输到日志采集平台，并通过可视化界面进行分析。在云原生时代的今天，更好的做法是让容器服务从stdout抓取日志，或者通过配置到特定的日志目录下获取日志数据。但是收集这件事需要搬到Sidecar上去升级Agent。因此，轻量级容器将日志采集与业务分离，也是一个架构演进的例子。资源隔离和自主升级示例3：业务提供探针使平台实现生命周期管理。应用架构的生命周期管理要求是原始应用启动后是健康的还是不健康的，这是应用运维或研发的需求。负责和关怀。在云原生时代，希望这个协议固定下来，通过业务提供的探针来判断应用是健康的还是不健康的。这就需要应用通过HTTP协议或者Shell提供健康信息，这样才能将应用生命周期管理落入平台。自动弹性、自动移动、自动重启（自愈）协议（Contract）=API+Configuration总的来说，协议就是API+配置。对于API，如果你使用缓存，你基本上会将开源协议视为API，而这样的协议通常比闭源协议更友好。对于RPC协议，开源的GRPC和DUBBO比私有的HSF要好。此外还有一些基础设施的协议，比如Terraform、Pulumi，其实都是在定义一种开源的配置语言。这些配置语言可以帮助声明所需的基础设施，如容器、磁盘、网络、存储等。虽然目前配置语言的种类很多，但未来最终会形成一两种语言，就像Java的SDK一样。以后使用云资源必然会出现一套SDK。此SDK必须基于一组配置编码语言。建。此外，GitOps等将发布流程和发布策略定义为一套语言，未来将成为应用程序与云之间的标准协议。Docker(&OCI)是标准的软件交付API。作为RPC协议，开源的GRPC/DUBBO优于私有的HSF。作为缓存协议，开源的Redis优于私有的Tair。微软的Dapr尝试基于sidecar架构将API标准化到HTTP/GRPC层，去掉SDK，支持多语言。Terraform和Pulumi等IaC产品通过配置语言声明基础设施。GitOps进一步使用代码来声明环境、发布过程和发布策略内容。研发重心的变化以前应用需要关心的东西太多了，比如各种SDK，各种运维事件，但是这些东西其实可以抽象成一个模型，用一种新的语言来定义，这是整个云行业都在关注的问题。之所以一直强调新语言和新协议，是因为定义了新语言或协议后，应用程序需要关心的就这些了。对于开发者来说，最关心的还是代码，所以如果能够用代码来描述应用对基础设施、运维、托管等方面的需求，对应用会非常友好。应用只需要能够连接到这个协议，就可以同时运行在私有云、公有云、阿里云上。综上所述，未来云上的资源会越来越丰富。在基础设施之上，云平台提供了更多的PaaS能力，就像操作系统提供了进程的能力一样，还有很多SDK。但是目前这些能力的使用还是非常低效和不规范的，使用过程也比较麻烦。今天我们以类似汇编的形式使用云，而云原生正在重新定义应用程序与云平台之间的契约，并围绕这个契约构建更高级的编程语言和工具。这是云原生时代背景下应用架构演进的一个非常重要的方向。【本文为专栏作者《阿里巴巴官方技术》原创稿件，转载请联系原作者】点此查看作者更多好文
