神结合！一招玩转K8s和微服务治理

‘纯粹‘的云原生

无法否认，EDAS是阿里云平台上的商业化产品，而云原生主要由开源社区所倡导，两者显然出自泾渭分明的两个阵营，那“纯粹”是在掩耳盗铃？

其实不然，商业化与开源并非水火不容，相反在很多领域他们总是相辅相成，这个话题并非本文关注的重点，若抛开“出身”的因素，我们理解的“纯粹”指的是：

1. 在原生的体系下，对资源进行组合和抽象，抽象后的资源也不脱离原生体系

2. 不侵入，不限制，不破坏已有云原生资源的使用约定

得益于K8s的开放性，EDAS实现的原理并不复杂，用户只需要在K8s配置资源（应用），通过声明式的配置将其置于期望的状态上，EDAS就能感知变更，自动维护并调整状态，使其最终与用户期望一致，从而达到管控应用的目的，这一切并不需要修改K8s的版本，只需要安装EDAS提供的扩展即可。

下面从两方面来具体介绍EDAS的做法和因之带来的优势。

云原生应用定义

前文提到，EDAS将应用抽象成了资源，这个过程中，应用定义的设计是至关重要的。在声明式的规则下，应用定义需要能覆盖软件生命周期过程中每个主体的配置，状态和关系的描述，并保证良好的可读性，因此，它必须归纳自大量应用，复杂场景和长久维护的经验总结，也只有这样才能保证定义不脱离实际，能被高效的推演到其他应用上。

EDAS没有重复造轮子，选择了“开放应用模型（OAM）”这一开放标准来作为应用定义，并选择与之共建的方式来丰富标准的内容。可以说，EDAS是OAM在阿里云上的一个实现。

对于开发者来说，EDAS使用OAM提供了两大好处：

1. OAM消除了厂商平台对开发者的绑定，虽然不同平台能支持的运维特征以及底层实现方式各部相同，但只要厂商都遵循同样的标准，同一份应用配置是可以在不同的平台之间进行迁移的。因此对于EDAS上产生的应用，是可以被迁移到其他同样遵循OAM规范的平台的，针对其他平台迁移EDAS的场景也同理。

2. OAM隐藏了特定的底层workload类型，通过更高的抽象层次避免了直接操作底层K8s的复杂性，提供了独立的ApplicationConfiguration资源，通过对Component（组件）配置Trait（运维特征）来施加不同的运维能力，Component和Trait的设计较好的分离了开发和运维团队的关注点，让应用生命周期中的配置和协作工作变得更为简单。

由于ApplicationConfiguration也是K8s自定义资源（CR），所以开发者可以直接使用kubectl工具对其进行增删查改操作，EDAS遵循K8s面向终态的设计原则，最终将应用调整到预期的状态，对开发者来说操作应用与操作常规的Deployment资源并没有差异，也可以非常方便的与其他CI/CD工具或者GitOps工作流相集成。

下面给出了一份EDAS的应用yaml示例片段，通过kubectl apply这样一份配置即可创建一个用指定Jar包部署的EDAS应用：

apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
name: helloedas
namespace: default
spec:
components:
componentName: stateless-component
instanceName: group-1
parameterValues:
traits:
name: tag
value: helloedas-1588854022
name: registry
value: registry-vpc.ap-northeast-1.aliyuncs.com
name: baseImage
value: registry-vpc.cn-hangzhou.aliyuncs.com/edas_unified/edas-openjdk:8-1.0
name: timeout
value: "900"
name: auto
value: "true"
name: batches
value: "1"
name: rollout
properties:
name: imagebuilder
properties:
name: packageVersion
value: '{"buildPackageUrl":"http://demo.oss-cn-hangzhou-internal.aliyuncs.com/prod/demo/SPRING_CLOUD_PROVIDER.jar","showName":"2020-05-07
20:20:18","type":"war","url":"http://demo.oss-cn-hangzhou-internal.aliyuncs.com/prod/demo/SPRING_CLOUD_PROVIDER.jar"}'
name: artifactFormat
value: FatJar
name: softwareComponents
value: '[{"componentId":"5","componentKey":"Open JDK 8","createTime":0,"desc":"Open
JDK 8","downloadUrl":"http://edas-hz.oss-cn-hangzhou.aliyuncs.com/agent/prod/files/jdk-8u65-linux-x64.rpm","expired":false,"id":"5","imageId":"","md5":"1e587aca2514a612b10935813b1cef28","type":"JDK","version":"8"}]'
name: replicas
value: "1"
name: showName
value: helloedas
name: description
value: ""

