程序员经验分享-hwhale

云原生微服务应用的平台工程实践

2023-11-17

作者：纳海

01 微服务应用云原生化

微服务是一个广泛使用的应用架构，而如何使得微服务应用云原生化却是近些年一直在演进的课题。国内外云厂商对云原生概念的诠释大同小异，基本都会遵循 CNCF 基金会的定义：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

弹性可扩展，是企业选择上云的一个重要原因。它可以为企业节省大量成本，同时保障服务稳定性。我们有个电商客户，平时只有 200 多个服务节点，但在大促时轻松扩容到上千个节点。这个扩容动作通过平台一键完成，只需要秒级的时间。操作之简单、时间之短是在上云之前是不可想象的，那些复杂漫长的硬件采购、环境搭建和服务部署流程被自动化完成。

在云原生领域，有一个广泛知晓的 Pets vs Cattle 比喻：在传统运维上，我们习惯把服务器当做“宠物”，这些服务器一旦出现问题我们会非常紧张；而在云原生阶段，服务器更应该被当做“牛群”，它不再具有特殊性，出现问题后可以通过自动化机制进行替换修复。在 Kubernetes 上，这一点尤其体现的淋漓尽致。如果某个 Pod 容器出现问题，那么我们应该能通过 Liveness 探针检测到容器异常，然后完成容器退出，并自动重启容器。

02 云原生浪潮的新问题

云原生浪潮释放了巨大的技术能量，但同时也带来了许多新的问题，这些问题广泛存在于企业的开发、测试、CICD 和运维场景。首当其冲的是 DevOps 实践。

在这里插入图片描述

图片来源于：https://www.atlassian.com/devops

DevOps 理念倡导的是，通过加强研发和运维团队在应用研发声明周期内的沟通合作，和配合自动化工具的使用，提高软件交付的速度和质量。 甚至研发和运维这两个角色往往是由同一个团队承担，达到 “Who Builds，Who Runs” 的境界。

但理想很美好，现实很骨感，DevOps 在很多企业中落地实践逐渐变了样，甚至出现了一些反模式。研发团队承担运维角色之后，需要学习 Kubernetes 编排、容器化、基础设施即代码、GitOps 等云原生运维知识，并负责各个环境的运维。这占用了本来用来实现业务需求的时间，反而降低研发团队的生产力。另外由于生产环境的特殊性，往往会由团队内较为资深的研发人员来承担运维责任，这导致了一个很奇怪的局面：生产力低的员工在写代码，并交给生产力高的员工来运维。

很多人没有意识到这些问题，以为通过 DevOps 减少了运维成本，但实际上付出的隐形成本并不小。这不是危言耸听，有许多研究已经证明了这个问题的存在。例如 Humanitec 曾对使用 DevOps 的组织进行了调查，发现有 44% 的组织存在这种反模式，即开发人员不仅需要完成自己的 DevOps 任务，还需要花费大量的时间承担帮助团队的职责。

在这里插入图片描述

图片来源于：https://humanitec.com/whitepapers/2021-devops-setups-benchmarking-report

问题不在于 DevOps 本身，而是我们是否提供了一个好用的平台和工具链来支持研发团队进行自服务(Self-Service)。这个平台屏蔽了下层复杂的基础设施、各种各样的云原生定义和yaml规范，向研发、测试和安全团队提供简单而清晰的平台交互，以加快上层业务迭代速度和提升产品质量。

如何构建这样的平台和工具链，称为平台工程(Platform Engineering) 。如果说云原生和 DevOps 带来了各种各样的定义，对研发人员是一个熵增的过程，那么平台工程就是屏蔽复杂定义、提供简单清晰交互的熵减工程。

03 平台工程

平台工程概念并非最近才诞生，这个词早在 2011 年已经有人开始使用(见 what-is-platform-engineering [ 1] )，并在 2017 年见之于技术雷达(见 platform-engineering-product-teams [ 2] )。而在云原生技术日益繁杂的今天，容器、编排、服务网格、可观测等各种产品及工具涌现，CNCF 云原生版图已经有超过 1000 个产品，在这种背景下平台工程的诉求愈加强烈。

