简介：新一代的技术架构是什么？如何改革？是很多互联网企业面临的问题。而云原生架构则是这个问题最好的答案，因为云原生架构对云计算服务形式与互联网架构进行整体性降级，粗浅扭转着整个商业世界的 IT 根基。

作者：计缘，阿里云解决方案架构师

云原生架构是什么

回顾过去十年，数字化转型驱动着技术创新和商业元素的一直交融和重构，能够说，当初曾经不是由商业模式决定采纳何种技术架构，而是由技术架构决定企业的商业模式。所以无论是行业巨头还是中小微企业都面临着数字化转型带来的未知时机和挑战。时机是商业模式的翻新，挑战来自对整体技术架构的改革。

新一代的技术架构是什么？如何改革？是很多互联网企业面临的问题。而云原生架构则是这个问题最好的答案，因为云原生架构对云计算服务形式与互联网架构进行整体性降级，粗浅扭转着整个商业世界的 IT 根基。

尽管云原生的概念由来已久，很多人并不了解什么是云原生。从技术的角度来讲，云原生架构是基于云原生技术的一组架构准则和设计模式的汇合，旨在将云利用中的非业务代码局部进行最大化的剥离，从而让云设施接管利用中原有的大量非性能个性（如弹性、韧性、平安、可观测性、灰度等），使业务不再受非功能性业务中断困扰的同时，具备轻量、麻利、高度自动化的特点。简略的说，就是帮忙企业的业务性能迭代更快、零碎能接受住各种量级的流量冲击的同时，构建零碎的老本更低。

传统架构与云原生架构的区别

上图展现了在代码中通常包含的三局部内容，即业务代码、第三方软件、解决非性能个性的代码。其中“业务代码”指实现业务逻辑的代码。“三方软件”是业务代码中依赖的所有三方库，包含业务库和根底库。“解决非功能性的代码”指实现高可用、平安、可观测性等非功能性能力的代码。

这三局部中只有业务代码是对业务真正带来价值的，另外两个局部都只算附属物，但随着软件规模的增大、业务模块规模变大、部署环境增多、分布式复杂性加强，使得明天的软件构建变得越来越简单，对开发人员的技能要求也越来越高。云原生架构相比拟传统架构后退了一大步，即从业务代码中剥离了大量非功能性个性到 IaaS 和 PaaS 中，从而缩小业务代码开发人员的技术关注范畴，通过云服务的专业性晋升利用的非功能性能力。

这便是云原生架构的外围思路。

为什么须要云原生架构

解释完什么是云原生架构后，大家可能会有进一步的思考，即当今互联网企业为什么须要云原生架构。剖析下 SaaS 的市场规模能够发现，2019 年 SaaS 市场规模为 360 亿元，2020 年仍放弃可观上涨趋势，2022 年 SaaS 市场规模预计破千亿。

纵观中国企业级 SaaS 行业倒退历程，大体分为四个阶段：2015 年之前，中国市场和绝大多数中国企业对“什么是 SaaS”不足根本认知，基于公有部署的传统软件模式仍为支流，企业级 SaaS 市场方兴未艾。到了 2015 年，随着云计算技术的进一步成熟，中国企业级 SaaS 行业进入疾速成长阶段，这个慢赛道逐步为公众所知。

时至今日，在疫情、经济、社会环境的大背景下。互联网企业开始寻求新的商业模式，一些抓住机会的 SaaS 企业实现了疾速响应，后果是其业务出现成倍增长，比方：

• 餐饮 SaaS 厂商帮忙线下餐饮门店开发小程序点餐零碎，实现无接触点餐。
• 电商批发畛域的 ERP 厂商帮忙企业建设会员管 理零碎。
• 营销 SaaS 厂商通过流量平台帮忙企业在线营销，近程触达客户。

所以，在“如何活下去”成为热门议题的背景下，疾速响应能力成为企业之间的外围竞争劣势，SaaS 企业须要及时满足市场的新需要。而这正是前几年中国 SaaS 企业为了疾速占领市场、自觉跟风、一味借鉴国外产品所产生的天生缺点。为补救这些缺点，SaaS 厂商须要依据市场的需要疾速调整产品服务方向，业务性能要多元化，业务体系须要新的枝杈，在技术上也有更大的挑战。

除了市场带来的压力，SaaS 企业本身也有诸多痛点：

