前言

即使在CloudNative发展如火如荼的当下，ECS应用（直接将应用部署在ECS上，不使用容器）仍然占了相当大的比重，原因主要在于相对容器化应用，ECS应用由于不需要容器的运行时环境和类似K8S的调度层软件，因此存在一些天然优势，比如：

更低的Overhead，可以更充分发挥硬件的处理能力，适合用于工作负载比较高的组件或应用

更高的单元可靠性，结合高可用方案，可以实现很好的整体可用性更好的安全性，因为隔离在虚拟化层面更易用的运维界面，对运维的技能要求更低对于既存系统，无改造成本当然，对比于容器化的应用，ECS应用的劣势也很明显，因为缺少统一的部署标准和调度系统，需要用户通过脚本或配管工具才能实现自动化管理，而这些附加手段由于本身缺乏标准，如果用户没有良好的运维能力，其本身的功能完整性和可靠性都有可能成为制约业务发展的不利因素。

拿发布应用过程来看，往往会经历资源预备，应用部署和服务上线等操作，对于ECS应用，这些操作基本只能用脚本来进行串联，使用脚本创建用户，使用脚本配置服务，使用脚本挂载磁盘，使用脚本部署，使用脚本配置负载均衡......

脚本胜在高效灵活，且可以满足大部分场景的需求，主要缺点则包括：

易错，对于使用者有较高的意识和技能要求;

缺少上下文信息，需要配合CMDB来使用;需要运行环境，不易被集成;通用性比较差，往往多个组件，多套环境之间的脚本是不可互换的如果用户希望从Devops，弹性伸缩，微服务架构中获取优势，必然会面对更为频繁的资源创建，应用部署，资源销毁动作，这时脚本很容易就会变成系统的阿喀琉斯之踵，需要投入精力去小心翼翼的维护，这就是ECS应用管理中的痛点，我们需要扬长避短。

EDAS如何提供帮助

我们认识到，面对不同的用户和各异的业务场景，寻求一个“万能”架构是极其困难甚至不可能的，所以在多数情况下，业务系统尤其是复杂系统，往往呈现出混合架构的特点；在架构演进过程中，也总会有中间状态存在，对于一个不停发展的系统，中间态就是常态。“混合”并不等于“不良”，只是相比“纯”标准化系统或者CloudNative的系统，混合架构的系统会存在相对较高的管理成本，因为各组件的部署形态和管理模式并不相同。

用户在做架构选择时固然要将运维成本纳入考虑，但业务的适用性永远是更重要的决策依据，用户需要聚焦业务本身，EDAS的任务在于帮助用户降低运维成本，使得架构能更好的适应业务发展，提供更多价值。

为了实现这一目标，EDAS对于资源，应用，服务做了清晰的建模，并在相应的层次内提供了多种适配方案，比如：在资源层，EDAS既允许用户使用K8S，也允许用户直接使用ECS，同时也提供了完全屏蔽掉资源层的Serverless方案；EDAS既可以管理阿里云的ECS主机也可以管理用户自建IDC内的主机；在服务层，EDAS又可以无缝的对接HSF，Dubbo，SpringCloud等多种主流微服务体系，提供诸如调用链跟踪，服务监控，限流降级等多种功能。

相比其他的PAAS平台，用户往往只需要很少的改动就可以将应用托管到EDAS，而且EDAS可以发挥阿里在Java应用和大规模分布式系统领域的深厚积淀，在保证自身处理高效的同时还可以提供给用户更多有价值的信息。

对于ECS应用，EDAS不强制用户做容器化改造，如果用户希望使用ECS，应用适合运行于ECS，那应用就应该使用ECS。而EDAS则会帮助用户消除运维过程中的各种障碍，我们下面会介绍一些优化实践，通过这些大家也许可以发现享受云计算所带来的价值并不需要“纯”的CloudNative架构。

实践1：环境配置标准化

如前文所述，应用管理过程中面临的一大问题就是脚本的脆弱性，包括环境初始化，应用部署，服务上线等各个环节的使用脚本。再进一步分析，当应用被EDAS管理后，部署和服务管控的流程也就随之标准化了，因此这些脚本是会被取代的，但在被EDAS管理之前，环境初始化过程中往往包含了业务特定的配置，如果不使用脚本，怎样将环境信息传递给EDAS，让平台来完成初始化过程？