Gartner 之前发布了 2023 年 10 大技术趋势，其中平台工程占有一席之地：

在这里插入图片描述

图片来自：https://www.gartner.com/en/articles/gartner-top-10-strategic-technology-trends-for-2023

如何实施平台工程呢？这个问题也同样充满了争议。引用一段来自于平台工程社区 [ 3] 的描述：

Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era. Platform engineers provide an integrated product most often referred to as an “Internal Developer Platform” covering the operational necessities of the entire lifecycle of an application.

翻译过来也就是，平台工程是设计和构建工具链和工作流的学科，使软件研发组织能够在云原生时代具备自服务能力。平台工程师提供一个称为“内部开发者平台”（IDP，Interal Developer Platform）的集成产品，涵盖整个应用生命周期的运维需求。

您可能会发现，这个定义和 PaaS（Platform-as-a-Service）的定义相差无几。按照一般的区分，PaaS 是由供应商提供，而 IDP 则是面向内部的平台。但是 IDP 是否等同于自建 PaaS？这个问题并没有标准答案，每个人都可能有自己的看法。

但有一个很明确的点是，企业的确需要这样的平台来解放研发和运维团队的生产力，无论它是 IDP 还是 PaaS。 对于像谷歌、亚马逊和 Netflix 这样的公司来说，他们有足够的规模、资本和人才储备来构建自己的 IDP 平台。而在社区，也存在如 Backstage、KubeVela 等产品来帮助构建内部平台。

问题是，大部分企业是否有足够的人力、时间和成本来完全从 0 构建这样的内部平台？ 在如今越来越卷的竞争环境下，快是制胜之道。更快的迭代可以更快地验证产品功能、市场和进行安全问题修复，如何提高研发团队的生产力一直都是每个企业的核心考虑点。

在平台工程上，谷歌、亚马逊或 Netflix 等公司或许获益颇丰，但同时也有很多公司陷入泥潭。前不久一篇《通用电气在平台工程上浪费 70 亿美元的教训》 [ 4] 的文章介绍了通用电气的平台工程实践，每个人可能从中学到的教训不同，但至少证明了一点：平台工程需要因地制宜的制定策略。

如果你问我广大中小型企业或者传统行业应该如何走向云原生之路、如何利用 DevOps 提升迭代效率，我会谨慎地建议：如果时间对你很重要，那么在找到更好的方案之前，不妨基于主流云厂商的 IaaS 或者 PaaS 来构建自己的产品迭代流程。

在这个领域，主流云厂商基本都有较为成熟的沉淀，大多数能力都是开箱即用。EDAS 很早就进入了微服务和云原生领域，经过了八年左右的迭代，目前具备了如下大体能力：

在这里插入图片描述

由于篇幅所限，上图未完全体现所有平台能力。对于很多企业来说，这些平台特性不是一朝一夕就能实现的。从底层基础设施的统一管理，到核心的应用管控，再到上层的工具链交互入口，每一个层次都需要投入大量的人力和时间进行打磨。

在这几个层次中，研发人员交互最多、却又最容易忽视的莫过于工具链。无论是云产商提供的 PaaS，还是企业自建的 IDP，如果忽略了研发、测试和运维团队最常用的工具，那么这样的平台使用起来是难以得心应手的。我们坚定的认为，只有结合工具链，云的能力才能最大化的交付到一线研发手里。 工具链是连接开发者和 IDP/PaaS 平台的重要粘合剂。

在这里插入图片描述

到目前为止，我们构建了如下三大场景的工具链：

  • 开发场景；
  • 测试场景
  • CI/CD 场景；

这里并不是否定基础设施管理和应用管控的重要性，恰恰相反它们是工具链的基石，缺乏它们一切无从谈起。下文旨在分享开发、测试和 CI/CD 等场景工具链，希望对广大希望采用 PaaS 或者 IDP 的企业有所帮助。

04 开发场景工具链

