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