先来看容器化的应用，它们依靠镜像提供了一个良好的解耦点，因为环境配置是包含在镜像内的，镜像粘合了资源与应用层，用户只需要把镜像配置到EDAS，提供标准化的主机即可以得到一个可供EDAS管理的单元，而镜像是由DockerFile生成，本身是标准化的，可读的且可被版本化的。

同样，ECS应用也可以借鉴这种思路，首先需要一个信息载体来实现标准化的环境初始化过程。我们可以使用cloud-init来实现这样的功能，现在主流的云计算厂商都支持cloud-init，阿里云自然不例外。使用cloud-init，无论是通过DSL或是普通shell，都足以胜任环境初始化的任务。

阿里云更进一步，提供了更强大的信息载体——启动模板，在启动模板中不仅可以定义cloud-init所需的User-Data，还可以填写完整的主机规格，从而实现从0开始生成完整的可供部署的环境，这是使用容器镜像都无法做到的。因此我们推荐用户使用启动模板功能，对于不同的应用分别创建对应的启动模板，EDAS也实现了与启动模板的无缝对接，比如在创建应用，扩容，弹性伸缩等场景下，EDAS都支持用户配置启动模板来作为创建资源蓝本，来提升用户创建资源效率。

谈到环境，用户往往还面临一个相关的问题，即处理共享资源。虽然Shared nothing架构可以提供更好的扩展性和更高的稳定性，但对于一个既存系统，改造可能意味着投入和风险，用户可以通过使用cloud-init在换初始化时完成共享资源配置，比如挂载NAS盘等，这也不失为一种务实的方案。

注意，这里并没有使用时下热门的Infrastructure As Code概念，标准化并不等于IaC，通过标准化可以解决脆弱脚本的问题，但并不苛求纯粹的“代码化”。

cloud-init

启动模板**

实践2：按需取用，按量付费

云计算提供的价值很大部分来源于弹性。通过弹性，云可以将相对固定的资源，动态的分配给相对易变的处理需求，在业务高峰期保证服务质量，在低谷期节省运行成本，这是使用传统手段很难做到的。

弹性即按需取用，不妨拆开来看“按需”和“取用”，什么是“需”？需求是来自业务的，最直接的需求是来自人的决策，除此之外，需求往往还可以通过一些运行指标来反馈，与人的决策相互补充。对于需求，其准确性是非常重要的，如果将系统分为资源，应用和服务层来看，服务层因为最接近业务，所以其指标往往具备更强的参考性。其次，什么是“用”？用的主体自然是应用，用的过程其实就是将资源调配至需求产生的应用的过程，而对于调度，速度则是至关重要的。

EDAS对于ECS资源的调度支持来源于阿里云的ESS服务，创建资源时，支持ECS启动模板功能，对于一个使用典型启动模板的应用，EDAS在2分钟左右即可实现资源和应用的扩容过程。EDAS可参考资源或服务的压力进行弹性触发，用户配置好规则后，完全不需要人工干预。用户也可以通过多可用区分布策略来实现资源在多个可用区间均匀分配，获取更高的可用性。

除了由系统触发的弹性伸缩，用户在人工创建应用或者扩容应用时，同样也可以使用启动模板，而无需切换到ECS控制台操作，指定实例数量后，由EDAS负责驱动ESS和ECS来完成资源的创建过程。

弹性对用户产生的价值离不开按量付费模式，EDAS为用户创建的资源均为按量付费模式（使用启动模板还支持创建抢占式实例），EDAS会为按需创建的主机做上标记，当应用被销毁，或实例被缩容后，资源也将会随之被回收，用户只需要为实例服务期间的用量付费即可；如果用户不希望EDAS彻底释放掉资源，在创建资源时使用“停机回收”策略，在触发资源释放时，EDAS会为用户保留下磁盘数据，在ECS控制台重启主机即可，这样做也只需要用户支付存储所产生的很少部分的费用，避免了相对昂贵的处理资源浪费。

ESS

按量付费

实践3：关于安全

