开发者学堂课程【云原生最佳实践案例：实战案例—南瓜电影】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1052/detail/15620
实战案例-南瓜电影
内容介绍
一、实战讲解南瓜电影1特性角度
二、实战讲解南瓜电影2使用角度
一、实战讲解南瓜电影1特性角度
今天演讲的主要部分大概包括三个层面，第一个介绍一下阿里云的 sae的一些整体情况。
第二部分会分享sae新发布的一些特性。
第三部分将分享一些阿里云的最佳的一些业务实践，那我经常会把sae看作一个三岁的孩子，因为是在18年首次面向业界发布了这样的一个面向应用的service的pass的产品，大家也看到了sae也已经三岁了，那在这个回顾这三岁的过程当中，我看到了是说也是基于k8s的底座，然后以应用为中心，同时屏蔽掉了一些k8s底层实现的这种技术细节。
同时也通过的开发开发了一些面向应用级别的这样的一个UI和API，那极大的降低了客户在使用k8s和service这样的一个技术门槛。
那基于此，现在也可以郑重的对外宣告，现在已经服务了阿里云上的万家的这样的，一个企业级的客户，同时也得到了客户的广泛认可。这里我也同样要感谢一下南瓜电影对阿里云一直以来的sae这个产品的一直以来的支持信任和包容，未来会更深入的进行一些合作。
那我同时也回顾了一下sae其实的到来也也更像一场及时雨，为什么这么说是因为sae的到来让service变得更加的通用，同时也让or on service变成了一种可能。
同时也打破了service以以之前的一些部署的边界，为什么这么讲因为之前很容易都想到的是说一一提到service，大家首先想到的是什么是前端的全站或者是一些小程序的应用，那通过sat看到的是说后端的这种微服务 Sars服务或者是说嗯一些物联网的应用，其实都可以实现四俄罗斯话，那这是我看到的一个点。
那第三点是说看到了一个是说可以让service从复杂变得简单，那为什么这么讲是因为看到通过阿里与sae，控制台实现了很多，比如说的炸包外包或者是说一些镜像，包括PHP的这包，通过通过控制台都可以玩成这样的一个部署。
同时还提供了全套的这种微服务的治理能力和配套的这种运维的一些能力。那基于此可以看到的是说容器化改造的过程中，可以无感的去拥抱k8s同时完成一个service架构的一个升级。
那这是我看到一个点，所以可以看到的是说sat其实可以覆盖应用上云的所有场景，相信团队都会相相信这样的一个事就是说未来sat一定是企业应用上云的一个首选方案。
那第二部分我将介绍一下sae近期发布的一些新特性，那第一个特性是弹性能力的2.0，也是云烟城大家庭的孩子，一个一个刚刚孵化三年的一个孩子，所以底层也是基于语言生ackk8s的一个能力，在这个能力之上丰富了弹性策略和指标，那这里的指标其实包含三个维度，第一个是做了TCP连接数，第二个是slb的qps第三个是rt的触发弹性，那这这这三个就可以帮助企业能更细力度的去做，基于业务的弹性，认为这样会更加的精准一些。
同时还提供了包括可以设置扩缩容的这种步长，同时还有冷却时间这样的一些高级的设置，那这样就可以让客户在快速的这种比如说有一些突发的场景，或者是说在搞一些大促，都可以保证业务能够持续的维稳。
那同时还发布了一个Java能启动的一个提速，提速了40%，这也是刚才南瓜电影的CTO庄总提到的一个点，就是他希望Java的冷启动能够快速的去提升一些性能，那为什么会做到这样一个点这就完全要归功于阿里巴巴开源的一个抓跟while11这样的一个jdk的版本。 通过它提供的一个APP的CDs的启动加速的技术，通过这种技术是在应用的第一次启动的过程当中是将应用的整个启动的过程全部的进行了一个缓存，然后并且把它保存了起来，那么当应用再次启用的时候，会通过缓存去启动的应用，这样的话就加速了，这整个的部署的这样一个效率同时，也看到做了一些数据的对比相比于标准的open gdk，大概可以在Java冷启动耗时这样这样的一个场景下可以提升40%左右。
同时也发布了第三个特性，就是极致部署效率15秒，那这个是通过一系列的底层技术的升级，包括刚才的演讲也提到了，使用到了沙箱容器2.0，同时也使用了镜下镜像加速的一个方案那等等的一些手段，做到了端到端的部署，能够优化到了15秒。
那第三第四个就是一站式的PHP应用托管，现在可以很自豪的讲，是可以支持PHP的这个包能够部署到阿里云的ice的上面，同时还支持了PHP的wrong time的运行时和一些应用监控的能力，通过这三个能力将PHP做到了一站式的部署体验，所以我也这里也呼吁大家可以后在线下的时候能通能够通过阿里云的这样一个控制台，sa的控制台去感受一下 PHP的这样的一个体验。
然后演讲的第三部分，我将结合在业务对接过程，当中的一些最佳实践给大家做一些分享。
那第一个实践是一个低门槛的微服务架构转型，都知道在企业的这个业务预就是不断的发展过程当中，很多的企业都会面临一个从单体到微服务架构转型的这样一个难难题，所以但是因为很多的开源的这种微服务的框架，有的时候是很难满足客户这种多样性的或者稳定性的需求。
那通过阿里云sae提供的这种微服务的能力和的一些稳定性的兜底的能力，能快速的帮助企业去完成这样的一个微服务的架构转型，同时还可以让企业尝试一些新的业务创新，那在这个过程当中，希望业务能更加的关注于业务的本身，那这也是sae应用最广泛的一个场景，也是目前主打的一个业务场景。
那第二个最佳实践是想给大家分享的是的一键启停的这样一个方案。那都知道其实开发测试环境和预发布环境生生产环境其实慢已经变成了所有企业的开发环境的一个标配，那很多的情况下都知道开发测试预发布其实是没有必要7×24小时连轴转的运营的，那这个时候如果客户有降本的诉求，他其实是希望做到的是说能不能将这样的三个环境的资源去做一个合理的利用，那通过阿里云sae的这样一键启动的环境，是可以做到一个点是说当是可以灵活的去按需去开通或释放资源，同时能保证保保存了所有环境的这样一个配置。
那当要再次的开启这样的一个环境的时候，通过第定时或者一键的启动，手动的方式就可以把这个环境重新部署上，这样就很好的满足了客户降成本的这样的一个需求，同时也满足了一些提升了这样的一个开发部署的效率，那我在这里可以做一个预告，那未来还会基于k8s底层这样的一个资源编排的能力，会尝试的去编排嗯应用到资源的这样一个依赖和应用与应用的依赖，那未来可能会实现一键的去初始化一套环境，或者是克隆一套环境这样的一个功能，那也请大家跟我一样去期待这样一个功能的实现。
那第三个我想表达的是说的一个全链路的灰度的这样一个解决方案。 那这样的一个解决方案，适用于从slb7成的流量入口的流量到后端的API get位的流量，再到后端的微服务的这样一个流量的灰度，同时还支持多个微服务机联的这样一个灰度。
那一提到灰度，大家其实可能都会想到的一个点是说平时做的这样一个灰度，其实都要起两个命名空间的多个应用，同时还要部署两个完整的环境，一套作为正式的环境，一套都有作为灰度的环境去实现这样的一个灰度方案，那这样一看就很容易是会造成一个硬件的层面上的浪费，同时也会增加一些的运维复杂度。
那基于阿里云sae提供的这样一个全链路的灰度的解决方案，能实现只你只需要一套的部署环境就ok了。然后通过定义去一些灰度的流量规则，通过把特殊的流量去分分配给特殊的实力上，实现一层层的积累下去，去实现这样一套的全链路的灰度。
那这时候就是很多熟悉sz K8s的朋友可能就会有一个疑惑，就这个其实就不就是 k8 s English实现的功能嘛是的没问题，但是我想重点强调一下是说在k8I不仅仅实现了这个 k8s的English的7层调度的能力，同时sae还基于微服务的接口方法级别，实现了这样的一个灰度，那这样的话也是在 sae在在对接各种各样的pass层面上的客户提供的一些场景特性，通过k8s的能力做了一个很好的一个增强。
同时也看到了一个点是说很多的客户是希望sae能作为他的资源弹性资源时去使用，那这里头我想提一个点，就是说目前已经可以通过ecs加上sae的混淆方案去实现这样的一个需求，那是实现的原理大概我可以讲一下，是通过复用客户已有的这样的一个发布系统，通过当客户在发布新的版本的时候，通可以是将保证 ecs的版本和sae的版本的一致性，那通过复用客户自建的这样一个监控系统，把SAR上产生了一些系统的监控数据，通过开放的这种open的API，同步到客户的自建的这个监控系统层面与ecs的一些监控数据去做一个很好的一个整合，那当真的系统流量达到高峰的时候，会第一时间把台弹性的实力谈到sae上，那通过sae弹性的这个效率去满足客户的一些极致弹性的需求。
同时也利用sae提供的资源包和一些按量付费的这样一个模式，去节省客户的一些研发的成本。那这个是我同时也可以通过这个方案，也落地的一些实践是当一些客户他在想通过从sae过渡的sae上面的时候，也做一个迁移方案，中间态的一个过渡方案去使用，那这样的话就可以保证业务在迁移过程当中的一个业务的稳定性，这是看到的一个点。
那最后我也看到了，其实sae是可以满覆几乎覆盖了企业上云的所有场景，那可以看到从前端的这种前端应用到一些小程序，或或者是到一些单体的外部应用或者是微服务，都可以去完成一个service化，那不其实是不需要客户去改各种各样的代码，也不需要改变应用原有的这种部署部署方式，就可以享受到这种 service加k8s加上微服务带来的这种技术红利。
通过一句话来结束我今天的演讲or on service。Simple is the best。 万物皆可思维，类似简单就是最好。
二、实战讲解南瓜电影2使用角度
南瓜电影是如何在7天内将整个平台超过几百台的服务器以及超过30多套系统，能够在7天内迁移到sa上的一个使用的一个经验。
将会从如下三方面给大家来讲当时的现状。
1.是为什么会选择用sae而不是使用其他的比如说k8s这样的一些模式。
2.是如何在7天内能够将整个系统进行落地的，在开之前嗯给大家一分半钟时间看一个小视频，然后来简单介绍一下南瓜电影的一个情况。南瓜电影作为互联网全新商业模式，在国内视频行业中的实践者异军突起，独树一帜，区别于传统视频软件，南瓜电影纯会员制，无任何广告与附加费，用让用户纵享极致纯粹的。
观影体验。在南瓜平台上的每一部电影都会以一种全新的智能算法重新结构，通过数据分析整理给每一位用户，定制专属于自己的影片推荐清单。不仅如此，全新上线的放映厅功能会员等级达到4级，即可建立自己的放映厅，现场远程交互，邀请粉丝亲友一起看大片，凭借影厅热度即可兑换现金。要
将全球最优质的电影资源最好看的故事带给用户。随着精品自制内容的增加，南瓜电影海外版也将面向全球发布，有理由相信南瓜电影将会成为中国文化精品生活的代言人。
这就是南瓜电影的一个简单的情况，南瓜电影是集整个视频的IP制作拍摄以及最终的流媒体，当然当然还有电影院发行各方面的一个业务的一个综合的一个公司，因为是个流媒体的一个公司，所以整个系统平台建设其实跟绝大多数公司做这种业务或者其他业务，其实都会在整体的架构上都会比较类似。
比如说整个系统的整个基础的资源都搭建在ecs然后对外提供了服务，用cdn pcdn这样的一些模式，对于用户提供一个播放的一个优质播放的服务，在上面就会有各种各样的一些数据库，其实用的数据库类型比较多，比如类似于POLO DB这样的一些各种各样数据库，包括mongo，h base，其实在内部都会有使用，在各种应用场景里面，在这整个基础服务之之上，就是一个的整个自研的一些能力中心，整个能力中心，基于整个的算法以及的视频增强能力上面提供各项对用户的服务，包括会员的，包括自适应的码率的，包括整个搜索引擎，包括放映厅各方面服务都基于这样的一个能力平台，然后再通过上面的slb，包括全球调度，以及那个 Wf这样的一些安全接入，然后对于的各种用户提供服务。
整个对外的终端，基本上涵盖了现在市面上全部的终端类型，包括手机的PAD的网页以及各种客户端甚至车载设备，这在的整个平台上都存在。然后跟其他的公司一样，会通过云安全中心对这整个流程上面做各种各样的一些安全管控，包括SL证书的最最基本的，包括云安全中心，包括铁道式攻击的防护，这方面都通过整个云安全中心这个平台搭建的时候，基本上是已经超过了五六年前就开这种方式在进行着。
其次，整个架构出来以后，也知道它一定会面临哪一天会面临一些问题，比如说整个石膏out时间一定会相对比较长，当然这个是相对于传相对于某些特定场景的。
然后第二发板一定会比较相对复杂，因为在互联网公司嘛花800的时间是比较频繁的，像整个后台来说基本上一天两天就会发布，各个系统都会有更新，有补丁包，有各项功能会提供给用户。
然后第三整个发布的时候一定会一不小心可能在某一个调度节点上或者某个系统上可能会容易出错，那这对需要进行回滚，也需要各种各样的一些监控。
3.对于整个运维监控相对来说，因为服务器比较多，各个系统也比较比较多，都是很多业务都必定会存在一些创新的一种可能性，所以人员技能各方面要求都比较多，然后这一些第四，因为用传统的ecs这样的模式，其实整个资源利用率毕竟会会有一些有波峰波谷的时候，特别像流媒体行业，高峰期一般来说都在中午或者是晚上，那剩下的时间都是相对于访问量会低的，而这个时候对于也不可能说在这时候把很多服务去撤出，那自然而然它的整个资源利用率在某些时候就会相对比较低。
因为系统比较多，团队的规模每个人负责嗯内容不一样，所以对整个权限分配这方面都也是其实也是一个非常繁琐的一件事情。这个是从整个架构出来的时候，当时就会都已经知道说一定会存在这些问题，当然开发人员一定会有个惰性，就觉得只要不出色先这样耗着对吧Okay然后在两年多前，然后有一次事件加速了，说这个架构必须要进行调整，包括说用虚拟化也好，用其他各种可能性好，就是说未来业务能够支撑更多的业务，而处罚这个事的一个原因是有一次我早上6点多接到一个开发同学的电话，系统压力特别大，我说不可能，我说早上六七点钟是正常来说业业业绩业务压力相对比较少的，他说不知道，但是流量极其高，然后后面各种业务都开始告警，所以已经启动了紧急的预案，就开始不断的买买买不断的买ecs服务器去扩容各项，去扩容各个系统，然后让系统里面就是说去应对上面的那个业务压力，然后整个时间基本上断断续续的对用户会产生一些影响，很多用户访问不了，然后整个运维时间超过了4个小时，最终把业务完全恢复，当然这4个小时不是不能访问，是断断续续的，用户会有点影响。
同时因为是一个纯会员制的一个视频网站，所以任何用户在平台里面基本上都是会员，都是付费用户，而因为付费用户它的对平台的苛刻程度会更高，所以当天的客服电话从早上忙到晚上，基本上不带用户来投诉说早上不能使用，所以要求赔偿。
所以这也是在一个国内一个纯会员制的平台所必然面临的问题，而这在某些免费的业务里面可能这种压力会比较少。所以因为这件事想到就说，那必须要开始准备对的平台进行一个调整，不然下一次一定会面临同样的问题。
因为每天一天新增80万以上的会员的时候，这整个系统平台也包括一些回流的一些用户，整个日活量是之前历史上同期最高超过了5倍。这只是一个5倍，如果超过10倍，那基本上按照当时的模式，就算买EC s这样的服务，估计也很难快乐快速的去支撑。所以像这种突然袭击，对团队来说是一个比较锻炼团队的事儿，但对公司来说是个损失非常大的事儿。
而那一天基本上测算了一下，当天对所有打开APP的用户全部进行了赔偿，说当天使用全部给用户免费，所以这就是也是对业务层面的一个损失。那当时就想下一步应该怎么改造，当时内部有两个方案，一个是把整个脚本进行一个深度的优化，因为ecs本身也有一种自动扩的一些各种各样的脚本配置，这方面也是一种办法，但是这个一直在使用，然后它的有一些一些问题，这些问题的话其实就是包括它的整个开机各方面，相对来说在应急情况下很难百%满足。
第二，是不是考虑通过k80这样的方式去做自己的容器解决方案然后当然这也面临问题是团队当时没有那么多资源，也没有那么多的经验说去搭建这东西，并且觉得就算搭建了，整个成本各方面也是一个很大的一个付出，那是不是应该考虑这个问题,我当时跟阿里云的同事沟通，我说这是的一个初步的想法，我说阿里云现在内部你们有什么样建议说应该往哪一条路上去走阿里云的一个同事告诉我说，说其实内部还有一个产品是即将发布的，就是说你可以考虑一下，他说我说什么产品，他说我先跟你说一下它能解决什么问题，你再决定说你要你们要自己做容器化，还是说自己购买更多的ecs服务器，还是用这个东西，但是他说这个东西现在有点，因为刚开始嘛总是说在线上业务来说，如果你要大规模使用的时候，是存在一定的风险以及一定的不敢不敢承担的一个压力的。
所以他当时说了几个特性，说有这些特性，说这些特性说完以后说你愿不愿意使用，比如说整个那个因为整个技术站是用纯Java，用斯林波塔这样斯布林克罗这样方式去做，搭建了整个一个平台，所以基本上用we包或者架包这样的方式来做步骤每个程序的，他说首先他支持这两个东西，说无缝的可以去切，基本上对业务层面几乎是0改造。
4.不需要以后买机器，也不需要你去运维那些ecs这些东西。说对对于使用方来说，这些东西从此以后可能就不会再存在了。
第三他说能够自动谈，比如说以刚才说那个案例举例之后，这个东西如果在当时用这种方式的话，它会自动进行扩，如果达到一定问题以后，它对用户来说无影响，这种自自动进行谈，但是我我在开玩笑，我问我问了一个我说如何自动弹，阿里云同志跟我说有钱就只能谈，只要存在的钱它会自动跟你谈他说，你根本对你来说无感知的，你也不用说受到告警，连告警头可能收不到，它会自动跟你谈，如如果说压力释放了以后，它会自动全部收拢。
第三那第四它也提供了一个比较全面的一个监控，然后对你查问题来说可能会更加方便，是方便于你们原来自己建的那套整体的一个监控系统里面的各个数据的一个查询的，他说用他可能能够对这方面有更好的补充。我说这个很不错，我说可以试一下，所以那这个产品就是现在的刚才说那个 sae这个产品，这是当时的一个最最初的印象。而整个而当时我说要做这个方面来说，因为嗯上面那个图就是现在以及之前整个开发流程的一个一个简单的结构图，通过再用的开发，的程序员，的嗯工程师写完代码以后，直接通过get up提交代码。
之后的一个travel，的ci工具会自动进行集成，自动会进行单元测试，自动全部等这方面测试全部通过以后自动会把文件部署到oss内部的o私有化的oss里面，之后自己的监控性，其实这更更内部的话，把它叫做一个监控以及整个部署的一个系统，就是说它会给它进行部署到嗯 ecs那边，然后给他做ecs做个镜像，这是最早之前的一个整个开发流程，而在这里面只需要改造一个地方，就是从原来部署到ecs变成部部署到sae上面，就只要做一个简单的改造，我说既然对开发流程几乎没有任何影响，然后也不需要花费太多的一个资源的时候，那说可以尝试一下，马上进行尝试。
所以当时就选了一个应用，而这个应用是内部也是最最核心的应用，也是压力最大的应用，就是一个API的网关，因为刚才最早结构图里面有各种各样的应用，都会通过API访问到的后端各个系统，而API这是第一道的一个防线。 所以说说把这个系统通过sae上来进行处理，而这而那为什么选这个系统的原因其实很简单，因为首先它有全国各地的部署。
第二它整个那个它本身就大量的ecs集群，如果说用加一个sae的话，对只要做的一个操作就是加入到一个调度系统里面，把部分流量挡到sae，如果假设sae那边出现不稳定的时候，也可以瞬间把流量切回到ecs对用户来说基本上是无影响的，而又能够最大程度的去测试出sae它的对到底是不是用内部这样的一个业务上面。
所以当时就选了这个 API的网关来进行测试，然后整个测试过程中，做了各种各样的一些操作，第一比如说第一错了，通过pts的一个压测，对整个模拟用户进行，线上环境的一个高并发的访问，看看sae在是否会自动的进行谈，以及要测算出如何的一个配置，设置个自动弹性比较好，比如说设设置定时或者是说CPU达到多少，或者memory达到多少，以及或者lps各方面的一些谈了多少去进行谈是比较合理的。
所以通过这方面来进行一个测试，然后拿嗯拿到这个系统比较好的一个数据以后，就开始进行在开通了一些相关的，一个因为 sae上本身就有个完整的监控，而这一点是之前在使用之前还没有考虑到，待会我会详细介绍一下它所带来的一个价值。然后再通过各种各样监控报警设置以后，然后去获得一个实时的一个监控指标，然后计算出s一上初始化容量多大是比较适合的，然后整个弹性时候每次谈多少是这方面比较好，所以这是当时通过这方面来做了一个处理。
然后第三点这两边做好以后还会出现一个问题，就是有时候会倾向一个雪崩效应，而在雪崩效应里面的话，通过sae上本身的一些功能，它能够又可以把这些问题给隔离掉，通过一些限速降流，把部分的用户请求调度到另外一个地方去，或者是通过一个默认的返回，让这些用户能够隔离开正常使用，避免就是说雪崩效应，导致整个系统出现一个崩溃式的反应。
所以这是最早用的一个模式，就通过这些方式，就是说把第一个系统进行这样的一个简单测试后拿到了最好的一个指标。第二方面，因为这一点这个图是最早用s一s一s一石头是没有想到它会能提供这种服务的，因为原来基本上这个完全靠自己对日志的分析，会通过弗林克这样东西对任何日志进行分析来看看，就是说各个接口到底有什么问题，而这一点如果在sae上它本身就已经给提供了这样的一些服务，所以在上面突然看到就是说你可以看到整个请求的链路是怎么样的，到底哪个环节出现问题，比如说是接口的请求，然后还是说后面的数据库的访问，比如说ready的慢或者ready的连接出现问题，或者是说那个 POLO定币这样的一些数据库的一个circle写的有问题在通过这样的一个监控就能清晰的看出来，而这叫而sae本身就提供一个最最简单，就是说开箱机用开箱就默认都打开了，然后还把它打开的就是说那个把这些流量导到阿姆斯里面去，做更多程度的事后分析，而这个是在标准产品都会提供一个支持，然后也是对开发的后续提供一个非常好的去优化的一个可能性。
举个最简单例子，最早自己做的时候，基本上嗯部署完以后系统能跑，然后正常访问正常就基本上就不再过多去关注，或者是因为没有那么多的资源去分析那么多的数据。但通过sae以后，发现很多接口其实优化的可能性很多，比如说SQL的优化，原来这些东西因为服务器特别多，加设到不同的数据库集群以后去做这种的动力也不足，所以的话之前会比较的忽视这个需求。
而通过这种方式以后，通过sae本身的监控以后，发现系统的各种开发效率会提高很多然后会有人给方便开发人员快速定位问题在哪，所以这是一个额外的一个好处。
当然除了刚才那两块以外，因为刚才两块对开发人员是完全没有问题了，但是对企业的管理来说，很多问题还是需要考虑的，比如说一个最基本的就是说审计的问题，因为很多公司一定会面临在国内的上市这方面，而这些东西一定会有个严格的审计上的要求，这些包括权限的管理，事后的一个追溯这些问题，而这个在原来传统sae上面基本上是有个非常成熟的解决方案的，通过堡垒机去分配每一个团队的权限，哪些服务器是属于哪些团队的，它能操作什么，然后密码基本上都是对开发者来说都透明的，而通过sae以后，其实它也可以通过ra m这种方式，对全县进行一个清晰的隔离，就是说那个能够让对应的用负责了，开发者只看到自己的，只能负责自己的那块，避免误操作，影响到其他的产品。
所以 sae上本身提供了一些权限隔离和审批是对，如果说考虑从ecs转移到sae里面，基本上就不用担忧，它本身还是提供足够这样的一个能力来服务的。 以上这些基本上就是说通过API的一个整个升级，基本上有这样的一些指标数据出来，当然这个指标不是说执政的API的，是把整个系统都迁移到sae以后，运行了一个月以后，对整个成本进行了一个成本性能做了一下各种的分析。
补充一下刚才的，整个API的话，从知道这个产品到跟阿里云的沟通以及到整个上线一共是三天时间，然后进行了那个整个部署，然后上线。然后到第五天的时候整个测试结束，然后流量基本上百%打到了sae以上，剩下两天时间把剩下30多个系统也同样的方式快速迁移到sae，所以基本上在7天了以后，ess服务器不再使用了，当时我跟阿里云的同学说，我说我的134同学会不会杀了，说一下子把服务器撤出那么多，他说不会，因为你们下面还是用的，ecs只是说你对来说更透明，然后使用上更方便。 针对整个7天的一个部署完以后，基本上得出了这样的一些结论。首先它的弹性如果配置的通过刚才的不断测试，配置完以后，基本上不用再去考虑，就是说并高峰期它会怎么样，低峰期它会怎么样，它一定会按照你的最优化来进行一个自动的进行调整。
第二个叫免运维，其实所谓的免运维其实说不是说不要运维，其实从的角度来说就是说等你收到告警，然后你打开控制台，登上去去改的那一刹那，其实它本身的修复已经自动完成了，所以它它的整个的一个运维速度会比你人工会更加的一个快捷。
第三发布更快，这里的发布举个最简单的例子，就是说以开发环境举例，传统的开发环境里面的话，你要部署的东西，你首先打个包，然后部署到服务器上去做，而sae上有个最最简单功能，通过ide上的插件，然后开通一下权限，然后你代码build一下以后自动会对应的云上的sae上自动给你部署好，所以它整个测试方便对开发者的一个调试或者测试来说是极其方便的。
所以这就是说随着它的一个发布率极快，当然还有一个叫监控更完善，但它的监控是当然这种监控也可以通过自研去做，但是用它来说基本上就省了一大部分这样的成本。 然后也也会开通SOS这样的方面去做事后的一个追溯之事后的一个分析，然后也通过弗林克来做实时的来配合他来做一些更全面的一个处理。
所以整个那个这个架构来说，对整个开发运维效率基本上提供超过70%以上。然后整个成本是上面写的是4%，其实综合算测算了一下，少一应该是远高40%的。然后针对扩容效率来说，10倍以上指的是相对原来传统ess上购买部署那个镜像，然后出来的时候大概会达到达到10倍以上，这是使用s一上里面的直观的一个改对来说的一个改变。
最后给大家分享一下在这么多用了那么多年的那 sae上，以及在7天的7天之后，包括之后很长时间积累下来以后的一些避坑指南，还有以后以及对阿里云的下一步，我觉得这个产品的一些从角度使用方的角度来说，一些想想法，当然这些碧坑指南现在只是个列表，对当时来说都是一些血泪石，因为每一点其实当时都是踩了一个坑，都踩到过的。
那第一点就是说一定要考虑多可用性部署，就是说如果这里比如说在一个杭州节点上，一定要考虑在一个sae，就一个服务里面设定多个可云区，不要只设定a和b一定要是ABCD越多去多没有错的，因为多的时候避免就是说当可用区出现问题的时候，整个集群出现问题，而这个在上面只要通过一个简单的网卡的配置，基本上后面就不用再去操心了，所以一定要考虑就是说在单节就是说单机房里面的时候考用多可用区这种方式，但如果说多机房的或者多个节点的话，那就另外一回事了。
第二点就是说在发布中可以考虑就是说通过一些灰度或者分批这样的方式去发布，能够避免一些 uh异常情况所影响的，就这些整个发布的话一定要做一个完整的测试，避免就是说发布在发布一刹那出让用部分用户不能使用，比如说发布只设定说登记，就是说一个节点或者两个节点提供服务，而当时业务量可能已经远超这个数字了。
所以如果你一不小心点了这个按钮，就可能会出现人为的出现故障。第三点就是说一定要配置健康检查，这个健康检查就是说就release也好，release也好，这两个健康检查的话可以让你的整个部署中基本上就不用再担忧会有什么风险，因为他会把整个执行完两个健康检查，执行完健康检查以后才会让用户提供服务，避免就开发过程中一个小小的一个写错导致出现问题。
举个最最简单例子，可能把数据库环境配错了也有可能，那这是个比较极端的情况，但是通过这种检查的话，它可以避免出现这种问题。第四点就是说要扩容的法子要经过多，一定要嗯因为每一个业务都是不一样的，每个公司的使用场景也不一样，所以这个只能要多测试。 就说通过跟传统的那种同时负载运行过程中去做一下各种测试以后，才去设定这样的一个法子。
最后就是说一定要建议配置开启一下Sae本身的一些遏制，因为这个功能在现有的提供服务里面默认是关闭的，而把它开启以后会之后出现一些故障之后的一些分析比较重要，因为 sae如果说出现问题，它会自动重启了，自动用新的服务来代替，会把之前儿子给丢，所以通过这种方式可以把这些数据完整的留下来，这是一些避坑的一些原则，而一些期待的话就是说它能够因为现在的话sae只能对单系统进行一个自动扩容，有没有可能就是说以后未来会支持一个全链路扩容，举个例子，服务器不够了它会自动扩，然后提供服务，但是如果下面数据库它监测到可能也会出现问题的时候，如果单纯扩服务器那自然也会出现问题，那如果他有没有可能就是说跟数据库那边联动让数据库那边也开始同时扩容，然后避免用户访问，就是说服务器没有问题，但是数据库出现问题或者是ready出现问题，这样各种可能性，这是一个。
第二就是说提升整个容器出能启动的一个时间，就那个减少这个能启动的时间，让整个部署能够从现在的几秒几十秒变成秒级甚至更低，那这是最好的方式。然后这基本上就完全做到了一个扩容的时候是瞬间的散了。
第三就是说现在的健康检查和应用启动过程有一些耦合，如果说你的健康检查配置的不是那么合理的时候，会发现它整个启动过程极其慢。当然如果说你把前面的配置设的法子比较少，那它这个慢没有影响，但如果你把前面的配置的法子设的比较高的时候，而这个启动就可能会对你的整个业务产生影响。
所以这一点是觉得下一步sae上从使用角度来说，如果能有提升的话，也是一个非常再从使用上会有更加的一个便捷。以上是公司在使用过程的一些简单分享，希望对各位开发者有帮助，如果说自己的公司游戏有考虑用使用这些东西的时候，可以上面的一些必坑原则可以参考一下。
再次非常感谢阿里云在这几年内对这个使用这个产品上的一个大力支持，也给了一些非常多的一些经验，让就是说快速的能够把服务通过它来对用户提供服务。
基本上用通过s一以后的话，对于那种大面积故障到现在为止还没有发生过一次，所以这个非常感谢阿里云以及这个云原生的一个团队。
