阿里企业级分布式应用服务EDAS
EDAS
- 一个应用托管和微服务管理的云原生PaaS平台
- 提供应用开发、部署、监控、运维等全栈式解决方案
- 用户不再需要自己组建微服务框架并精心维护各个组建。只需要通过租用EDAS的方式，即可马上实施微服务应用开发
EDAS中的微服务核心组件
- 支持 Spring Cloud,Dubbo，HSF 3大主流微服务框架
- 内置Nacos商用版。集成了注册中心，配置中心，负载均衡三大核心组件
- 原生支持Sentinel(AHAS)兼容Hystrix
- Nacos提供服务鉴权功能，同时通过CSB实现微服务网关
EDAS应用托管
- 通过应用托管开发者部署和升级应用时不再需要台登录逐台部署服务器的繁杂操作
- 需要登录EDAS控制台，就可以快速部署应用，并可以和阿里云其他产品无缝结合
EDAS主要功能：应用部署；应用发布；弹性扩容；限流降级；健康检查；应用监控；服务鉴权；应用日志
EDAS主要功能介绍
创建和部署应用
- EDAS支持以容器的形式托管Java应用、PHP应用以及多语言(包含Node.js、Go和Python等多种语言)应用
- JAVA应用支持以JAR (WAR,SAR)包或者容器的形式部署
- 其他语言使用容器进行部署
CI/CD部署应用
CI 持续集成（Continuous Integration）
现代应用开发的目标是让多位开发人员同时处理同一应用的不同功能。但是，如果企业安排在一天内将所有分支源代码合并在一起（称为”合并日”），最终可能造成工作繁琐、耗时，而且需要手动完成。这是因为当一位独立工作的开发人员对应用进行更改时，有可能会与其他开发人员同时进行的更改发生冲突。如果每个开发人员都自定义自己的本地集成开发环境（IDE），而不是让团队就一个基于云的 IDE 达成一致，那么就会让问题更加雪上加霜。
持续集成（CI）可以帮助开发人员更加频繁地（有时甚至每天）将代码更改合并到共享分支或”主干”中。一旦开发人员对应用所做的更改被合并，系统就会通过自动构建应用并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证这些更改，确保这些更改没有对应用造成破坏。这意味着测试内容涵盖了从类和函数到构成整个应用的不同模块。如果自动化测试发现新代码和现有代码之间存在冲突，CI 可以更加轻松地快速修复这些错误。
CD 持续交付（Continuous Delivery） 完成 CI 中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库。为了实现高效的持续交付流程，务必要确保 CI 已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。
在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化。在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中。
CD 持续部署（Continuous Deployment） 对于一个成熟的 CI/CD 管道来说，最后的阶段是持续部署。作为持续交付——自动将生产就绪型构建版本发布到代码存储库——的延伸，持续部署可以自动将应用发布到生产环境。由于在生产之前的管道阶段没有手动门控，因此持续部署在很大程度上都得依赖精心设计的测试自动化。
实际上，持续部署意味着开发人员对应用的更改在编写后的几分钟内就能生效（假设它通过了自动化测试）。这更加便于持续接收和整合用户反馈。总而言之，所有这些 CI/CD 的关联步骤都有助于降低应用的部署风险，因此更便于以小件的方式（而非一次性）发布对应用的更改。不过，由于还需要编写自动化测试以适应 CI/CD 管道中的各种测试和发布阶段，因此前期投资还是会很大。
- 一种通过在应用开发阶段引入自动化来进行频繁交付部署应用的方法
- CI/CD的核心概念是持续集成、持续交付和持续部署
- EDAS目前支持Jenkins和云效两个平台
在混合云中部署应用
EDAS(专业版或铂金版)
- 支持混合云，可以将公共云、本地IDC或及其它云服务提供商的机器通过专线连通，并添加到EDAS公共云的混合云ECS集群中。
- 可通过EDAS控制台统一部署及管理阿里云和本地IDC或及其它云服务提供商的HSF、Dubbo和Spring Cloud等应用。
- 对于阿里云公共云中的ECS实例，EDAS提供弹性伸缩功能。
分批发布模式
- 分批发布按照一定的批次，每次只对应用的一部分实例进行升级的发布过程
- 分批发布过程中如果出现故障，可以终止变更过程并进行回滚，待问题修复后重新发布
灰度发布
又称金丝雀发布，是将应用的旧版本A与新版本B同时部署在环境中，业务请求可能会被路由到版本A的后端上，也可能会被路由到版本B的后端上。您可以自定义灰度发布策略，快速调整版本A和B的流量占比。
灰度发布可以在发布新版本应用时：
- 自定义控制新版本应用流量比重
- 渐进式完成新版本应用的全量上线
- 最大限度地控制新版本发布带来的业务风险，
- 降低故障带来的影响
- 同时支持快速回滚
蓝绿发布
蓝绿发布提供了一种零宕机的部署方式。不停老版本，部署新版本进行测试，确认OK，将流量切到新版本，然后老版本同时也升级到新版本。始终有两个版本同时在线，有问题可以快速切换。
蓝绿部署中，一共有两套系统：一套是正在提供服务系统(也就是上面说的旧版)，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的，并且正在运行的系统，只是系统版本和对外服务情况不同。正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。
蓝绿发布的特点：
在部署应用的过程中，应用始终在线。并且新版本上线过程中，不会修改老版本的任何内容，在部署期间老版本状态不受影响。只要老版本的资源不被删除，可以在任何时间回滚到老版本。 先切分20%的流量到新版本，若表现正常，逐步增加流量占比，继续测试新版本表现。若新版本一直很稳定，那么将所有流量都切分到新版本，并下线老版本。
蓝绿部署要求在升级过程中，同时运行两套程序，对硬件的要求就是日常所需的二倍，比如日常运行时，需要10台服务器支撑业务，那么使用蓝绿部署，你就需要购置二十台服务器。
有了灰度发布之后，为什么还需要蓝绿发布呢？主要有如下几点考虑：
• 应用在生产环境全量发布后，发现故障时回滚时间慢。当线上核心应用存在几十上百的服务实例时，应用实例分批滚动回滚，部分业务应用启动时间需要几分钟，导致整个回滚过程的时间可能超过十分钟，甚至几十分钟。 • 灰度发布期间能发现的问题有限。如数据库慢查问题、死锁问题等，10%流量很难发现，可能只会在100%流量中才容易暴露。 • 灰度发布成功后，仍然需要进行全量发布，在此过程中仍有较多不确定性，如因一些未预料的异常导致发布失败等。
对于上面几个问题，使用蓝绿发布系统都可以较好地解决： • 蓝绿发布期间，流量全部切至新集群时，原稳定集群继续保持在线，若新集群有问题，可通过流量控制秒级切回至原稳定集群，没有应用启动以及其他等待时间。 • 蓝绿发布期间，新集群规模与原稳定集群规模一致，即使是瞬时大流量也没有问题。 • 蓝绿发布期间，新集群承载全站流量，容易验证各种场景，如数据库死锁等并发问题。 • 蓝绿发布新集群验证完成后，已经处于正常服务状态，不会再引入不确定性的变更操作。