亚马逊AWS官方博客
亚马逊云科技云原生架构演进
经过十几年的发展，云计算已经得到广泛认可成为主流，企业基础设施逐渐从IDC迁移上云，甚至采用云优先战略，优先在云上部署应用。在这种趋势下诞生了云原生的概念，英文是Cloud Native。从字面意思来看，这种直接诞生在云上的应用就是云原生应用。但云原生的意义远不止这些，它是云计算时代一种构建和运行应用程序的方式，充分利用和发挥云平台的弹性和自动化优势，结合容器、微服务、无服务器 (Serverless) 等技术来构建现代化应用。云原生更是方向和引导，引导企业更加深入的认识和使用云计算，使应用不仅生在云上，更是以一种适应云计算文化的方式诞生。
在使用Amazon Web Services的过程中，我们经历了IDC迁移上云助力业务全球扩展；从最初的在云上以虚拟机部署单体应用，到借助ECS、EKS进行微服务化、容器化改造，实现云资源的弹性伸缩，全球容器集群的统一管理；以及采用无服务器架构 (Serverless) 来解放运维工作的过程。这也是业务云原生进化的典型过程。
1. 迁移上云助力全球扩展
在云计算兴起之前，对于大多数企业而言，硬件的自行采购和 IDC 机房租用是主流的 IT 基础设施构建方式。而机房维护是一件非常复杂的工作，而且面临众多的问题：
(1) 设备采购、机房网络规划、系统以及软件的安装、虚拟化等工作都需要非常专业的人员来管理。
(2) 资源利用率问题。通常各个业务部门会在每季度进行项目预算，之后IT部门统一进行硬件采购，而各个业务部门往往是按照峰值甚至是未来的峰值过度申请资源。使得资源在日常的利用率非常低。
(3) 在一些业务出现迅速发展的情况下，采购的设备很快就用完了，然而资源的整个重新审批、采购、上架，以及配置过程往往需要一个月甚至更长的时间，严重制约业务增长。
(4) 机房的可用性很难保障。且不说异地多中心的实现难度，单是机房断电切换UPS的过程也会造成闪断，机器重启等问题。
(5) 在IDC部署的应用架构往往比较落后，也很难满足快速增长的业务需求。
因此，企业在某个事件或者时间点开始把业务迁移到云上，而不是在全球招聘IDC团队。
迁移上云之后，资源拥有了快速扩容的能力，服务器的采购周期不再阻碍业务的增长。并且可以随时在全球的数据中心中启动资源，助力业务的全球扩张。企业也不再需要进行过多的前期投资，而是按需采购服务器。
并且在云上有完整的安全、网络、用户权限等基础设施规划。最重要的，实现这一切不需要企业自己的全球IDC团队，背后有云厂商更加专业的团队保证基础设施的安全稳定。
2.ECS EKS 容器化弹性扩缩、快速部署
迁移上云解决了企业最棘手的问题，然而上云之后只是云原生的开始。
首先，虽然业务已经上云，但是业务形态仍然是传统的单体应用，发布周期长，而且代码改动造成的影响也比较大。因此，需要对应用进行微服务化改造来获得更高的敏捷性。
其次，把云上的计算资源简单地看成是固定的虚拟机去管理，在服务器的整个生命周期中，会经历无数次的发布、变更和调试。同一集群的服务器之间的配置变得越来越不一致，集群各个服务器出现的问题也不一样。这种配置不一致导致我们调试bug，或者想要对集群进行扩容的时候效率非常低。运维成本也会随着机器的增加而增加。
第三，虽然迁移上云有利于降低企业采购基础设施，以及建设和运维的成本，但在IDC中面临的资源利用率的问题在上云之后并没有明显改善，计算资源依然是要按业务峰值再加一定的缓冲来申请，甚至为保证业务稳定性要预留较大的资源缓冲。再加上服务器申请交付流程麻烦（审批，环境初始化，部署流程配置，监控配置等），因此业务申请机器之后为了防止后续再重新申请，不会轻易回收已经申请到的服务器，从而在资源使用上仍然存在极大的浪费。
Flexera报告指出，企业公有云支出成本的浪费是最主要的问题，并随着支出成本的上升而变得更加可观。受访企业自我评估他们的企业云支出有30%的浪费，如下图所示。但是由于很多企业倾向于低估浪费的程度而使得结果偏低。在与客户合作来识别浪费时，Flexera发现，平均而言，实际浪费为35％甚至更高。
要解决这些问题，我们需要对业务进行云原生架构改造，使其更加适应云计算环境。
首先，为了提高业务的灵活性以及快速部署的能力，需要对业务进行微服务化改造。相应的基础设施架构也需要从虚拟机部署改为容器化部署。
AWS的容器管理平台有Amazon ECS (Elastic Compute Service) 和Amazon EKS (Elastic Kubernetes Service) 两种选择。
Amazon ECS 是AWS自主研发的容器管理平台，提供了简明的资源管理控制台。不需要维护集群的升级，ECS后台会自动升级，我们直接应用新特性即可。同时ECS与AWS其他服务也有着非常完美的集成，不需要做额外的开发即可开始使用。它是非常简单便利的容器管理平台。
Amazon EKS是托管的Kubernetes容器管理平台，Kubernetes早已是大趋势，拥有庞大的开源社区的支持、强大的工具和插件生态系统，以及宏大的开发路线图。并且，由于其统一的接口，可以实现多云多Region众多集群的统一管理。
用户可以根据需求选择一种平台进行容器化改造。
其次，要解决服务器配置管理混乱的问题，建议采用不可变基础设施架构。
在这种模式中，任何基础设施的实例（包括服务器、容器等）一旦创建之后便成为一种只读状态，禁止对任何运行的服务器做手动修改。如果需要修改或升级某些实例，唯一的方式就是创建新的实例替换原有实例。通过只读和替换这两个特性，可以保证集群配置的一致性，并且永远保持在最初的良好状态。这种架构模式带来的好处是，无论几十台还是几百台服务器，都可以像一台服务器一样去管理。随着服务器数量的增加，运维成本没有明显增加。
进一步可以通过自动化弹性扩缩容来提高资源的利用率。使业务根据每天请求的高低峰进行服务器资源的自动调整。这才是云计算的最本质的能力。
容器环境的弹性扩缩容分为两个层面，一个是容器层面，一个是node层面。两个层面的扩缩容逻辑是，业务负载变化触发容器层面的扩缩容，容器的扩缩容使Node集群的剩余可分配资源量变化进而触发Node节点的扩缩容。容器层面的自动扩缩容比较好实现，ECS中使用 Application Autoscaling，EKS中使用HPA来实现。而Node层面的扩缩容需要解决三个问题：
- 扩容时服务器环境初始化，可以用初始化脚本解决。
- 缩容时容器的优雅调度，可以使用 ASG lifecycle hook调用 Lambda 解决。
- 最后最关键的是扩缩容时机，一个建议的方案是计算集群中Node节点的剩余的可分配资源情况，每分钟触发Lambda进行计算并推送到CloudWatch，并把这个指标作为Node节点的扩缩容指标，这样就可以预留出特定数量的Node节点资源，在Pod扩容时无须等待Node就绪。
或者选择开源的Cluster Autoscaler来管理Node层面的扩缩容。
最后，Spot实例是AWS的剩余计算资源，相比按需实例，Spot实例提供了最低一折的折扣。但是相应的，当按需资源需求增加的时候竞价实例可能随时会被回收。有了自动化作为基础，我们就可以把Spot实例加入到集群中，在Spot实例被回收之前把容器平滑地调度到其他实例中。从而在利用竞价实例的低价优势的同时，不会因为其不稳定性而对业务造成影响。
通过容器化改造，集群可以根据每天业务高低峰自动调整资源配置，高效利用资源，并且通过Spot实例进一步节约成本，同时结合不可变基础设施架构大幅度减少运维成本。在推广活动之前也可以很方便地一键化对资源进行扩容，活动之后方便地进行缩容。新业务上线不仅不需要提前申请过多的资源，而且申请下来的冗余资源也可以按需使用。业务的微服务化使得业务各个模块独立部署，独立扩缩容，快速上线。
进一步通过使用EKS，结合聚云立方以及KubeStar平台，使众多的Kubernetes容器集群管理更加便利。服务治理、CI/CD、可观测性等方面都可以通过统一的平台来管理，而且也可以很直观地展示容器层面的费用情况。
3. 无服务器解放运维
容器化以及自动化的架构演进，使得业务的发展更加敏捷可靠。然而这一切复杂的工作都是因为有服务器。解决的都是如果没有服务器就不会存在的问题。
无服务器 (Serverless) 架构替我们屏蔽了服务器的管理，当不再需要维护服务器，才真正开始回归问题本质，专注解决业务本身的问题。Serverless 可使开发人员专注构建和运行应用，而不需要管理服务器。不过，实际上 Serverless 方案中仍然有服务器的，只是是由云厂商负责管理云基础设施架构和应用扩展。
AWS提供了两种Serverless计算服务，一种是EKS和ECS平台的Fargate容器引擎，另一种是Lambda平台。
Fargate是一种适用于容器的无服务器计算引擎。通过使用Fargate， 不需要再预置或者管理服务器，只需为运行的容器付费即可，而且可以非常方便地实现容器的自动扩缩容，不需要关心计算节点的扩缩容。而且在EKS和ECS平台中使用的CI/CD流程以及监控流程都可以继续在Fargate平台中使用。
而Lambda相比Fargate提供了更深一层的托管，它将容器环境也托管起来（当然现在也支持了容器在Lambda平台运行）。客户只需构建代码即可，应用会自动部署到Lambda管理的容器中，这些容器在被调用时会自动按需启动。而且在CI/CD流程方面有不同于容器环境的实现方式。我们通常所说的Serverless 应用指的就是基于Lambda平台构建的应用。
Serverless 应用实现了真正的资源按需配置，自动弹性伸缩，实现更快速的部署流水线，以及更高的系统安全性。而且可以使用平台支持的任意语言，不需要限制开发人员使用特定的编程语言。与传统服务端应用常驻内存的特点不同，Serverless 应用不需要长期运行，而是通过事件触发，执行之后即可释放资源。
因此，在讨论 Serverless 应用之前，不得不提一下事件驱动模型。事件驱动的体系结构使用事件在解耦的服务之间进行触发和通信。事件是状态的更新，例如放置在电子商务网站上的购物车中的项目，或者S3文件上传事件等。事件驱动的体系结构具有三个关键组件：事件生产者、事件路由器和事件消费者。 生产者服务和消费者服务是分离的，这使得它们可以独立扩展，更新和部署。
几种常见的事件驱动场景有：
(1) AWS平台的事件，实例重启、S3上传文件、CloudTrail记录的事件等，都可以作为事件源，触发Lambda或者System Manager Automation对其进行自动处理。前面的容器集群的弹性伸缩配置也是事件驱动的一种情况。
(2) 业务逻辑，比如用户的登录、充值、提现等操作，都可以作为事件源通过触发Lambda进行处理，来实现完整的业务逻辑。
(3) 定时任务，不需要长期运行在服务器中，定时触发执行即可。
在AWS中使用SAM (Serverless Application Model) 来管理无服务器应用，Amazon SAM无服务器应用程序模型是Lambda函数、事件源和共同执行任务的其他资源的组合。需要注意的是，无服务器应用程序不仅仅是Lambda，还包括其他资源，如API、数据库和SQS、SNS、事件源映射关系等。
Amazon SAM包含两个部分：
(1) AWS SAM模板规范，定义构成无服务器应用的相关资源，是Amazon CloudFormation 模板的扩展。
(2) 命令行，可以结合Amazon CodePipline等CI/CD工具来部署CI/CD流水线，并且在本地开发环境做测试和debug。
另外，还可以把无服务器应用程序部署到Serverless Application Repository（Amazon SAR），即无服务器应用仓库。它类似于容器镜像仓库，我们可以把无服务器应用发布到公共或者私有的仓库中。通过应用仓库可以方便地进行无服务器应用程序的分发，使开发人员和企业轻松地在云中快速查找、部署和发布无服务器应用程序。
对于无服务器应用的监控，我们使用X-Ray服务。X-Ray可以跟踪通过整个应用程序的用户请求，进而准确发现应用程序造成性能问题的位置和原因。最后，还可以非常方便地使用CloudWatch Logs来收集业务日志。
下面用简单的例子来说明如何实现Serverless的CI/CD流程。如下图所示，当风控模块接收到前端请求的时候，把消息统一推送到Event Bridge，然后通过不同的行为规则触发相应的Lambda进行处理，处理之后把结果写到Serverless的数据库中。每个方框里的相关资源定义为一个Serverless应用一起部署。
我们来看一下这个Serverless应用是如何部署的。
左上角是代码目录结构，cmd文件夹里边是业务代码，最终会在构建之后被发布到Lambda中，同级目录下的两个配置文件是发布过程用到的配置文件。其中template.yml是模板文件，定义了Serverless应用所有的相关资源。samconfig.toml 是 SAM 命令用到的配置文件。
有了配置文件和模板文件，就可以通过 sam build， sam deploy 来完成部署，两个命令会自动去找到模板文件和配置文件，并完成如下操作：
(1) 构建代码，并且把构建好的代码上传到S3桶；
(2) 根据模板定义创建Lambda、SQS等相关资源，同时把代码部署到 Lambda。
Serverless的应用架构给我们带来了更加快速方便的应用部署方式，业务无论大小都不需要提前预估容量，也无须提前申请服务器。而且，因为资源模板和业务代码统一管理，开发人员可以自助部署以及维护服务，不需要运维参与。通过把基础设施的配置和变更自动化和流水线化，这天然就是基础设施即代码的管理方式。当然容器环境也可以使用Cloudformation模板来做基础设施即代码管理，但是远不如Serverless应用这么自然和简单。
上面通过一个简单的例子对 Serverless 做了介绍，在实际场景中可以结合所有计算、集成和数据存储三个层级的无服务器服务来构建丰富的适用于各种场景的无服务器应用程序。
例如，通过Lambda、Amazon API Gateway来实现后端逻辑以验证和处理 API 请求，使用Amazon DynamoDB 作为数据库来实现通用的事件驱动的Web应用程序，从而可自动扩展和收缩，并跨多个数据中心中运行，而无须在可扩展性、备份或多数据中心冗余方面执行任何管理工作。
或者，使用 AWS Lambda 构建无服务器后端，以处理 Web、移动、物联网 (IoT) 和第 3 方 API 请求。
无服务器应用架构适用于丰富的应用场景，给业务带来了更高的敏捷性，从而能够更快地创新和响应变化。
总而言之，在云计算时代，我们应该转变传统应用部署的思维方式，拥抱云原生，最大化利用云计算提供的弹性以及自动化能力来构建现代化应用。