• 大多 SaaS 产品只做所谓的通用能力，或者只是一味模拟国外产品，一旦深刻到行业属性比拟重的场景时便无奈满足需要，所以被贴上了“半成品”的标签，导致市场接受程度不如预期。
• 产品模块繁多、性能类似的 SaaS 产品很容易陷入价格竞争，最初只能以亏损取得网络效应，但会终食恶果。
• 市场对 SaaS 产品的定制化需要过多，使得 SaaS 企业不足对产品打磨的精力，把一个 SaaS 型公司做成了我的项目型公司。

SaaS 企业解决以上的外忧内患的外围就是专一在业务。要做好一款 SaaS 产品，对于业务渠道、竞争格局、用户体验等诸多方面都有更加严苛的要求，甚至从市场经营、产品经理到研发、运维都要专一在业务，所有这些角色的本职工作都应该为行业业务服务，行业的深度剖析，疾速响应市场，稳固的产品质量这些是必须要具备的。但这就要求技术具备更快的迭代速度，业务推出速度从按周晋升到按小时，每月上线业务量从“几十 / 月”晋升到“几百 / 天”，并且不可承受业务中断。

另一个互联网企业须要云原生转型的起因是中国的刘易斯拐点曾经到来。刘易斯拐点，即劳动力过剩向短缺的转折点，是指在工业化过程中，随着农村充裕劳动力向非农产业的逐渐转移，农村充裕劳动力逐步缩小，最终达到瓶颈状态。用大白话说就是中国的人口红利曾经逐步消退，企业劳动力老本一直减少，加上 2020 年疫情的影响，老本因素越来越成为企业的重要考量。而 SaaS 产品订阅制付费、通用性强、低部署老本的特点，便成了企业降本增效的新抉择。这是 SaaS 企业在市场中的机会，而且对于 SaaS 企业自身来说，同样有降本增效的需要，而且外部降本增效做得越好，SaaS 产品在市场上的竞争力会更加显著。

以上这些现状的解法和云原生架构和外围能力不约而同：

• 云原生将三方软件和非功能性能力的齐全兜底，能够极大水平解放企业研发、运维人员的精力，并使其能够专一在业务上。
• 零碎的横向扩展性、高可用性、健壮性、SLA 由云原生架构兜底，解决了 SaaS 产品最禁忌的稳定性问题。
• 将一些自建的组件迁徙至云原生架构中，对传统的部署形式和资源进行云原生化，GitOps 的落地，在资源老本和人力老本方面都有进一步的优化。

如何落地云原生架构

在聊如何落地云原生架构之前，咱们先来看一看云原生架构成熟度模型（SESORA）：

云原生架构成熟度模型

云原生架构成熟度模型有六个评判维度，能够将成熟度划分为 4 个级别。我会从自动化能力、无服务化能力、弹性能力、可观测性、韧性能力这五个维度，贯通阐明如何落地云原生架构。

传统架构

上图展现的是一个较传统的 Java+SpringCloud 架构应用服务侧的部署架构。除了 SLB，基本上所有的组件都部署在 ECS 上。上面咱们来一起看看如何将这个架构转型为云原生架构。

无服务化（Serverless）

Serverless 的概念是什么在这篇文章不在赘述，能够参阅这篇文章进行理解。应用 ECS 集群部署服务的架构有两个显著的短板：

• 运维老本高：ECS 的各项状态、高可用都须要运维同学保护。
• 弹性能力有余：每次有大促流动时，都须要提前购买 ECS，扩大服务的节点数，而后再开释，并且这种状况只实用于定时定点的流动，如果是不定时的流量脉冲则无奈应答。

所以首先咱们要将服务的部署形式 Serverless 化，咱们能够抉择 Serverless App Engine（SAE）作为服务利用的公布、部署平台。SAE 是面向利用的 Serverless PaaS 平台，可能帮忙用户免运维 IaaS、按需应用、按量计费，做到低门槛服务利用云原生化，并且反对多种语言和高弹性能力。

命名空间

关上 SAE 控制台，咱们首先创立命名空间，SAE 的命名空间能够将其下的利用进行网络和资源的逻辑隔离，通常咱们可应用命名空间来辨别开发环境、测试环境、预发环境、生产环境。

创立利用

