乐趣区

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

jiezi

发布会传送门

进入直播间还有好礼等你拿！

EDAS 产品免费试用：https://www.aliyun.com/activity/middleware/edaspromotiononmay

首届云原生编程挑战赛正式开战！立即报名瓜分 330000 现金奖：https://tianchi.aliyun.com/specials/promotion/cloudnative#problem-definition

观看《云原生架构师培训课程》领取新用户折扣：https://yqh.aliyun.com/live/AlibabaCloudNative

云原生的发展速度日新月异，要用好却绝非轻而易举，当开发者开始使用云原生或向云原生架构迁移时，往往会面临一些困境：

  • 第一，云原生对于软件产品存在约束，如必须满足容器化，12 要素等，因此要让一个遗留系统适配云原生体系，不免会需要做一些改造，其中甚至会涉及到开发模式的转变，对部分团队而言，转变的过程可能充满挑战。
  • 第二，K8s 复杂性足以让很多开发者望而却步，而只有对其有较好的掌握才能发挥好云原生带来的优势，否则可能导致系统难以维护，甚至因错误的配置引发故障。而让开发者的技术水平紧跟 K8s 的发展速度，这本身也需要持续投入，这些额外的投入也背离了让开发只关注业务的初衷。
  • 第三，虽然开源社区给云原生贡献了丰富的能力组件，但对于线上业务，尤其是企业级的服务来说，开源组件的性能，可靠性和可维护性能否经得住考验，以及运维团队是否有能力对这些开源组件兜底，这也是在技术选型前所必须做的考虑。

总之，了解云原生和 K8s 只是开始，想要将云原生在业务落地，发挥云原生的价值，选择一条合理的“原生化”路径，才是开发者要关注的核心问题。

阿里巴巴对于云原生的运用起步很早，对于在具有大规模，高可靠和分布式特征的系统上应用云原生技术有丰富经验。EDAS 作为出品自阿里巴巴云原生团队，阿里云上 aPaaS 的旗舰产品，在早期也提供了容器和 K8s 的支持能力。近期随着 EDAS 3.0 版本的重磅发布，更是将云原生融入了 EDAS 的功能核心，致力于帮助业务进行云原生落地，立足云原生平台打造更强大的应用管理能力，释放技术红利，服务广大开发者。

下文将通过一些示例，带领大家一窥究竟，看 EDAS 如何帮开发者“躺着”进入云原生时代，玩转云原生。

“纯粹”的云原生

无法否认，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:

    • 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: “”
traits:

*   name: rollout  
    properties:
    
    *   name: auto  
        value: "true"
    *   name: batches  
        value: "1"
*   name: imagebuilder  
    properties:
    
    *   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"

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 的“血”和“肉”。

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

    1. 特定的工具往往设计为解决某个“点”或某条“线”上的问题，但解决真实的问题很多是需要多角度协作的，在解决这些问题上，使用多个工具难度会更高，效果也不理想。
    1. 在深度使用开源工具后，最终问题可能变成工具自身的维护能力问题，对运维团队更高要求。

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

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

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

金丝雀发布

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

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

    1. 部署金丝雀实例后需要将特定的请求流量引入金丝雀实例
    1. 观测到金丝雀实例的运行状况并与原有实例的运行状况进行对比
    1. 当金丝雀发布不符合预期时可回滚整个发布过程

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

EDAS 也提供了金丝雀发布功能，EDAS 的金丝雀发布支持 SpringCloud 和 Dubbo 两种开发框架的流量调度，用户只需要上传 Jar 包，不需要对应用做任何修改，开箱即用。关于 EDAS 金丝雀发布的使用这里不做详细介绍，可以参考这篇文章
https://mp.weixin.qq.com/s?__biz=MzU4NzU0MDIzOQ==&mid=2247489003&idx=3&sn=a7827438814bec3175743d77e3cb4aab&chksm=fdeb278bca9cae9dc08912e7b23669b67bb8145f709d155e84f0d6b63fd278df5b954c3b41f9&token=209782105&lang=zh_CN#rd

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

日志管理

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

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

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

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

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

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

开发者工具

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

EDAS 提供了丰富的开发者工具集来帮助开发者更高效的完成测试和部署，目前全面支持了 EDAS 云原生应用，工具如下表：

工具

适用场景

参考文档

OpenAPI

使用编程的方式来使用 EDAS 功能

https://help.aliyun.com/document_detail/62038.html

SDK

同 OpenAPI，支持 Java，Python

https://help.aliyun.com/document_detail/62123.htmlhttps://help.aliyun.com/document_detail/123354.html

CLI

用命令行的方式使用 EDAS 功能

https://help.aliyun.com/document_detail/104440.html

Maven Plugin

快速将 Java 代码部署到 EDAS 上

https://help.aliyun.com/document_detail/150674.html

AlibabaCloudToolkit

快速部署代码和端云互联测试等

https://help.aliyun.com/document_detail/150670.html

Terraform Provider

快速创建 EDAS 应用和依赖的资源

https://www.terraform.io/docs/providers/alicloud/d/edas_applications.html

开启云原生时代

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

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

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

  1. 如果您已经是 EDAS 用户了，并且有 EDAS K8s 应用，您可以通过点击“升级新版应用管理”，仅需要花费几分钟即可得到全新的应用管理能力，详细操作可以参见此文档（https://help.aliyun.com/document_detail/156823.html）。
  2. 如果您是阿里云容器服务（ACK）的用户，并且有基于 Deployment 的应用，可以选择将集群导入到 EDAS 后，将它们一键转化为 EDAS 应用，这样既能享受 EDAS 所带来的更丰富的能力，同时还能保留原有的 Deployment 配置信息。
  3. 如果您尚未使用过 K8s 或者没有使用过 EDAS，那可以从容器服务（ACK）创建一个 K8s 集群，将其导入 EDAS，直接部署 Jar 包或者 War 包即可，通过这几个简单步骤，开箱即用的就能拥有 EDAS 的全部功能。

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

退出移动版