那个程序员，被打了。

Posted 2022-09-03 微笑很纯洁

工欲善其事，必先利其器。

1

打起来了...

“微笑哥，研发和运维就快打起来，你赶紧去看看...”

某年一个加班的夜晚，我正坐在公司的一个小角落，戴上耳机开心的敲着代码，突然测试部的女孩跑过来找我。

说研发和测试快要打起来，让我去看看。

那个时候，公司正在全力研发第四代收单平台，采用的是最新微服务架构，当时国内大规模使用的案例并不多。

我们遇到了很多问题，其中就有研发和运维的配合问题，之前运维可能只需要部署十几台应用。

而采用微服务架构后，平台直接膨胀到了100多个应用实例，并且应用和应用的部署还有依赖关系。

上线流程复杂容易出问题，上线出现事故之后职责不清，导致研发和运维的矛盾频发。

而后面的架构升级，导致矛盾进一步升级。

2

架构升级

在使用微服务架构一年以后，为了更高效利用服务器资源，避免因服务器环境不一致导致的相关问题。

我们在架构中，引入了容器技术 Docker。

而这个时期 K8s 也慢慢成熟了，面对海量的容器编排和管理，又将 K8s 引入到架构中。

而 K8s 的引入，也帮我们从底层解决了另外一个问题。

我们使用 Spring Cloud 构建微服务架构，解决了配置中心、服务发现、网关、熔断、负载均衡等架构问题。

这些新技术够一名新手学习好长一段时间，并且确实这些技术和业务无关。

另外，在微服务应用层做通讯、限流、负载等效率并不高，当应用数量足够多的时候，问题还会加剧。

而 K8s，可以从底层帮我们实现这些功能，不但可以提升服务之间的通讯效率，（因为少处理一部分工作）还可以提升开发人员的研发效率。

 K8s 虽好，但却引爆了开发和运维...

3

矛盾升级

此时整个架构就比较完善了，K8s 负责集群管理，Dokcer 负责容器化部署，研发专心在业务开发。

但 K8s 虽然好，却带来了另外一个问题。

就是整个 K8s 的生态太大了，并且每年都还有新的项目不断涌入，来完善整个生态的发展。

我给大家发一张，2022年云原生全景图，大家就应该能够感受出来一二了。

而我们要进行云原生的发布，就不得不持续的了解和学习 K8s，最关键的是研发和运维都得学。

开发人员如果不懂 K8s 没办法开发，运维人员不会 K8s 无法完成应用集群化部署，并且部署到底由谁负责不够清晰。

经历了 N 次矛盾之后，在一个加班的夜晚，又一次上线失败后，运维人员和开发人员甚至打了起来...

怎么办？

问题终究还是要解决，于是我在网上调研了一番，有什么工具可以降低云应用使用门槛，并且能管理应用的全生命周期。

这还真让我给找到了。

4

Orbit

调研了很多国内外工具，大部分仅仅是覆盖了应用生命周期的一部分。

而既想降低云应用使用门槛，又要覆盖应用开发、交付、运维、部署整个周期，完全符合要求甚至超出预期的轻量级工具只有一个。

那就是 Orbit。

Orbit 整体的设计思路是这样的。

在保障资源权限安全的情况下，将应用的运维工作交给研发，负责应用的全生命管理，比如应用的创建、发布和销毁。

这样避免了研发⼈员只能找运维要⽇志，在各个环境通过运维配合查询相关问题信息，导致解决问题链条很长效率极低。

在 Orbit 的设计中，运维⼈员则专注于资源的交付，负责熟悉 k8s 和它的⽣态，以编写模版或者云原⽣⽣态的插件。

研发⼈员通过引⽤这些模版和插件，填上少量和业务相关的参数，就可以完成云原⽣应⽤的改造，适配上云原⽣社区的最新能⼒。

这样有效的分清了研发和运维的职责边界，研发人员也不需要懂 K8s 所有细节，完美的屏蔽了 K8s 的复杂性。

5

不仅仅是这些

当然了，Orbit 的能力不仅仅是这些。

Orbit 应用中心，通过图形化界面操作就可以完成应用的创建、变更，以及多种形式的发布，提高应用交付效率与可靠性。

在应⽤详情⻚中，可以看到这个应⽤由哪些服务、配置、数据表组成。

能看到应⽤距离上⼀次发布已经积累了多少变更，能看到这个应⽤被部署到什么环境中。

如果出现了问题，可以根据使用场景接入不同的运维工具，查看环境页面包含的监控、日志、事件、调用链追踪等信息定位问题。

问题定位后，使用应用中心的应用发布能力，可以快速实现 hotfix 自动化发布。

Orbit 的发布策略，可以轻松实现蓝绿发布、金丝雀发布，甚至支持跨地区跨应用的原子化发布、原子化回滚。

Orbit 应用中心采用了 GitOps 来实践 K8s 的应用发布，这样的好处显而易见。

通过 GitOps 的控制循环结合 K8s 的声明式 API 和终态控制，用户仅需将 K8s 的 yaml 文件提交至代码仓库中。

GitOps 会自动感知到 yaml 文件的变化，配合代码仓库的合并请求功能，将 yaml 文件的变更自动推送至集群中。

整个过程无需开发人员学习 K8s 的发布命令，也无需直接操作集群，大大降低了云原生的使用门槛。

通过以上的介绍，相信大家应该对 Orbit 有了一个整体的认识。

Orbit 不但可以降低云原生的使用门槛，还提供了一整套云应用的创建、交付、监控、部署的能力。

通过 Orbit 这一个平台，完成了云应用的整个生命周期管理。

昨天我刚好参加了 Techo Day 线上活动，而本次活动的产品发布重点就是“轻量化工具”，上文提到的 Orbit 就是这次发布的7个产品之一。

除此以外，还有腾讯首个面向高校教育的仿真开源平台“腾讯数字孪生Tad Sim“、首个面向工业/能源资产洞察的物联网平台”物联网设备洞察IoT Insight“。

以及首个面向个人开发者的轻量化机器学习平台”腾讯云TI平台公有云版本“，确实让我感受到腾讯云在努力降低开发门槛、提升研发效率的满满诚意。

看完发布会能够感受到，腾讯在“轻量化工具”上面投入了很多研发资源，整个发布会满满都是技术男的风格。

互联网使用云原生技术的趋势不可阻挡，而 Orbit 能够从更高的一个维度，帮大家降低使用云原生技术的门槛。

特别是演示监控的那一段感触还蛮深的，可以通过图形界面的方式一键排查Bug，有了这个功能以后排查问题就简单多了。

另外，这次活动还把腾讯整个云原生服务体系的相关轻量化明星产品的技术原理、适用场景等课件内容整理成《腾讯云轻量级工具指南》。

（长按识别即可下载）

点击阅读原文也可以获取，尤其是做云原生开发的程序员，强烈推荐了解下。