创立好命名空间后，咱们进入利用列表，即可抉择不同的命名空间，看到其下的利用或者创立利用：

抉择对应的命名空间，而后创立利用：

• 利用名称：服务名称，用户自行输出。
• 专有网络配置：

• • 主动配置：主动帮用户配置 VPC、Vswitch、平安组。这些组件都会新创建。

    • 自定义配置：用户抉择命名空间，VPC，VSwitch 以及平安组。个别抉择自定义配置，因为咱们的服务所属的 VPC 必定要和其余云资源的 VPC 是雷同的，这样能力保障网络畅通。这里须要留神的一点是，当在新的命名空间下第一次创立好利用后，该命名空间就会和所选的 VPC 进行绑定，之后再创立利用时，该命名空间对应的 VPC 不可更改。如果须要更改，能够进入命名空间详情进行更改。
• 利用实例数：利用（服务）节点数量，这里的节点数量按需设置，而且不是最终设定，因为后续能够手动或者主动的扩缩节点数。
• VCPU/ 内存：该利用在运行过程中须要的 CPU 和内存的规格。这里的规格是单个实例数的规格。既如果抉择了 2C4G，那么有 2 个实例的话，就是 4C8G。

配置完根本信息后，下一步进入利用部署配置：

• 技术栈语言：Java 语言反对镜像、War 包、Jar 包三种部署形式，其余语言反对镜像部署形式。以 Java Jar 包形式为例：

• • 利用运行环境：默认规范 Java 利用运行环境即可。

    • Java 环境：目前反对 JDK7 和 JDK8。
    • 文件上传形式：反对手动上传 Jar 包或者配置能够下载 Jar 包的地址。
• 版本：反对工夫戳和手动输出。
• 启动命令设置：配置 JVM 参数。
• 环境变量设置：设置容器环境中的一些变量，便于利用部署后灵便的变更容器配置。
• Host 绑定设置：设置 Host 绑定，便于通过域名拜访利用。
• 利用健康检查设置：用于判断容器和用户业务是否失常运行。
• 利用生命周期治理设置：容器侧的生命周期脚本定义，治理利用在容器在运行前和敞开前的一些动作，比方环境筹备、优雅下线等。
• 日志收集服务：和 SLS 日志服务集成，对立治理日志。
• 长久化存储：绑定 NAS。
• 配置管理：通过挂载配置文件的形式向容器中注入配置信息。

我应用 Jar 包的形式部署完利用后，在对应命名空间下就能够看到刚刚创立的利用了：

点击利用名称能够查看利用详情：

绑定 SLB

因为 ServiceA 在架构中是对外提供接口的服务，所以须要对该服务绑定公网 SLB 裸露 IP 和做负载平衡，在 SAE 中，绑定 SLB 非常简单，在详情页中，即可看到利用拜访设置：

增加 SLB 时能够抉择新建也能够抉择曾经创立好的 SLB：

服务 / 配置核心

对于微服务架构，服务中心和配置核心是必不可少的，大家罕用到个别是 Nacos、Eureka、ZooKeeper 三种。对于云原生架构来讲，依据不同的场景，服务 / 配置核心能够有以下几种抉择：

对于现状就是应用 Nacos 的客户而言，转型云原生架构，服务 / 配置核心如下面表格所示有两种抉择：

• 须要疾速转型，对服务 / 配置核心高可用要求不是特地极致的状况下，倡议间接应用 SAE 自带的 Nacos 即可，代码不须要做改变，间接在 SAE 中创立利用即可。SAE 控制台提供的配置管理在界面操作和性能上和开源 Nacos 的控制台基本一致。
• 对服务 / 配置核心高可用要求比拟高的状况下，倡议应用 MSE Nacos，它的劣势是独享集群，并且节点规格和节点数量能够依据理论状况动静的进行调整。惟一有余的一点就是须要批改 Nacos 的接入点，算是有一点代码侵入。

对于现状是应用 Eureka 和 ZooKeeper 的客户而言，倡议间接应用 MSE Eureka 和 MSE ZooKeeper。

这里我简略介绍一下 MSE。微服务引擎 MSE（Microservice Engine）是一个面向业界支流开源微服务框架 Spring Cloud 和 Dubbo 一站式微服务平台，提供治理核心、托管的注册核心和托管的配置核心。这里咱们用到的是 MSE 的托管注册核心和托管配置核心。