Deployment编辑

EDAS通过OAM给用户提供了统一的应用模型，而对底层工作负载的管理主要是借助Deployment来完成。

对于无状态应用的管理，Deployment的使用是相当普遍的，它的配置项也颇为丰富。对于习惯了使用Deployment来管理应用的开发者，常常会存在一些相对复杂的配置需求，这里会产生一个矛盾，当特定workload（这里是Deployment）的配置能力超过了OAM模型所定义的运维能力，如何在保留底层自定义配置同时还能维持OAM规范的简洁性和管控的有效性？

纵观软件开发历史，类似的问题并不新鲜，编程语言的发展也是如此，在通用开发领域，高级语言早就替代了机器语言成为开发的主流，因为人的智力是有限的，“抽象”一定是解决复杂问题的利器，这也是前文应用定义产生的重要原因，但对于特殊领域和过渡时期，需要一些“例外”手段来提供足够的灵活性。

因此，尽管用Deployment来直接操作应用存在一些问题，但EDAS并没有“一刀切”的将Deployment的控制权完全收回，而是用“插件式”增强的能力给出了一个答案。

从实现看，EDAS在操作Deployment时默认会通过patch的方式，若需要新建Deployment（比如分批发布），EDAS也会先以之前Deployment为蓝本复制后再进行对应配置调整。因此，只要在配置不冲突的情况下，用户自定义的配置是完全可以继承的，用户可以在EDAS控制台，通过EDAS的API/SDK，或是直接用kubectl工具来修改Deployment，体验上与独立使用Deployment完全一样。

“专业”的云原生

因为“纯粹”云原生，开发者可以以原生的方式去理解和使用EDAS，但仅有这一点是远远不够的，云原生只是一个技术框架，而应用管理则是个更具体的业务命题，aPaaS平台必须要有血有肉，才能完成在应用托管，应用可观测性，微服务治理等诸多领域，全方位解决问题的任务。

EDAS既然帮开发者打开了云原生的大门，下一步自然就是将阿里云和阿里中间件的技术优势融入aPaaS，以专业领域的技术优势来帮开发者更好更省的管理应用，这些才是EDAS的“血”和“肉”。

不可否认，开源社区确实贡献了很多的优秀工具，解决了很多的问题，但他们的短板也同样存在，比如：

• 特定的工具往往设计为解决某个“点”或某条“线”上的问题，但解决真实的问题很多是需要多角度协作的，在解决这些问题上，使用多个工具难度会更高，效果也不理想。

• 在深度使用开源工具后，最终问题可能变成工具自身的维护能力问题，对运维团队更高要求。

EDAS从开始就摒弃了使用开源工具集合来拼凑功能的路线，而是基于经过验证的技术或成熟的云产品，从问题出发，构建一整套专业的解决方案给用户。这样对常见的问题更具有针对性，没有整合和维护的问题。如果开源工具就像瑞士军刀，小巧灵活，随取随用；那EDAS提供的能力更像是数控机床，精准高效，可规模化。

当然，对于开发者而言，使用开源工具或EDAS从不是单选题，在云原生平台下，完全可以通过组合的方式来取长补短，形成最合适的方案。

这里没有全量讲解EDAS功能，仅列举几个典型的微服务治理的场景。

金丝雀发布

金丝雀发布是比较理想的发布方式，可以有效的降低版本发布的风险，也被广泛的用于线上系统的运维过程中，这里不赘述它的好处，对于一次简单的金丝雀发布过程来说，只需要在全量部署前先部署金丝雀实例，能够在验证新版本，验证完发布到全网即可。

但要在生产系统的实现金丝雀发布，至少还需要解决几个问题：

• 部署金丝雀实例后需要将特定的请求流量引入金丝雀实例

• 观测到金丝雀实例的运行状况并与原有实例的运行状况进行对比

• 当金丝雀发布不符合预期时可回滚整个发布过程

可见，“完整”的金丝雀发布所需要的能力并不只是应用托管能力，还需要配合可观测性和微服务治理一起协作完成，因此单纯用某个工具或者用简单的Deployment可能很难解决这些问题。

EDAS也提供了金丝雀发布功能，EDAS的金丝雀发布支持SpringCloud和Dubbo两种开发框架的流量调度，用户只需要上传Jar包，不需要对应用做任何修改，开箱即用。

