购物网站开发的背景,vs做网站教程,个人怎么做公司网站,室内设计学校哪家好发布会传送门
进入直播间还有好礼等你拿#xff01;
EDAS产品免费试用#xff1a;https://www.aliyun.com/activity/middleware/edaspromotiononmay
首届云原生编程挑战赛正式开战#xff01;立即报名瓜分330000现金奖#xff1a;https://tianchi.aliyun.com/specials/p…发布会传送门
进入直播间还有好礼等你拿
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是阿里云平台上的商业化产品而云原生主要由开源社区所倡导两者显然出自泾渭分明的两个阵营那“纯粹”是在掩耳盗铃
其实不然商业化与开源并非水火不容相反在很多领域他们总是相辅相成这个话题并非本文关注的重点若抛开“出身”的因素我们理解的“纯粹”指的是
在原生的体系下对资源进行组合和抽象抽象后的资源也不脱离原生体系不侵入不限制不破坏已有云原生资源的使用约定
得益于K8s的开放性EDAS实现的原理并不复杂用户只需要在K8s配置资源应用通过声明式的配置将其置于期望的状态上EDAS就能感知变更自动维护并调整状态使其最终与用户期望一致从而达到管控应用的目的这一切并不需要修改K8s的版本只需要安装EDAS提供的扩展即可。
下面从两方面来具体介绍EDAS的做法和因之带来的优势。
云原生应用定义
前文提到EDAS将应用抽象成了资源这个过程中应用定义的设计是至关重要的。在声明式的规则下应用定义需要能覆盖软件生命周期过程中每个主体的配置状态和关系的描述并保证良好的可读性因此它必须归纳自大量应用复杂场景和长久维护的经验总结也只有这样才能保证定义不脱离实际能被高效的推演到其他应用上。
EDAS没有重复造轮子选择了“开放应用模型OAM”这一开放标准来作为应用定义并选择与之共建的方式来丰富标准的内容。可以说EDAS是OAM在阿里云上的一个实现。
对于开发者来说EDAS使用OAM提供了两大好处
OAM消除了厂商平台对开发者的绑定虽然不同平台能支持的运维特征以及底层实现方式各部相同但只要厂商都遵循同样的标准同一份应用配置是可以在不同的平台之间进行迁移的。因此对于EDAS上产生的应用是可以被迁移到其他同样遵循OAM规范的平台的针对其他平台迁移EDAS的场景也同理。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: 1name: showName value: helloedasname: description value: traits: name: rollout properties: name: auto value: truename: batches value: 1 name: imagebuilder properties: name: tag value: helloedas-1588854022name: registry value: registry-vpc.ap-northeast-1.aliyuncs.comname: baseImage value: registry-vpc.cn-hangzhou.aliyuncs.com/edas_unified/edas-openjdk:8-1.0name: 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的“血”和“肉”。
不可否认开源社区确实贡献了很多的优秀工具解决了很多的问题但他们的短板也同样存在比如 特定的工具往往设计为解决某个“点”或某条“线”上的问题但解决真实的问题很多是需要多角度协作的在解决这些问题上使用多个工具难度会更高效果也不理想。 在深度使用开源工具后最终问题可能变成工具自身的维护能力问题对运维团队更高要求。
EDAS从开始就摒弃了使用开源工具集合来拼凑功能的路线而是基于经过验证的技术或成熟的云产品从问题出发构建一整套专业的解决方案给用户。这样对常见的问题更具有针对性没有整合和维护的问题。如果开源工具就像瑞士军刀小巧灵活随取随用那EDAS提供的能力更像是数控机床精准高效可规模化。
当然对于开发者而言使用开源工具或EDAS从不是单选题在云原生平台下完全可以通过组合的方式来取长补短形成最合适的方案。
这里没有全量讲解EDAS功能仅列举几个典型的微服务治理的场景。
金丝雀发布
金丝雀发布是比较理想的发布方式可以有效的降低版本发布的风险也被广泛的用于线上系统的运维过程中这里不赘述它的好处对于一次简单的金丝雀发布过程来说只需要在全量部署前先部署金丝雀实例能够在验证新版本验证完发布到全网即可。
但要在生产系统的实现金丝雀发布至少还需要解决几个问题 部署金丝雀实例后需要将特定的请求流量引入金丝雀实例 观测到金丝雀实例的运行状况并与原有实例的运行状况进行对比 当金丝雀发布不符合预期时可回滚整个发布过程
可见“完整”的金丝雀发布所需要的能力并不只是应用托管能力还需要配合可观测性和微服务治理一起协作完成因此单纯用某个工具或者用简单的Deployment可能很难解决这些问题。
EDAS也提供了金丝雀发布功能EDAS的金丝雀发布支持SpringCloud和Dubbo两种开发框架的流量调度用户只需要上传Jar包不需要对应用做任何修改开箱即用。关于EDAS金丝雀发布的使用这里不做详细介绍可以参考这篇文章https://mp.weixin.qq.com/s?__bizMzU4NzU0MDIzOQmid2247489003idx3sna7827438814bec3175743d77e3cb4aabchksmfdeb278bca9cae9dc08912e7b23669b67bb8145f709d155e84f0d6b63fd278df5b954c3b41f9token209782105langzh_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.htmlSDK同OpenAPI支持JavaPythonhttps://help.aliyun.com/document_detail/62123.htmlhttps://help.aliyun.com/document_detail/123354.htmlCLI用命令行的方式使用EDAS功能https://help.aliyun.com/document_detail/104440.htmlMaven Plugin快速将Java代码部署到EDAS上https://help.aliyun.com/document_detail/150674.htmlAlibabaCloudToolkit快速部署代码和端云互联测试等https://help.aliyun.com/document_detail/150670.htmlTerraform Provider快速创建EDAS应用和依赖的资源https://www.terraform.io/docs/providers/alicloud/d/edas_applications.html
开启云原生时代
EDAS努力为开发者提供“更好”的云原生技术一方面致力于让云原生从少数人能玩转的“阳春白雪”变成真正成熟易用的技术释放云原生的价值另一方面通过集成阿里云的各种优势技术来增强云原生下aPaaS平台的能力提供更强大和稳定的应用托管服务。
但如果这些能力需要用户付出高昂的改造成本才能获取那就是南辕北辙了所以使用EDAS必须要比直接使用K8s更为简易EDAS确实也做到了。对于使用常见的Java框架如SpringCloudDubbo开发的应用EDAS都提供了很方便的接入途径多数时候并不需要修改软件或者开发流程即可顺利使用在EDAS创建应用并部署对应的程序包即可对于使用镜像的应用EDAS也可以提供正常的功能支持。
这里举一些例子看看各种不同的应用如何轻松的接入EDAS
如果您已经是EDAS用户了并且有EDAS K8s应用您可以通过点击“升级新版应用管理”仅需要花费几分钟即可得到全新的应用管理能力详细操作可以参见此文档https://help.aliyun.com/document_detail/156823.html。如果您是阿里云容器服务ACK的用户并且有基于Deployment的应用可以选择将集群导入到EDAS后将它们一键转化为EDAS应用这样既能享受EDAS所带来的更丰富的能力同时还能保留原有的Deployment配置信息。如果您尚未使用过K8s或者没有使用过EDAS那可以从容器服务ACK创建一个K8s集群将其导入EDAS直接部署Jar包或者War包即可通过这几个简单步骤开箱即用的就能拥有EDAS的全部功能。
当下云原生已经蔚然成荫未来已来是否使用云原生技术不再是问题。如果您渴望治理软件的纷乱绕杂但对于驾驭云原生没有十足信心对后期的维护成本倍感压力不妨把这些难题都交给EDAS您只需要关注好业务自身轻装上阵快速进入云原生时代。
原文链接 本文为云栖社区原创内容未经允许不得转载。