MSE 有三块外围的性能点：

• 反对三大支流服务中心，节点规格和数量灵便搭配，可在运行时动静调整节点规格 / 数量。
• 通过命名空间逻辑隔离不同环境。
• 配置变更实时推送并且可追踪。

弹性能力（Elasticity）

云原生架构成熟度模型中的弹性能力同样依靠于 SAE 来实现，因为 Serverless 的底层实现原理，所以在 SAE 中的利用实例数（节点数）扩缩速度十分快，可达到秒级。

进入利用详情页的实例部署信息，能够看到利用的具体实例：

SAE 提供了两种扩缩利用实例数的形式，手动形式和主动形式。

手动扩缩

在控制台右上方有手动扩缩操作按钮，而后抉择要扩缩到的实例数即可：

当进行扩缩时，咱们能够看到具体实例的变更状态：

主动扩缩

在控制台右上角有主动扩缩操作按钮，而后能够看到创立扩缩规定的界面。SAE 主动扩缩提供工夫策略和指标策略两种。

上图是工夫策略，即设置好具体的工夫节点，在这个工夫节点要将利用的实例数扩到几个或者缩到几个。这种策略适宜流量高峰期有绝对明确工夫节点的场景，比方在线教育的客户，通常流量顶峰在早晨 8 点开始，11 点逐步完结，这种状况下，通过定时策略在 7 点半左右把利用的实例数扩起来，而后 11 点之后逐步把利用实例数缩回失常。

上图是指标策略，目前提供 CPU 使用率、内存使用率、利用的 QPS 阀值、利用接口均匀响应工夫（RT）阀值四种指标，这四种指标能够配合应用。当这四种指标其中有一种达到阀值后就会触发扩容，会对利用实例进行逐步扩容。当指标小于阀值后触发缩容。这种策略适宜流量顶峰工夫不固定的场景，比方市场营销，游戏经营。

老本优化

对于弹性能力，大家可能更多的是关注它能让零碎疾速撑持流量脉冲，减少零碎横向扩大的能力。其实因为 SAE 有极致的弹性能力，再加上按分钟、按量计费的模式，对整体的资源老本是有肯定优化的。

可观测性（Observability）

利用侧的可观测性分两个维度，一是纵向的 Metrics 指标，比方主机的 CPU、内存、磁盘各项指标，Pod 的 CPU、内存各项指标，JVM 的 Full GC、堆内存、非堆内存各项指标。另一个维度是横向的申请调用链路监测，上游服务到上游服务的调用、上游接口到上游接口的调用。

在监控微服务架构时，通常须要从三个角度来看：

• 利用的整体健康情况。
• 利用每个实例的健康状况。
• 利用每个接口的健康状况。

而 SAE 对利用的监控也都笼罩了上述这两个维度和三个角度。

利用整体健康情况

进入利用详情页，点击左侧菜单中的 利用监控 / 利用总览，便能够看到利用的整体情况：

• 总申请量：能够高深莫测的看到申请量是否显著的异样，比方骤降或者陡升。
• 均匀响应工夫：利用整体接口的均匀响应工夫，这个指标间接反映最实在的利用健康状况。
• Full GC：JVM 里比拟重要的指标，也是会间接影响零碎性能的因素。
• 慢 SQL：智能抓取执行工夫大于 500ms 的 SQL。
• 一些曲线视图：帮忙咱们把握不同时段的利用状况。

利用实例节点健康状况

进入利用详情页，点击左侧菜单中的 利用监控 / 利用详情，便能够看到利用每个节点的信息：

从上图能够看到，左侧会列出以后利用的所有实例节点，包含该节点的均匀响应工夫、申请次数、谬误数、异样数。如果咱们依照影响工夫降序排序，比拟靠上的节点就是响应工夫较慢的节点，而后咱们就须要剖析是什么起因导致这些节点的响应工夫较慢。所以，右侧会提供了一些查看维度来帮忙咱们剖析排查问题。

比方查看 JVM 指标：

利用接口健康状况

进入利用详情页，点击左侧菜单中的 利用监控 / 接口调用，便能够看到利用每个接口的信息：

接口监控和利用实例节点监控的思路统一，左侧会列出所有申请过的接口，同样显示了响应工夫、申请数、谬误数，右侧同样提供了一些查看维度来帮忙咱们剖析接口 RT 高的起因。