在开发场景上，我们认为工具链的核心是程序员的 IDE。 在方向上，Cloud IDE 当然是酷炫的，它是一种在线集成开发环境，允许开发人员通过浏览器即可完成开发、测试和应用部署。但实际上国内采用 Cloud IDE 进行开发的企业并不多见，根本原因在于 Cloud IDE 的体验还比不上本地 IDE 的体验。当然在某些场景下 Cloud IDE 可能是唯一方案，例如要求代码不落盘的高密项目。但在综合考虑下，我们还是暂不提供 Cloud IDE 的解决方案。

经过慎重考虑，我们选择通过 IDE 插件来提供平台能力。这种方式可能不那么高大上，但一定是最接地气的，实际上也是研发人员最容易接受的。整体上我们通过 IDE 插件提供了三大能力：开发联调、应用部署和 API 调试。 在使用上，研发人员基本都会优先在本地完成开发联调，联调通过后再进行应用部署和验证，这个效率是最高的。

开发联调

这个能力是我们首先关注的，传统应用进行云原生化改造，如何进行高效开发调试一定是首先需要面对的问题。对此我们提供了本地调试和端云互联两种模式。

  • 本地调试：通过 IDE 一键启动本地 Nacos 注册中心 [ 5] ，完成本地开发调试。对于简单的应用，开发人员在本地就可以通过这个注册中心完成调试，无其他外部依赖，简单且高效。
  • 端云互联：通过 IDE 在本地启动应用，底层通过插件代理自动跟云上网络打通，本地节点跟云上其他微服务节点具备同样的能力，可相互调用。这种方式对于复杂微服务开发调试非常有用，研发人员的调试效率大大提高。

根据实际使用情况来看，这两个能力都备受客户青睐，而端云互联能力更是命中微服务开发调试的痛点。端云互联不仅可以使得应用跟云上互联互通，还把云的能力下沉到研发人员的开发端，比如分布式链路跟踪和全链路流量控制等等。

在这里插入图片描述

此外，我们还支持容器级和进程级流量转发、ECS 和 Kubernetes 多种代理、适配 Windows 和 MacOS 系统等等，感兴趣可查阅 EDAS 端云互联文档 [ 6] ，此处不再展开。

应用部署

我们早在 2018 年就支持通过 IDE 部署应用 [ 7] ，对于开发测试环境来说，通过 IDE 完成构建、上传和部署是很爽的事情。当然我们也支持多种 CI/CD 工具集成（下面会进行展开），CI/CD 流程可以使得代码集成和应用发布更安全，尤其适用于集测和生产等稳态环境中。而在开发测试环境中，首要目的是快速验证代码是否符合预期，如果所有变动都需要先提交，再通过 CI/CD 流程部署，那么这个效率肯定是非常低下的。

通过 IDE 部署后，如何确认部署是否成功？最常用的手段就是终端和日志。这两个操作我们也可以通过 IDE 来一键完成。如果应用日志打到标准输出，那么直接通过 IDE 在目标节点上选择查看日志即可：

在这里插入图片描述

如果日志打到文件、或者需要通过终端登录目标节点，那么只需通过 IDE 双击目标节点，即可完成终端打开：

在这里插入图片描述

更多能力可参考 EDAS 微服务开发侧边栏 [ 8] ，不再展开。

API 调试

我们在 IDE 中集成了云端 API 调试能力，你可以通过 IDE 来快速调试云端应用的接口。这个能力解决了从本地到环境间快速访问通路的问题，这个通路为开发人员节省了宝贵的时间。当出现上下游接口联调问题时，直接通过 IDE 打开 API 调试，现场发起请求测试便一目了然。

在这里插入图片描述

API 调试也集成了分布式链路追踪能力，如果中间链路调用出错，点击界面上的调用链即可一键打开调用链页面，异常信息一清二楚。

05 测试场景工具链

在测试场景，我们优先关注接口级别测试和集成测试。而集成测试本身也是依赖对每一个系统接口的测试，并且对接口响应结果进行断言，最终生成整个系统的质量报告。