因为云最大化了资源的共享，所以安全也变成了比以往更重要的话题。对比容器化的应用，ECS应用因为少了容器的层次，隔离相对彻底，但关于安全仍然需要注意很多问题，这里提醒两个方面：

在进行主机登录认证时，EDAS推荐用户使用主机密钥对。密钥的复杂程度远高于口令，不存在被枚举的风险，同时非对称密钥的机制也保证了用户不需要将私钥通过任何网络传输给任何目标，原理上不存在传输的泄露可能。因此当用户选择在EDAS创建资源时，使用密钥总是推荐的或者唯一的选择。

而对于主机之间或者主机与云产品之间的访问控制，推荐使用安全组。使用云往往意味着资源的生命周期被缩短，资源就像“细胞”一样，快速产生并被替代，这时基于ID（IP）的访问策略就会显得捉襟见肘，可维护性变差，因此云厂商引入了“角色”来将身份标记与规则配置解耦，这种角色就是安全组。目前，安全组在阿里云已经广泛使用于各个产品，比如用户可以在启动模板中很方便的配置安全组；比如在RDS中，用户可以将需要被控制RDS实例添加到一个安全组，并通过配置此安全组规则，实现控制该实例与其他安全组内资源访问的目的。被EDAS使用的启动模板也要配置安全组，通过这些模板启动的实例会归属于确定的安全组，这与使用阿里云ECS服务来创建资源的要求是一致的，用户也可以通过配置安全组规则来控制这些实例的访问权限。

密钥对

安全组

实践4：开放API

有一个观点：对用户而言，业务逻辑和数据永远是皇冠上的明珠，应用程序和基础设施只是载体。其实除了业务，还有另外一颗明珠，虽不放射夺目光彩但也被用户视若珍宝，那就是流程。

流程的背后是“人”，比如团队组织，知识仓库甚至使用习惯，更特定一些，这些人就是“开发者”。程序可以改变人与机器的边界，机器与机器的边界，人也同样也可以；而且由于人是各异的，以现有的技术还不足以制定出同时让所有人都满意的流程，所以人必然还会要介入流程的制定。

因此对于像EDAS类似的管理平台而言，在维持功能内聚的前提下留给开发者定制的能力是至关重要的。这些能力，EDAS都通过开放API提供出来，用户可以通过使用API来完成控制台相同的功能，将EDAS操作串接起来，编排自身所需要的流程。

EDAS的开放API是阿里云的OpenAPI的一个子集，在OpenAPI的体系下，EDAS不仅有API，还有支持多种开发语言的SDK以及命令行工具CLI，方便开发者选择。同时，EDAS与Alibaba Cloud Toolkit也做了深度整合，在IDE内即可完成EDAS应用的发布等常用功能。

使用开放API并不局限于管理ECS应用，本文不展开介绍，API给了开发者发挥的空间，大家可以通过探索下面的文档获取更多灵感。

API / SDK / CLI

Cloud Toolkit

结语

本文其实侧重于ECS应用的资源管理，不包含服务和应用数据管理的等相关内容，所以并不足以覆盖“应用管理”的全部内容，当然，EDAS的功能也不局限于文中介绍的部分，之所以提炼出这些优化实践，皆因ECS应用在资源管理上的特殊性，而EDAS旨在帮助用户更高效的将合适的技术运用于解决实际问题，保证用户尽可能少的被技术（ECS应用）本身的短板所困扰，同时规避全面架构改造所带来的不可控性。

另一方面，文中推荐的实践都不是EDAS特有的技术，EDAS只是将这些云计算的工具集做了融合，通过平台整合让用户更容易了解并使用，这些工具中既有阿里云提供的，也有来自开源社区的。这样做的好处显而易见：阿里云的专业服务可以保证技术的优势，而开源给了用户不被锁定，平滑迁移的能力，这两者都可以给用户提供独特价值。

在云时代，技术日新月异，理念层出不穷，降低技术的落地成本并保持开放，这是EDAS与用户的共同努力的方向，在云计算的浪潮中避开暗礁和蜃景，与用户一起探究云的本质，攫取更多宝藏，ECS应用管理实践就是其中一个例子。