比方查看 SQL 调用剖析：

纵向 Metrics 指标

在上述三个角度中，其实曾经涵盖了绝大多数 Metrics 指标，比方有利用衰弱状态的指标、JVM 的指标、SQL 指标、NoSQL 指标等。

横向调用链路

在很多时候，咱们单纯的看 Metrics 指标是无奈确定问题的根本原因的，因为会波及到不同服务之间的调用，不同接口之间的调用，所以须要查看服务和服务之间、接口和接口之间的调用关系以及具体的代码信息。在这个维度上，SAE 集成的 ARMS 的监控能力便能够实现。咱们在利用监控 / 接口调用 / 接口快照中能够看到有申请的接口快照，通过 TraceID 便能够查看该接口的整体调用链路：

从下面这个图咱们能够看出很多信息：

• 该接口在服务级别的残缺申请链路，比方ikf（前端）-> ikf-web(java 服务)-> ikf-blog(java 服务)-> ikf-blog(java 服务)
• 每个服务的状态状况，比方状态一列是红点，阐明在这个环节是有异样呈现的。
• 在每个服务中申请的接口名称。
• 每个服务的申请耗时。

除了上述这些显性的信息以外，还有一些隐性的信息：

• 上游服务 ikf-web 的总耗时是 2008ms，但上游服务 ikf-blog 的总耗时是 5052ms，而且耗时终点是一样的，阐明 ikf-web 到ikf-blog是一个异步调用。
• 既然 ikf-web 到ikf-blog是异步调用，然而 ikf-web 的耗时有 2s 之多，阐明 ikf-web 服务中的接口也有问题。
• 在 ikf-blog 服务中，又有外部接口被调用，因为从调用链上呈现了两个ikf-blog，并且这个外部调用是同步调用，而且问题呈现在最初一个接口调用上。

从以上这些信息能够帮咱们放大和圈定问题根因呈现在哪个环节的范畴，而后咱们能够点击办法栈一列的放大镜，查看具体的办法栈代码信息：

从办法栈这里咱们又能够失去很多显性信息：

• 具体的办法。
• 每个办法的耗时。
• 办法产生的具体异样信息。
• 数据库操作的具体 SQL 语句，甚至 SQL 上的 Binding Value。

当然除了显性信息外，还有一个比拟重要的隐性信息，比方咱们能够看到 BlogController.findBlogByIsSelection(int isSelection) 这个办法的耗时是 5s，然而该办法外部的数据库操作的耗时很少，只有 1ms，阐明耗时是属于业务代码的，毕竟业务代码咱们是抓不到也不会去抓取信息的。这时咱们能够有两种形式去定位具体问题：

• 从办法栈信息中曾经晓得了具体的服务和具体的办法，那么间接关上 IDE 查看、剖析代码。
• 查看办法栈页签旁边的线程分析，也根本能够确定问题所在。比方上图这个状况，咱们查看线程分析后会发现他的耗时是因为java.lang.Thread.sleep():-2 [3000ms]。

韧性能力（Resilience）

对于云原生架构的韧性能力，我会从优雅高低线、多 AZ 部署、限流降级三个方面来聊一聊。

优雅高低线

一个好的产品，要能疾速应答用户对产品性能、能力具备普适性的反馈和意见，能疾速响应市场需求的变动。那么产品的性能就须要疾速的做迭代和优化，从 IT 层面来看，就是要有疾速、高效、高质量的公布变更流程，可能随时进行生产环境的服务公布。

然而这会带来一个外围问题，即频繁的服务公布，并且不能影响用户体验，用户的申请不能断流。所以这就要求咱们的零碎部署架构中有优雅高低线的能力。

以微服务架构来阐明，尽管开源的产品有能力和计划做到近似优雅高低线，但也是近似做到，当公布服务节点较多的状况下仍然会有断流的状况。所以开源计划有诸多问题：

• 注册核心不牢靠、告诉不及时。
• 客户端轮训不实时、客户端缓存。
• 自定义镜像非 1 号过程，Sigterm 信号无奈传递。
• 无默认优雅下线计划，须要增加 actuator 组建。

在无服务化 / 服务配置核心章节中，我论述了 SAE 自带的服务中心和 MSE 的服务中心，无论应用那种计划，咱们都对优雅高低线做了进一步的优化。