因此，接口级别测试是上层业务测试的基础。对此我们开放了接口调试能力，你可以通过我们提供的多种工具插件来完成对云上应用接口的测试，整体链路如下所示：

在这里插入图片描述

例如，安装完 Jmeter 插件 [ 9] 后，你即可通过界面配置接口测试用例，并完成整个系统或模块的集成用例编写：

在这里插入图片描述

EDAS 平台引擎已经处理底层网络的复杂性，你只需要关注上层的业务测试结果即可。在每个工具运行过程中，我们都会打印请求参数、响应日志和链路追踪链接，这样在测试异常时能快速定位问题并改进。

06 CI/CD 场景工具链

CI/CD 即持续集成(Continuous Integration)和持续交付(Continuous Delivery)，《The Product Managers’ Guide to Continuous Delivery and DevOps》 [ 10] 对持续集成、持续交付和持续部署三个概念定义如下：

  • 持续集成： 强调开发人员提交了新代码之后，立刻进行构建和单元测试。根据测试结果来确定新代码和原有代码能否正确地集成在一起。
  • 持续交付： 在持续集成的基础上，将集成后的代码部署到类生产环境，并完成自动化测试，确保可以以可持续的方式快速向客户发布新的更改。如果在类生产环境验证通过后，证明该制品已达到可交付状态，可手工部署至生产环境。
  • 持续部署： 在持续交付的基础上，把部署到生产环境的过程自动化。

CI/CD 领域的产品有 ArgoCD、Jenkins 和云效等开源和商业化产品，这些产品都具备了很高的成熟度。开发者只需要在这些产品的流水线上设置构建、单元测试、集成测试和环境部署等多个流程即可。而在这些流程中，最容易出错、损失最大的莫过于生产环境部署。

根据经验统计，在所有的线上问题中，由于部署变更导致的故障比例相当高。我们非常重视客户应用变更的稳定性，目前支持如下几种发布动作：

  • 单批部署： 一次性把应用中所有节点都更新到新版本。此部署动作常用于开发测试环境，生产环境不建议使用。
  • 分批部署： 按照所设定的批次和间隔来逐步更新应用节点，可以在完成上一批次后，选择手动或自动进行下一批次发布。
  • 金丝雀部署： 在分批部署基础上，将第一批节点设置为金丝雀节点，支持设置金丝雀节点的流量比例、接口参数或者泳道策略，在满足条件的情况下生产流量才会转发到金丝雀节点。比如，如果我们希望只有广东地域的客户端请求才转发到金丝雀节点，那么就可以针对流量中的特征（例如参数中带有 Guangdong 字符）来制定金丝雀流量策略。

目前我们支持 Intellij IDEA、Maven、Jenkins 和云效等多种工具来部署至环境中：

Intellij IDEA

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

Maven

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

Jenkins
https://help.aliyun.com/document_detail/171313.html

云效
https://help.aliyun.com/document_detail/199501.html

例如使用云效实现应用的持续集成和部署，我们只需要将开发好的新版本应用代码提交到代码库，云效流水线 Flow 会监听代码事件，当满足触发事件时会触发流水线运行，部署新版本应用到 EDAS K8s 环境。

在这里插入图片描述

07 总结

事情从来都不是一蹴而就的，搭建平台需要相关领域的专业知识和持续的人力投入才有可能做好。当我们选择构建一个平台时，我们构建的是一个有生命的东西，组织架构变迁和技术的更新换代都会对 IDP 产生影响。构建 IDP 不是一锤子买卖，这些变量在最初就要有充分考虑，否则 IDP 最终会演变成一个烂摊子。在云原生化改造过程中，我们可能会遇到很多新的概念，诸如 Helm、IaC、Terraform、Kubernetes 等等。如果时间和成本对你比较重要，而且团队不是这方面的专家，那么选择一个成熟的 PaaS 平台可能是一个更好的选择。