这里简要列出了EDAS金丝雀发布的重要步骤和参与的组件，可看到一些云产品参与了金丝雀发布的过程，其中ACM用来推送灰度流量规则，ARMS负责采集并呈现监控数据，运行于用户侧的Agent则保证了程序可在用户完全无感知下，按照灰度的规则进行服务注册和数据上报：

日志管理

另一个例子是日志管理，应用日志对线上运维有着非比寻常的意义，日志查询也一直是EDAS使用频度最高的功能之一，对于开发者来说完备的日志管理功能就是刚需，EDAS将日志管理的功能通过“日志中心”提供给开发者来使用，其中：

• 实时日志功能可以让开发者在控制台查看到指定容器在前台产生的输出。

• 日志目录功能可以方便用户收藏应用需要关注的特定日志项，并提供了即席查询指定的日志文件内容，和检索特定模式的功能。

实时日志和日志目录功能主要用于满足常用的即席查询需求，但全面的日志管理功能并不仅仅是查询，还包括汇聚，转储，统计分析，监控告警等很多场景，对于这些需求，阿里云的日志服务（SLS）提供了完善的解决方案，SLS完全可以胜任海量日志数据存储，检索，复杂统计分析，多维度数据可视化等场景；而且与流行的开源日志系统（如EFK）相比，SLS在日志管理的功能丰富度，效率，稳定性，成本等方面也均有过之而无不及。

所以，EDAS与阿里云日志服务（SLS）做了很好的集成，开发者只需要在日志中心配置待采集的日志项，即可将相应的日志转储到SLS，完全免去了配置logtail客户端的操作。EDAS + SLS的组合对开发者来说是一对“黄金搭档”，将应用与数据无缝的衔接起来，带来的不仅是流畅的用户体验，而且是直接将产生的数据服务于数据化运营或智能运维决策的能力，这对产品的带来的价值是不言而喻的。

下图描述了EDAS日志管理功能的设计思路：

开发者工具

软件开发是软件生命周期的重要环节，开发与运维是密不可分的，开发的质量决定了现网故障数量和维护工作的投入，开发的效率影响着版本迭代速度和问题修复速度。EDAS在提升软件开发者维护效率的同时，也同样关注开发者软件在生产阶段的体验，从提升开发体验中获取更高的生产力。

开启云原生时代

EDAS努力为开发者提供“更好”的云原生技术，一方面致力于让云原生从少数人能玩转的“阳春白雪”变成真正成熟易用的技术，释放云原生的价值；另一方面，通过集成阿里云的各种优势技术来增强云原生下aPaaS平台的能力，提供更强大和稳定的应用托管服务。

但如果这些能力需要用户付出高昂的改造成本才能获取，那就是南辕北辙了，所以，使用EDAS必须要比直接使用K8s更为简易，EDAS确实也做到了。对于使用常见的Java框架如SpringCloud，Dubbo开发的应用，EDAS都提供了很方便的接入途径，多数时候并不需要修改软件或者开发流程即可顺利使用，在EDAS创建应用并部署对应的程序包即可；对于使用镜像的应用，EDAS也可以提供正常的功能支持。

这里举一些例子看看各种不同的应用如何轻松的接入EDAS：

1. 如果您已经是EDAS用户了，并且有EDAS K8s应用，您可以通过点击“升级新版应用管理”，仅需要花费几分钟即可得到全新的应用管理能力。

2. 如果您是阿里云容器服务（ACK）的用户，并且有基于Deployment的应用，可以选择将集群导入到EDAS后，将它们一键转化为EDAS应用，这样既能享受EDAS所带来的更丰富的能力，同时还能保留原有的Deployment配置信息。

3. 如果您尚未使用过K8s或者没有使用过EDAS，那可以从容器服务（ACK）创建一个K8s集群，将其导入EDAS，直接部署Jar包或者War包即可，通过这几个简单步骤，开箱即用的就能拥有EDAS的全部功能。

当下云原生已经蔚然成荫，未来已来，是否使用云原生技术不再是问题。如果您渴望治理软件的纷乱绕杂，但对于驾驭云原生没有十足信心，对后期的维护成本倍感压力，不妨把这些难题都交给EDAS，您只需要关注好业务自身，轻装上阵，快速进入云原生时代。

 动动小手指 了解更多详情 ！