从上图能够看到，部署在 SAE 的利用具备被动告诉服务中心和服务消费者的能力，再联合 Liveness 利用实例探活和 Readiness 利用业务探活的机制，能让咱们的服务在进行部署和因为其余起因挂掉时不会影响用户的失常拜访。

多 AZ 部署

本着鸡蛋不能放在一个篮子里的准则，一个利用的多个节点，应该散布在不同的可用区，这样整体利用的高可用和健壮性才是足够好的。SAE 反对设置多个交换机（VSwitch），每个交换机能够在不同的可用区，这样在部署、扩容利用的节点时会随机从可选的可用区拉起实例：

这就防止了当某个可用区呈现问题挂掉时，整体零碎因为在一个可用区而挂掉，这也是最根本的同城多活的实际。

限流降级

限流降级是零碎断臂求生的能力，在遇到突发的流量脉冲时，能够及时限度流量，防止整个零碎被击穿，或者当流量超出预期时，及时切断非核心业务，开释资源来撑持外围业务。

目前对于 Java 利用，SAE 也反对限流降级的能力，首先对利用的所有接口的申请指标进行抓取和监控：

而后咱们能够针对每一个接口设置流控、隔离、熔断的规定，比方我对 /checkHealth 接口设置一条流控规定：

当该接口的 QPS 达到 50 后，单个机器超过 50 的申请将疾速失败。比方咱们对一个有 6 个节点的利用进行压测时，能够看到每个节点的 QPS 状况：

当开启流控规定后，能够立刻看到限流的成果：

能够看到 QPS 被精准的管制到 50，超过 50 的申请间接返回失败。

自动化能力（Automation）

在自动化能力方面，我次要从 CICD 流程这个维度来聊一聊。大家从下面章节的截图能够看到，有很多是 SAE 控制台的截图，在理论利用中必定不会通过控制台来一个一个公布利用，必然都是通过 CICD 流程来做自动化的利用打包和公布流程。

SAE 在这个方面提供两种实现自动化运维的形式。

基于 Gitlab 和 Jenkins

目前很多企业的 CICD 流程都是基于 Gitlab 和 Jenkins 来做的，那么 SAE 也反对将公布的操作集成到这种计划里。这个计划的外围是 SAE 会提供一个 Maven 插件，同时对应有三个配置文件，Maven 插件通过这三个配置文件中的信息将打包好的 Jar/War 或者镜像公布到对应的 SAE 利用中。

• toolkit\_profile.yaml：配置 RegionID、AccessKey ID、AccessKey Secret。
• toolkit\_package.yaml：配置比方利用部署包类型、部署包地址、镜像地址。
• toolkit\_deploy.yaml：配置比方 SAE 利用的 ID、利用所属命名空间 ID、利用名称、公布形式等。

更具体的配置信息能够参阅该文档。

而后在 Jenkins 的工作中，对 Maven 设置如下的命令即可：

clean package toolkit:deploy -Dtoolkit_profile=toolkit_profile.yaml -Dtoolkit_package=toolkit_package.yaml -Dtoolkit_deploy=toolkit_deploy.yaml 

这样就能够很容易的将 SAE 的部署流程集成到基于 Gitlab 和 Jenkins 的 CICD 计划里了。

基于 Open API

还有一些企业会本人研发运维平台，运维赋能研发，由研发同学在运维平台上进行运维操作。面对这种场景，SAE 提供了丰盛的 Open API，能够将 SAE 管制台上 90% 的能力通过 Open API 集成到客户本人的运维平台中。具体的 OpenAPI 阐明能够参加该文档。

总结

基于 SAE 武装过零碎后，整体的部署架构会变成这样：

云原生架构成熟度模型（SESORA）在我论述的这五个维度一共是 15 分，基于 SAE 的云原生架构在这五个维度会达到 12 分：

• 无服务化：3 分
• 弹性能力：3 分
• 可观测性：2 分
• 韧性能力：2 分
• 自动化能力：2 分

对于上手、实际、落地快捷简略，又能达到比拟好的云原生架构成熟度的 SAE 计划，大家还在等什么呢？一起实际起来吧。如果大家有任何问题，能够退出 钉钉群：35712134来寻找答案，咱们不见不散！

版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。