开发者学习笔记【阿里云云原生助理工程师认证（ACA）课程：微服务和 Serverless 架构-EDAS 主要功能介绍】
课程地址：https://edu.aliyun.com/course/3112075/lesson/19027
微服务和 Serverless 架构-EDAS 主要功能介绍
课程目录
一、创建和部署应用
二、CI/CD部署应用
三、在混合云中部署应用
四、分批发布模式
五、全链路流量控制和灰度发布模式
六、弹性伸缩功能简介
七、限流降级功能介绍
八、EDAS健康检查
九、应用监控功能
十、EDAS应用平台管理
十一、服务鉴权功能介绍
十二、组件中心介绍
十三、日志功能介绍
一、创建和部署应用
首先讲解应用的创建和部署，在EDAS里应用的创建和部署主要分为两大类，一类是基层CS集群的部署，也就是基于云服务器进行部署。
第二类是基于K8s集群的部署，也就是基于容器集群架构的部署。
在EDAS环境中这两种环境的区别主要体现在通过EDAS集群方式进行部署，相对来讲会更简单和直观一点,只需要将ECS加入集群，EDAS平台就会在ECS上安装一个EDAS,也就是一个小的代理应用，通过这个代理应用就可以实现服务的部署。
除了自动安装的EDAS应用服务器在使用上和普通ECS并没有什么区别，而K8s集群的准备要比ECS集群更复杂一点,首先要准备ECS集群，再在ECS集群上创造K8s集群,不过EDAS也支持Serverless与容器服务ASK，开发者可以选择通过ASK，在公共计算资源上创建K8s集群,这种方式的复杂度比自建集群要简单很多。
接下来说明两种部署方式的选择，从微服务框架上来看如果我们使用spring cloud或者Dubbo HSF开发的JAVA型应用,那么我们可以同时选择两种部署方式，那么就是说我们可以在ECS集群中直接部署JAR文件，同时也可以打包成镜像文件,以容器的方式部署，如果我们使用其他的语言开发微服务Go等，或者我们需要一些比较复杂的配置，比如我们用JAVA开发的微服五除了一个大包，还有其他的内容需要一起部署，比如说一些配置文件或资源，依赖的第三方应用等。如果是这种情况就建议用容器的方式进行部署，容器方式的兼容性实际上是最好的,但相对来讲他的应用打包比单一的要相对复杂一点。
这两种部署方式实际上底层都会使用微服务组件和弹性伸缩编排来实现各种功能，所以从功能上所以从功能上讲区别不大,在实际开发中可以根据自己应用的实际情况来进行选择更合适的部署方式。
二、CI/CD 部署应用
EDAS同时支持应用CI/CD平台进行应用的部署，在这里我们先对CI和CD的概念做一个简单的讲解。
CI即持续集成，是指通过自动化的方法快速自动的通过代码生成应用程序，而CD持续交付是指通过自动化的方式快速部署上线应用。为什么要提出这两个概念，前面讲过在现代的微服务开发过程中，由于规模的变小，同时应用迭代的速度也更加的快速,那么应用的生成部署提交频率比传统的瀑布式流程要频繁的太多太多，同时快速地进行集成和部署有助于测试人员能快速地对新开发的功能进行验证。
以及在测试环境中实际运行应用以尽早发现程序中存在的问题，这也是为辅的倡导者所非常推崇的一种方法。和微服务价格一样CI/CD里面对加快应用的迭代速度有着非常多的好处，但是靠传统的人工方式进行交付和提成，效率和准确率上都无法满足需求。
因此为了能在项目中贯彻CI/CD思想，我们就需要自动化持续平台来为我们进行技术支持。而在CI/CD领域比较流行的开源平台，叫Jenkins。同时阿里云也有自己的商业化CI/CD平台云效。相对于开源平台提供了相对更加全面的技术支持，图中以云效平台为例，简单说明了CI/CD开发工具，在整个代码开发周期中的功能，在后面的课程中，会对云效平台做更加深入的讲解。
我们的EDAS平台，现在现在对Jenkins和云效两个平台都有非常好的支持，开发者只需要通过Jenkins或者云效平台提交代码，平台插电就可以自动编译生成应用，并将应用部署到EDAS中，简化了开发者的部署流程。
三、在混合云中部署应用
EDAS开发部署的另一个亮点功能就是混合云部署，所谓混合云的概念是指对于一些大型的企业，或者存在敏感数据的企业他们在上云的时候一般不会把所有的业务全部移动到云服务厂商等平台上，而是会把其中一些重要的核心数据留在自己的服务器上,或者虽然采用了云服务厂商的技术，但是会采用私有云的形式也就是说由云服务厂商为他们专门制定和公有云环境有所区别的单独地云环境，而这种结合了公有云、自建ADC和私有云的复杂应用环境就称为混合云，在这种环境下的部署,如果单靠人工进行多种平台的部署其效率和安全性也是一个重大的风险，那么针对这种情况，EDAS的专业版或者铂金版就推出了混合云部署应用。
具体开讲，不论是自建机房还是私有云，只要通过高速通道产品连接到阿里云平台，实现和阿里云没网的互联互通，并且在服务器上安装了EDAS 那么就可以通过平台向管理平台ECS服务器一样，对这些外部服务器统一进行部署和管理。
对于这些数据敏感企业来讲，实现了安全性和便利性的两全其美，需要注意的是，EDAS的弹性伸缩功能,因为涉及到对ECS资源的调度，所以暂时只能在阿里云功能云的ECS实力上进行应用，这也是一个需要注意的小区别。
四、分批发布模式
EDAS的应用服务发布,应用部署和应用发布的区别在于，应用部署是将应用，复制到对应的运行环境中，而应用发布是将应用实例真正的激活，并使之能对外提供服务,在实际的企业及应用里，应用的发布尤其是升级发布，是一个很容易出现未知风险的环节,因此升级分布通常会采取比较谨慎的方法进行，而不是简单的应用替换。
业界通常采用的发布当时有，蓝绿发布、分批发布、灰度发布等，具体的定义做一个简单的讲解。其中蓝绿发布又称AB发布，其特点是准备两套生产环境，一套为备用当有新版本需要发布时，在备用环境中部署好新版本，然后通过负载均衡将所有流量一次性由旧版本切换到新版本服务器上，这种方式的优点是发布简单，但是缺点也非常明显首先，开发者需要准备比实际多一倍的应用资源，其次新版本一旦有问题，会导致所有用户都受到影响,因此在大规模应用企业中并不十分推荐。
分批发布又称滚动发布，是指在生理过程中并不一下启动所有的新版本，而是将服务器进行分批,先在一批的一台或几台服务器里部署新版本然后将同样数量的旧版本应用下架,等待一段时间新版本服务正常工作以后在更新下一批服务器同时下架旧应用，循环往复的进行。一旦升级中出现问题，迅速回滚到旧版本中，这种发布方式无论是资源消耗还是稳定性比蓝绿发布都有了很大的提升，用户也不再需要准备多一倍的计算资源。
同时新版本中有风险则可以在升级过程中及时发现不至于影响到全部用户,不过这种发布方式的稳定性还是存在一定的问题，一旦开始滚动升级后，用户流量将直接进入新版本中，虽然数量较小但对于迭代速度越来越快和质量控制越来越高的互联网应用还是显得略有不足。
五、全链路流量控制和灰度发布模式
为了近一步将应用发布的风险，也在分批发布的基础上又提出了一种新的发布模式，称为灰度发布，又称为金丝雀发布。金丝雀发布的名称，来源于中世纪的采矿工人发现金丝雀对瓦斯气体非常敏感，因此狂欢，会在下井之前先放一只金丝雀到井里。
如果金丝雀不叫了那就证明井下的瓦斯浓度较高，矿工就会避免下井。金丝雀发布和分批发布的区别在于，金丝雀发布在升级之前会讲新版本的流量近一步调小，通常会从一台服务器负载的5%到10%开始进行测试，如果新版本应用执行稳定，则逐步增加流向新版本的流量，直到达到正常生产环境的流量水平如果这个状态仍然稳定，后面再采取分批发布的方式逐步上限。
如果以采矿工人的例子来讲，分批发布是对于有危险的矿井一队矿工一个一个分批下井避免风险，而金丝雀发布是在矿工分批下井之前先放入一只小小的金丝雀来检测可能遇到的风险，但是分批发布从技术上来讲只需要做好应用的上下限和负载均衡的切换等工作,而金丝雀发布需要对传入的流量实现精确的管控，这就需要应用框架必须提供相应的技术支持,而EDAS提供了全链路流量控制功能，可以根据流量的灰度识别特征讲，流量精确的切换到不同的应用分组中,而这种精确的流量控制技术，就可以很好的帮助开发者实现灰度发布。
全链路流量控制功能，不但可以实现灰度发布还可以实现线上用户诊断功能，当某些用户出现特定问题而难以大规模复现的时候，可以根据该用户的身份特征为他创建灰度流量标识。将该用户的所有请求倒入到链条集群的服务环境中，在链条环境中针对他的问题进行精确的定位和排查，对于提高用户体验降低小概率化等是非常重要的一种技术手段。
六、弹性伸缩功能简介
刚才介绍了应用发布中的一些常用功能，下面介绍另一个非常重要的功能，弹性伸缩。在这之前先介绍一下互联网企业应用的一些场景特点。
首先绝大多数的互联网应用，都存在明显的时间分布不均的情况，也就是一天24小时之内用户的活跃，往往只集中在特定的一部分时间内。而其他的时间用户流量相对较小，比如像游戏应用，通常集中在中午午休、晚上下班到临睡之前的时间。而网课应用一般集中在课程表规定的开课时间内，这就导致了用户的服务器存储在一个明显的冷热不均的情况,如果按照峰值流量去配置计算资源则绝大多数时间服务器都处于闲置状态，造成资源浪费。同时互联网应用还存在着用户流量难以预测的情况。
例如经常社会上出现某些热点情况会导致微博微信等社交平台出现瞬间爆增的流量,而某些直播场景，也很难预测用户实时在线人数。在这些场景下如何保证服务质量的前提下更有效地提高计算资源的利用率，直接影响企业在设施上的投入性价比,而靠传统的人工运维手段，一是享用速度化及时，同时人工运维的成本和风险都会比较高。
基于此种需求业界推出了弹性伸缩的概念，所谓弹性伸缩就是指平台将实时监控服务的运行状态和用户流量,一旦用户流量达到某个预值，或者服务所在的运行环境负担过重计算资源将消耗殆尽，则自动增加服务的实例个数，并调整负载均衡组件，将流量平均分布在全部实例。而当用户流量或服务所在的运行环境资源充足时，则自动下线一部分服务，减少资源的消耗,通过这种无需人工干预的自动运维调整手段，就保证了服务的高并发性能，和性价比之间的双赢。
EDAS平台所包含的弹性伸缩组件，源自阿里巴巴内部的技术实现。历经了历年双11海量流量洪峰的严苛考验，具有多种弹性伸缩扩容配置模式，通过用户界面的配置就可实现全自动扩缩容。
七、限流降级功能介绍
刚才讲解了通过弹性伸缩来应对流量瞬间增大的情况，但是在实际的企业应用开发中单纯的弹性伸缩有时候并不能完全避免过快的流量洪峰，对后端服务的压力,因此除了弹性伸缩外，互联网下的企业应用通常还会引用限流降级组件,为服务提供安全保障。
先简单介绍限流和基本概念，如图左边，一般来讲在服务提供者前面会加入一个限流模块，也就是常说的限流熔断器,当服务的消费者发起请求时，熔断器会检查当前服务提供者的流量压力，如果请求速度过快则限流模块会将服务请求排队,而如果排队时间过长，则后来的请求会被直接返回失败,这样就保证了服务提供者不会被过多的流量压垮，同时服务消费者也不会因为提供者的阻塞而导致长时间的等待这种模式就被称之为限流。而限流可以说是服务实例很重要的安全保障。
再看右边的图，相对于服务提供者前面工作的限流模块，降级模块一般工作在服务消费者一侧降级模块主要负责处理当服务提供者无法正常提供服务的一种情况,无法提供服务包括了被限流，也包括一些其他的情况。比如说无法想到服务，服务异常等。
这种情况下如果直接返回错误可能会导致整个调用链路都因为一个微小的错误而失败，这种情况下对于一些核心功能一般的做法是提供一个备用的降级方案作为替代。
当主方案返回失败时，并不是直接向上级返回失败，而是再次尝试请求备用的降级方案尽量保证非核心业务功能的失败不会对主业务流程产生影响这种模式就是降级，是实现大型系统的重要手段,EDAS原生支持限流降级组件，同时在阿里云上也提供商用版本Ahas，后面会进一步讲解。
八、EDAS 健康检查
健康检查是指由EDAS Agent 针对容器和应用的运行状态定时进行检查，并将结果进行汇总和反馈的过程,简单来说就是EDAS Agent 会定时对应用环境进行两部检查。
首先先检查Ali-Tomcat 是否存活，以便判断整个运行的安全状态，然后再根据用户设定好的健康检查URL 去访问为服务实例，判断微服务实例是否仍然还在运行当中，以便微服务实例出现崩溃或锁死时，用户能及时获得异常信息并进行还原现场Bug 保存运行环境等诊断时操作。
同时健康检查的状态结果也会汇总到EDAS应用管理平台中使开发者对整个集群下的服务状态有一个更直观的了解，总的来说健康检查是一个非常实用的诊断工具。
九、应用监控功能
EDAS中另一个重要的诊断功能就是应用监控功能，在微服务架构中无论是微服务的种类还是微服务的实例其数量都会比单体应用有了极大的增长，同时企业应用运行除了受服务自身的状态，服务所在运行环境的CPU、内存、网络、JVM等指标的影响也离不开其他云上中间件。如数据库、缓存、消息队列等组件以及CDN网络传输、运行解析、客户端嚼文解析等一系列流程，任何一个环节出现问题都会导致应用的享用不及时卡顿或者逻辑错误甚至整个应用不可用。因此对应用整体建造状态的实时监控是应用运维中一个必不可少的日常工作，EDAS集成了阿里云的应用监控系统ARMS 企业，整合了微服务应用、运行环境、阿里云组件、外部资源等各方面的统计数据，可以使用户非常方便的了解到整个系统服务的运行状态。
另外由于分布式系统天生的远程调用特性，其失败概率远远大于单一系统的进程内调用而远程调用又无法将近程调用一样通过调用堆占来显示模块之间的等级关系。因此一旦出现错误开发人员往往难以获得错误的上下关联信息，从而导致排查错误的真正原因变得非常困难。因此ARMS还提供了全链路调用跟踪服务，对于每一次异部调用发者都可以查看服务调用者服务提供者的名称ip 地址以及耗时是否异常调用类型等信息。可以实现如单一调试堆占一般的调用信息查看,具体内容在后面ARMS中会有详细的讲解，这里仅做简单介绍。
十、EDAS 应用平台管理
上面讲解了EDAS的主要功能，包括应用部署、应用发布、弹性扩容、限流降级、应用监控这几部分,下面再介绍EDAS中几个非常实用的应用管理功能。
EDAS在2015年推出的时候拥有一套主子账号管理系统，实现了资源的购买和使用分离，2016年7月份升级以后EDAS开始支持阿里云通用的访问控制RAM账号系统，主要设计思想是通过设置权限策略集中管理用户以及控制用户可以访问哪些资源。例如可以限制用户只拥有对某一个EDAS应用的独权限。以图为例，EDAS内置的权限为子账号分配资源后所有的权限都会匹配这些资源。例如当授权子账号APP1 和APP2的资源后，如果在授予子账号部署应用和停止应用的权利那么该子账号就有权限对APP1和2进行部署和停止。资源力度较为粗糙不能更精细的控制权限。
相比EDAS内置的权限管理，外部的权限控制更为精细。每条权限都可以配置所拥有的资源例如阿里云账号可以授权RAM用户部署APP和停止APP的权限。同时部署APP的权限上资源APP1和2停止的权限上配置资源2和3此时RAM用户可以部署1和2不能部署3，可以停止2和3不能停止1。
十一、服务鉴权功能介绍
当开发者的某个微服务应用有安全性的要求，不希望其他所有应用都能调用的时候，可以对调用该应用的其他应用进行健全，仅允许匹配健全规则的应用调用，保证调用的安全同时基于性能的考虑。EDAS采用分布式健全方式会将健全数据下发到每一个服务提供者所在的运行环境避免单独点健全带来的性能瓶颈和单点风险。
服务健全这个概念相对比较容易理解，需要强调的是如果开发大规模分布式系统建议大家在有条件的情况下尽量采用服务健全的方式进行安全管控。在现代的网络安全管理体系内比较推崇的一种理念是零安全信任理念，所谓零安全信任理念他的核心思想是假定网络环境在已经被攻陷的情况下来设计和开发系统，也就是无论网络位置处在公网还是内网，通信要尽量保证安全。同时对所有的访问采用最小授权原则，这样可以有效的防止恶意的外部攻击和内部服务无意中的破坏行为。
十二、组件中心介绍
接下来看组件中心，使用EDAS一个非常重要的好处就是EDAS本身基于阿里庞大的生态体系而阿里云的生态体系中包含了很多对微服务开发非常有帮助的组件和功能，EDAS的组件中心
甚至将这些功能梳理出来，将微服务开发最为紧密的一些功能集成到EDAS中，免去了开发和运维人员的跨组件维护工作。
这里筛选了四个和微服务开发最为紧密的应用进行讲解,其中CSN涌现，之前已经讲了，它本身可以看作是微服务核心组件中的微服务网关的升级产品，提供了与微服务网关更为强大的协议转换链路集成功能。
关于CSB的功能，在后续高级课程中会有详细讲解,而应用实时监控系统ARMS之前也做了详细的介绍，基本上ARMS也可以算作微服务开发中必不可少的组件之一，具体详情后面讲解,第三个组件是日志模块，这个功能在下一页做详细讲解。
最后一个功能是分布式调用SchedulerX ，之前也提到过，在分布式调用中本身调用的失败率比单体应用高的多，这种情况下对于一些需要同时成功或同时失败的操作,例如银行转账的场景下，扣款方和收款方的账户可能存在不同的微服务之中,这时转账业务就应该做到要么转账成功扣款和加款同时成功，要么失败扣款和加款同时失败，这种操作就叫做同步受损操作。
在分布式条件下的同步试用操作实际上涉及到了比较复杂的数学问题业界也提出了各种各样的理论，例如CAP 原则，应用开发者如果想自己开发一套综合考虑各种情况的分布式同步事务组件，实际上难度是非常大的,因此遇到需要事物型操作的时候一般建议选用比较成熟的分布式事务框架，以便在实际情况中出现各种复杂情况。
十三、日志功能介绍
最后讲解一下日志服务，阿里云的日志服务SLS是一个单独的应用，而EDAS组件中心同SLS做了比较完善的结合，在应用开发中断点调试和日志输出是两种最常见的问题诊断手段,而在生产系统中断点调试难度很大，因此对于生产环境的系统内部流程的监控就需要通过应用中的日志输出进行完成。
相对于ARMS更侧重于应用模块外部环境的监控，日志是应用模块内部模块的重要监视手段,开发者使用日志系统时只需要配置微服务相应的日志输出目录SLS就可以将所有微服务实例的日志以及EDAS本身的系统日志整合到一起，便于开发者在统一的平台中进行管理，而在SLS日志平台中不但可以查看过往的日志，还可以设置多种条件的日志搜索。
