ECS应用管理最佳实践

前言

即便在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
https://cloudinit.readthedocs.io/en/latest/topics/format.html
https://help.aliyun.com/knowledge_detail/49121.html
启动模板**
https://help.aliyun.com/document_detail/73916.html

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

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

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

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

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

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

ESS
https://www.aliyun.com/product/ess
按量付费
https://help.aliyun.com/knowledge_detail/40653.html

实践3：关于安全

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

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

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

密钥对
https://help.aliyun.com/document_detail/51792.html
安全组
https://help.aliyun.com/document_detail/101348.html

实践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
https://help.aliyun.com/document_detail/62038.html
Cloud Toolkit
https://www.aliyun.com/product/cloudtoolkit

结语

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

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

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

 

原文连接 更多技术干货 请关注阿里云云栖社区微信号 ：yunqiinsight