而如果出于其他原因，希望构建自己的内部平台，那么可以遵循平台工程的五大准则，这样可能会让你更容易朝着正确的方向前进：

  • 明确使命和角色。
  • 像对待产品一样对待你的平台。
  • 关注共同问题。
  • 粘合剂是有价值的。
  • 不要重复造轮子。

除此之外，我们提出一点建议：云原生已经非常复杂，平台工程应当在保留灵活性的同时尽量暴露简单清晰的交互，而非一味增加新的逻辑定义以增加研发团队负担。 EDAS 产品一直遵循着这个设计理念。一方面我们支持松管控，支持你可以用最云原生的方式来灵活运维；另一方面，我们暴露最简单的上层应用模型，屏蔽底层的复杂定义，并将云的能力集成到研发团队最熟悉的工具里，做到润物细无声。

相关链接：

[1] what-is-platform-engineering

https://diff.wikimedia.org/2011/08/17/what-is-platform-engineering/

[2] platform-engineering-product-teams

https://www.thoughtworks.com/radar/techniques/platform-engineering-product-teams

[3] 平台工程社区

https://platformengineering.org/blog/what-is-platform-engineering

[4] 《通用电气在平台工程上浪费 70 亿美元的教训》

https://www.infoq.cn/article/qepvmrlawsw735wwunmb

[5] Nacos 注册中心

https://github.com/alibaba/nacos

[6] EDAS 端云互联文档

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

[7] 通过 IDE 部署应用

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

[8] EDAS 微服务开发侧边栏

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

[9] Jmeter 插件

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

[10] 《The Product Managers’ Guide to Continuous Delivery and DevOps》

https://www.mindtheproduct.com/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)

云原生

微服务

架构

云原生微服务应用的平台工程实践 的相关文章

