本文为 2021 MAXP 系列公开课第三讲完整版直播回顾，由来自亚马逊云科技的资深开发者布道师黄帅老师主讲，为大家介绍云原生应用开发相关知识以及一个航班查询预订应用的快速开发案例分享。
直播视频回顾：https://www.bilibili.com/vide...
关于2021 MAXP
2021 MAXP 高性能云计算创新大赛（2021 MAXP）由中国计算机学会高性能计算专业委员会和中国信息通信研究院指导，ACM中国高性能计算专家委员会（ACMSIGHPC）和云计算开源产业联盟联合主办，亚马逊云科技和腾讯云支持，阿里云、华为云、UCloud、天翼云等厂商参与。大赛以高性能云计算为主题，旨在进一步推动国内高性能计算的发展，并为参赛者提供了高达 40 万元的奖金池，还会提供实习机会和权威荣誉证书。
直播回顾
黄帅，来自亚马逊云科技的开发者布道师，曾从事软件研发及相关的咨询自行领域，有超过 10 年的架构设计经验，在运维实践、云原生可靠性治理以及可观测性构造等有深入的研究和丰富的案例经验。本期由黄帅老师内容为大家介绍关于云原生应用的有关知识：
- 什么是云原生应用
- 云原生应用的交付形态
- 云原生应用快速开发的核心期望
- 云原生应用快速开发的基本特征
- 云原生应用快速开发的 Serverless 积木块
- 快速开发一个航班查询预订 App
- 回顾总结
什么是云原生应用
云原生应用，是在云上构建和运行应用程序的一种方法。由于这种方法使用了云计算的交付模型，因此，不管是构建代码的部分、执行代码的部分，或是维护和运行代码的部分，都有相应的云服务支撑。所以，可以利用它快速地开发相应的软件应用，然后迅速地推向市场，进而更快地响应客户需要。
同时，在另一个层面，云原生应用也为开发者提供了更强的能力。
在如今的大数据时代，应用更迭换代的速度很快。过去开发应用得基于现有的框架，经过长年的累积，才能把应用做好做稳。
但是在云上，特别是后文中的如 Serverless 这样的新技术，可以使得在软件开发中，大部分工作被云服务所托管。因此，软件开发人员能够更多地关注自己业务的代码，从而大大减轻了自己的工作负担。
云原生应用还有个很大的特征，是云原生开发融合了 DevOps、持续交付、微服务和容器的概念，而整个云原生的方法也包含了 DevOps 的理念、持续交付的理念、微服务的相关的架构和治理模式及容器。
容器现在可以简单理解为 cobordism 的部分。
云原生应用的交付形态
基于云原生的应用的定义，关于其开发、成型、投入生产、推广使用。这背后有一套逐步演化的过程。
第一个阶段是 Demo，就是要实行实现论证新业务，将一些核心的功能、特定的功能做成Demo，吸引有关的用户对其投入。
第二个阶段就是 PoC（Proof of Concept），就是概念的论证，对于 Dome 来说 ，PoC 会比较独立，而且已经开始涉及更多具体的需求、用例的部分。所以也可以叫做独立的部分用例。
第三阶段是 Prototype，即原型设计或者原型开发的部分。这个时候它所覆盖的实际的应用的场景，还不是非常全面。系统也比较完整，但还不够庞大。
第四阶段是 Pilot，在 Prototype 做完之后，要将应用往生产去推，因此要把它做成生产系统，它不同于 Prototype（原型设计）里较为完整的系统，它有很多的考虑因素，不管是架构、运维，还是实际的代码变更、持续的交付等等。Prototype 往下就是 Pilot，即一个试点，这可能也还是部分用例，但比 Prototype 更好，因为它是生产系统，这时，会有真正的用户参与投入。
第五个阶段是 Production，即产生了真正的生产系统后，需要之前所定义好的所有用例，都要能满足用户的需求。
所以，整个云原生应用的交付形态，经历了 Demo→Poc→Prototype→Pilot→Production 五个阶段。
这中间最重要的就是 Prototype，即原型设计或原型开发的部分，这是真正完整的系统。所以云原生应用的快速开发，其实就是关注在原型设计。可以认为，云原生应用的快速开发，其实指的就是 Prototype——原型开发或者原型设计。
云原生应用快速开发的核心期望
对于快速开发的期望是：可以快速地验证所有的项目都是可行的，实质上是要快速创新，因为这背后基本上都是新的业务、新的需要。
第一，在快速开发的过程中，可以采用新型的软件技术。比如说 Serverless 架构：Serverless 方法，即一种新型的软件技术，它指使用了云的 Serverless 服务之后，开发人员就不用再关心应用背后所需要的，比如计算存储的资源；也不用去关注自动扩展的部分或者运维管理的部分，开发人员只需要专注自己的代码及其所写的业务逻辑即可。
第二，通过快速开发，可以推动应用最后往生产的方向发展，这可能需要依赖第三方的软件。更重要一点是，应用一定是跑在基础设施上的，期望它具备基础设施上所有相关的、自动和可扩展的能力。所以，在全面治理的方面，必须要借助云服务。
第三，持续优化的部分，也是对快速开发的期望。即在快速开发的过程中，不仅可以缩减开发周期，还可以降低风险、减少成本。
所以，简单来说，云原生应用快速开发的核心期望基本上就是快速创新、全面治理、持续优化这三点。
云原生应用快速开发的基本特征
云原生应用快速开发的基本特征，就是更低的成本、更高的效率、更好的产品，从小处着手、快速失败、持续迭代。
在快速开发的过程中，一定是从小处着手。如果快速地把应用交付出来，有不合格的情况，就让它回滚，然后再接着往下开发，因此需要持续迭代的部分。
在开发过程中，应用的基本特征大，就可以很明确看到原始应用快速开发的流程，基本上这是个很快的过程：先把用户故事用一天的时间列出来，这就是需求的部分。
然后，再花一天的时间，根据需求把架构设计出来，接着再花一天时间去做原型，因为它还有界面的部分。
在界面切换的部分，以及相关的前端或者后端的原型，在后面会经历更长时间的开发，最后实现真正的代码化，可以让产品跑起来，这个过程大多在 5 天之内。
最后，还需要两天的时间做测试，这是验证的部分，基本上开发人员的应用快速开发，经历的流程就是这些。
开发人员期待的低成本高效率，即对于产品是可以让它快速失败、持续迭代，就是这样的加速创新的过程。
云原生应用快速开发的 Serverless 积木块
在上面这张图中可以清楚的得知，如果要做好的原生应用的快速开发，基本上都会使用 Serverless 的积木块。Serverless 的积木块其实就是亚马逊云科技上的云服务，比如 Lambda，可以认为是 Function as a Service；Fargate 的部分就是完全托管的云计算服务。
关于 Kinesis 的服务，存储的部分就会有 S3，同时数据库就会有 NoSQL 的 DynamoDB；以及关系型数据库的Aurora Serverless。开发者可以很方便地根据不同的场景做出选择。
开发协调过程、调试的过程及调试完之后没有问题，真正地交付出去，包括中间还会有测试，因为是持续交付的流水线，在这个过程中亚马逊提供了很多的开发工具，包括基础设施及代码等等。
治理的部分也有可观测性，所以可以借助云原生应用快速开发的 Serverless 的积木块，帮助开发人员真正地把快速开发做好。
快速开发一个航班查询预订 App
接下来以一个实际的例子展示云原生应用快速开发的核心技术，即快速开发一个航班查询预定的 App。首先是要确定用户的目的地和出发地、预计出发时间、抵达时间，帮助用户分析、评估选择的航班、机票价格，最后由用户确定需要购买航班的机票。
除此之外，更重要的是，用户在购买机票的过程中，会实行会员制，会员会有相应的会员积分，以及保级升级的情况，对这类情况，在开发的航班查询预订 App 中需要有相应的会员服务。
这看似复杂，但使用云原生应用快速开发里的 Serverless 的积木块可以使其得到简化。
如上图是一个比较完整的航班查询预订和会员服务的 App。
可以看出，App 的界面上有很多的内容，比如数据分析和数据处理的部分，会用到 API 网关；也会用到Lambda或者是 Fargate。
除此之外，还有相关的前端、后端及其数据，以及机器学习进行分析。
因此，在前端页面输入起飞的机场、到达机场的时间，然后点搜索，其背后会显示相应的 API。
API 背后会有实际业务的逻辑，甚至在数据库中查询数据、反馈结果，所以要开发这样的 App：
第一，如果使用 Serverless 的积木块，包括前端的部分，有 Quasar framework，也是基于 Vue.js 通过包装，得到网站和应用的开箱的框架。
第二，渐进式的 JavaScript 的框架。
第三，我们亚马逊云科技的服务叫做 Amplify。即能帮助开发人员做前端 Web 以及移动 App 的全站式的应用，可以借助 Amplify 在几分钟之内配置相应的应用后端并让它们连接起来，这简化了开发的过程，仅点击几下就可以部署整个静态的外部应用。它也支持很多的外部框架，比如安卓、IOS 等等，所以在使用了 Amplify 的情况下，前后端的处理会变得容易。
第四个，Stripe Elements 是国外的一个支付的服务，因为在使用 App 的过程中，会购买机票，所以相应地会有支付的框架，这涉及到应用的前端框架。
第五，就是认证的部分，认证部分有云服务配合，即 Amazon Cognito，它可以帮忙来做用户的管理、认证的管理。
第六，是核心的部分，即 API，有前端必然会需要有 API,这是因为要用到 API 的网关。
第七，是亚马逊云科技 AppSync。亚马逊云科技 AppSync 其背后的真正的含义是在于说它使用了 GraphQL 的技术，GraphQL 的好处是可以提高效率，很多时候要在数据库里查比较复杂的信息内容，或者有很多联邦查询的时候，可能这种 rest 的方式其实是比较困难，所以 GraphQL 可以帮助前端开发人员查询多个数据，然后帮助更快地开发应用，效率上有极大的提高，所以亚马逊云科技 AppSync 非常有意义。
详细来看，第一个页面，会在起飞的机场和到达的机场里面，需要选择一个具体的日期，然后点击 SEARCH FLIGHTS (查询航班)，这个动作背后做的事情，会在云服务里有已经定义好的相应的 API。然后前端的部分会去调用 这个 API。而 API 要去到达目的数据库中查询航班的信息。
之后的 VTL，叫做阿帕奇 Velocity 的模板语言，它可以很方便地定义来自客户端的 GraphQL 的请求，然后转换成所需要的数据源的方式或是格式。
上面页面表示已经选好航班，接着下单的过程。这个过程背后实际在后端的部分即 API 网关，然后有 Lambda 的部分，它会写相应的逻辑，接着调用第三方的支付平台的 API，最后实现相应的支付的动作。
同时也应当注意，有支付失败、取消预定或用户没有支付的情况等等，在这样的过程中，需要用到另外的亚马逊云科技服务：Step Function， Step Function 背后有编排的服务，其实就是设计 workflow，即整个预定和支付的过程中所有的工作流。
所以它有一定的逻辑，这个逻辑是需要通过亚马逊科技的 Step Function 方式来帮助实现相应的状态机和工作流。
再往下，就会有 listBookings，即查询记录，这能使用户的行为动作更为清晰。
因为这涉及到从 DynamoDB 中查询相关的航班信息，而另外一个 DynamoDB 中可能需要查询相关的订单信息，它们是两个不同的数据库，储存的是不同数据的内容，一个是航班信息，一个是预订信息。
当然，在做 listBookings API的时候，需要同时读取这两个部分的内容，然后组合起来把数据重新整理之后，再显示到前端去，所以这个过程必须要用到 AppSync，因为 AppSync 就是使用 GraphQL 的方式，帮助前端开发人员查询多个数据库。
最后，就是需要考虑的会员制的问题，毕竟会员有会员积分、会有等级等等，具体操作简单，但背后的原理就是要做会员等级的制定细则，每次做完制定之后，所有的会员等级的积分计算以及等级的升降，都需要通过 Lambda 服务的方式写出逻辑。而数据可能存在 DynamoDB 数据库中，API 网关其实代表相应 API 的支撑部分，所以可以看到，如果有订单确认成功，会有程序计算相关的会员分数，而这样的过程，依赖于亚马逊云科技的服务，这都与 Serverless 相关，也就是原生应用，快速开发中所需要的所有的积木块。
汇总一下，基本上架构非常清楚：有前端和后端。前端部分，即真正的用户航班查询预订和会员的 App 打开，这个过程中，看到的页面其实是一个网站移动端，在这个网站上最前面有它的 CDN，即在内容分发托管的部分，用的是亚马逊科技的 CloudFront。前端的部分就是对象存储的 S3，其中储存着页面的所有信息、页面的资源等等。也会使用前文提到的框架，可以便于开发人员做相关开箱的急用的支撑，而且其对桌面和移动浏览器的支持也非常强。
后端部分就是 API 的部分， API 的部分使用的是亚马逊云科技的 AppSync。AppSync 背后有很多复杂的逻辑，因为其往往牵扯到很多内容，比如说航班信息的查询、会员等级的部分。
在预定的部分、支付的部分，是分成四大不同类型的 APM，其中需要用到 Serverless 的积木块，比如 DynamoDB、Lambda、API 网关、Step Functions 等等，都是前文提到的云原生应用快速开发里的 Serverless 的积木块，所以，亚马逊科技的云服务，可以帮助开发人员快速进行云原生应用的开发。
除此之外，还有持续的自动化监控等内容，列入最终部分，也会使用到亚马逊科技的 CloudFormation、X-Ray 和 CloudWatch 等工具。
接下来展示的是代码的概样。基本上，在 App 的开始要进行登录、做用户的认证，这背后使用了 亚马逊科技的 Amplify 框架，而这背后用户认证的部分，由亚马逊科技服务的 Cognito 实现。
上图展示的是 signUpConfig，即注册过程中所要用的所有参数，比如用户的姓名。同时，在相关的资源中，做相关 Amplify 发展的认证。
比较重要的一点是，前端的很多内容是通过亏损得到的，在 API 的部分基本都使用了亚马逊科技的 App，所以可以得到很多数据，比如航班信息、预定信息以及会员等级信息，其在具体的建制队中定义。
基本上，可以看到的大多数的代码都是 int（整型）、string 型，也有少数的 Boolean 型，这些就是详细的数据的定义、结构的定义。
如上是关于 API 的代码，其实 API 很简单，上面的代码已经加上了认证的过程，它也定义了所有相关字段的部分。通过这种方法形成亚马逊云科技 App 的 API，这个 API 背后会产生相关的日志，这个日志可以反映出各项指标的情况。
在实际中，开发出 App 之后，大多数服务都是托管完成，开发人员只要写与前端相关的内容，像 Kinesis 就是一个开箱即用的配件，所以很多功能只要开发人员简单搭配即可。
简单来说，像 back into 的部分、基础设施的部分、第三方的部分基本上 Serverless 都可以帮助完成，所以开发人员只要关注自己的代码。通过这种方式，可以使用亚马逊科技的 Amplify 中的功能，然后快速地做相关构建部署和验证的部分，这是个非常方便的过程。
除此之外，比较重要的是，因为涉及到很多的不同服务之间的调用关系。因此可以使用亚马逊云科技的 X-Ray 服务，它可以将各种调用的信息、调用的服务显示在 X-Ray 链路追踪的拓扑图中，所以一旦有任何问题发生时，能清楚地看到绿圈会发生变化，可能部分变黄色、全部变黄色，或者出现红色。红色表示开发的产品是不能使用的。
以及，在监控的部分，使用到了亚马逊云科技的 CloudWatch，它可以帮助开发人员很快地做出相应的仪表盘。
所有如同订单和支付的 KPI，包括很多其他的数据点，都可以使用 CloudWatch 的云服务，画出相应的仪表盘。这也是快速开发的重要支撑力量。
在日志部分中，也可以通过亚马逊云科技的 CloudWatch 服务，通过查询相关的语句、字段，把相应日志中的数据筛选出来，做相应的分析或台账工作。
总而言之，在这个看似复杂的航班查询预定和会员管理的 App，牵扯到大量的项目，但是，其中有很多服务都可以使用云原生应用快速开发的方法。只要使用其提供的 Serverless 积木块（Serverless 服务），开发人员就可以快速地建造这个 App。
右边的二维码，即该 App 的 get up 的开源地址，大家如果感兴趣可以扫一扫，就可以找到相关的代码。读完代码后再阅读今天的分享，可以对云原生应用快速开发有更深入的理解。
总结
简单总结一下，首先，云原生应用是在云上构建和运行应用程序的一种方法，其交付形态经历五个阶段。
第二，也是本期分享中最重要的部分，即快速开发的部分。对于快速开发，希望达到的效果是低成本和高效率，这其中有三个基本的流程和六大特征。同时，快速开发需要使用到的云服务所提供的 Serverless 积木块，也叫做 Serverless 服务，来支撑整个云原生应用的快速开发。
第三，采用了真实的例子，就是航班预定查询以及会员管理的 App，帮助理解如何快速地从前端、后端、数据库以及相关的 API 的部分，可以很快速地把看起来比较复杂的 App，通过相关的 Serverless 的云服务，实现快速开发的效果。
希望本期分享可以给读者带来启发。在实际中，有了云技术之后，人们对很多事情的看法也会发生相应的变化。希望在未来通过在云中学习、云中开发，获得更多持续迭代的业务价值。这也是本期讲到云原生应用快速开发的核心技术的初衷。