随机推荐

  • C/C++之宏定义函数

    注意事项 1 将宏定义中的参数和整个宏 用 括起来 2 在宏定义结束的后面 不要加 宏定义只是简单的进行字符串替换 会把 也替换过去 include

  • Spring-1

    struts web层 比较简单 ValueStack值栈 拦截器 hibernate dao层 知识点杂 spring service层 重要 讲多少用多少 gt 了解 spring day01 基础 IoC控制反转 DI依赖注入 整合J

  • 安装完nodejs后在powershell使用node命令报错

    安装完nodejs后 在cmd中可以正常启动node 但是在powershell中出现如下错误 解决方法 鼠标右键点击计算机 打开属性 点击高级系统设置 然后打开环境变量 如下图所示 然后在下面的系统变量点击新建 添加如下图所示变量 然后编

  • 线上服务平均响应时间太长，怎么排查？

    最困难的事情就是认识自己 个人网站 欢迎访问 前言 最近线上环境某个接口服务响应时间偏长 导致用户体验超差 那平时该怎么快速的排查这类问题呢 为代码添加上详细的打印日志 不建议 一是线上环境 没法随便的重新部署更换了详细日志的代码 二是 添

  • 合并数组，升序排列

    public class Demo22 给两个数组 数组A 1 7 9 11 13 15 17 19 数组B 2 4 6 8 10 两个数组合并成数组C 按着升序排序 public static void main String args

  • k-Means——经典聚类算法实验（Matlab实现）

    聚类算法 k Means实验 k 平均 k Means 也被称为k 均值 是一种得到最广泛使用的聚类算法 1 k Means算法以k为参数 把n个对象分为k个簇 使得簇内具有较高的相似度 实验目的 了解常用聚类算法及其优缺点 掌握k Mea

  • 迷你搜索引擎

    这几天在思考如何对项目做出扩展 当一个网站访问量上升之后随之而来的便是用户的大量交流 根据现在主流的交流方式来看 一般都是一个用户先进行发帖 然后其他用户在下面对之评论 评论系统暂且搁置一边不谈 现在有一个问题就是当帖子数量越来越多 如何快

  • vue使用loading加载

    1 效果 1649832674984 2 前言 在vue中提供v loading命令 用于div的loading加载 因为v loading需要绑定一个双向绑定的变量 因此会产生如果页面需要多个loading 则需要很多个变量 在此不必要的

  • 基于Flink+Hudi构建企业万亿级云上实时数据湖教程

    在工作中 我们发现AutoOptimize的优化 在一些场景中可以带来巨大的提升 其中的一些优化可以满足数仓的高性能查询需求 某些时候工程师需要对收集的数据 根据下游的不同场景处理需求 再次进行ETL处理 使得下游使用数据的时候 优化数据的

  • MRI-CEST原理与MRI几种序列

    目录 一 引言 二 核 磁 共振 三 CEST成像 四 弛豫模型 五 几种序列 一 引言 MRI核磁共振的基本原理为核 磁 共振 接下来会具体展开各个词的含义 而CEST成像则是基于Bloch McConnell方程 模拟化学交换的工具 因

  • 曲速未来 发布：区块链技术带来金融服务的信任变革

    区块链安全咨询公司 曲速未来 表示 近年来伴随着新技术的出现 创新资源流动加速 对全球的金融体系也带来了巨大的冲击 作为科技领域极具挑战性的创新之一 区块链 凭借其开放性 自治性 匿名性 不可篡改性等特点 带来了金融的信任变革 重构了传统金

  • conda更新软件包conda upgrade语句

    在虚拟环境中使用upgrade更新语句 例如更新tensorflow conda update tensorflow 要注意几个点 1 可能会更改相关的包的版本 它会检查该虚拟环境下conda环境中的包列表 并尝试更新其他的包来适应版本匹配

  • el-input系列（el-input、el-select等）palceholder 的样式设置

    el input系列所有带有palceholder的 修改palceholder的样式 为了避免样式污染 对placeholder先包一个父类 谷歌浏览器 父类 deep input webkit input placeholder col

  • 高等数学——驻点，拐点，极值点

    一 定义不同 1 极值点 若f a 是函数f x 的极大值或极小值 则a为函数f x 的极值点 极大值点与极小值点统称为极值点 极值点是函数图像的某段子区间内上极大值或者极小值点的横坐标 极值点出现在函数的驻点 导数为0的点 或不可导点处

  • 活体检测的几种手段分析

    人脸识别是判断你是否是你 而活体检测则为了确定人脸识别的你是不是活得你 基于这样的特性 活体检测可以有效的避免视频 图片的技术BUG 活体检测的手段比较多 目前比较通用的是人脸活体检测 但是实际应用中的还有指纹识别 虹膜识别 静脉识别 通过

  • 生成一个6位数的随机密码，且需要包括字符、数字、特殊符号

    实现思路 第一步 6位数的密码 且需要包括字符 数字 特殊符号这三个元素 将三个元素组成6位时每个元素的排列组合列举出来 第二步 从第一步的排列组合中随机抽取一个排列组合类型 i j k 第三步 从所有的字符 数字 特殊符号中随机抽取i个字

  • Zookeeper到底是干嘛的

    在Zookeeper的官网上有这么一句话 ZooKeeper is a centralized service for maintaining configuration information naming providing distr

  • 数据集笔记：杭州 & 上海 地铁客流数据

    数据集地址 PVCGN data at master liuwj2000 PVCGN github com 1 数据集介绍 从5 15到23 30的地铁乘客流量预测 使用前四个时间间隔 15分钟 x 4 60分钟 的地铁乘客流量 进 出流量

  • Python（1）--Python安装目录介绍

    DLLs Python 自己使用的动态库 Doc 自带的 Python 使用说明文档 include 包含共享目录都是 h的文件 Lib 库文件 放自定义模块和包 pip 安装下载的包会放这Lib site packages 这个路径可以修

  • 云原生微服务应用的平台工程实践

    作者 纳海 01 微服务应用云原生化 微服务是一个广泛使用的应用架构 而如何使得微服务应用云原生化却是近些年一直在演进的课题 国内外云厂商对云原生概念的诠释大同小异 基本都会遵循 CNCF 基金会的定义 云原生技术有利于各组织在公有云 私有

热门标签