1. 首页
    2.  » 
  2. CLOUD
    3.  » 用天文望远镜，观测云原生

用天文望远镜，观测云原生

by | Nov 9, 2021

“2019年是云原生理念和技术普及的元年；

2020年是云原生的全面应用之年；

未来，云原生将成为新常态。”

正如我们无法给出让所有人都满意的“云原生”定义，我们同样无法判断这种说法的正误。但毫无疑问的是，云原生是近几年云计算领域最炙手可热的话题。

从“上云”到“云上”，云原生重塑世界

云计算作为信息产业的全新业态，对社会与经济发展起着重要的促进与推动作用。近年来，国家相继颁布了一系列云计算相关法规与标准，从引导企业上云到推动云上业务应用创新，云计算的技术演变不断加深人们对云原生的价值认知。十年前，软件足以“吞噬”世界；十年间，开源社区、云计算与云原生相继出现，技术在重塑人们价值认知的同时，也在重塑IT运行的规则，重塑世界。

从2008年到2020年，“上云”是大势所趋。意识到云作为可弹性扩缩的基础设施资源后，企业纷纷将业务应用从传统环境迁移至私有云、公有云与混合云环境。

自2013年首次提出“云原生”概念开始，云原生的理念与技术被不断丰富、普及与应用。2015年云原生计算基金委员会（以下简称“CNCF”）的成立，更是建立了云原生技术生态体系，“云上”重塑IT应用、架构等成为潮流。据Gartner预测，到2025年，云原生平台将成为95%以上新数字倡议的基础。

摒弃将传统的IT架构与应用“迁移上云”，将应用的开发方式、架构、部署与维护全部建立在云上，可以最大程度发挥云计算弹性扩缩、动态调整、自动伸缩等技术价值，帮助企业最快地应对市场变化，拥有颠覆传统业务的能力。具体来说：

  • 云原生大幅降低企业的IT开发与运维成本
商业模式决定产品形态，产品形态决定研发模式，研发模式决定采用何种技术，云原生时代，应用（业务）是核心。传统商业模式下业务需求往往比较固定，业务并发量在千级到万级，且允许一定时长的业务停顿。到了互联网时代，业务需求持续发展与变更，业务并发量可以达到百万、千万乃至亿级，在某些行业，业务必须保证连续24小时运转。云原生的微服务、容器、DevOps、持续交付等关键技术可以提高开发、运维与业务之间的协同能力，通过自动化的快速部署、频繁发布、快速交付与反馈，保障业务应用敏捷性的同时，为企业降本增效。

  • 云原生提升企业业务创新效率与产业价值

随着云计算技术的不断发展，传统的IT基础设施被云端资产所取代，云原生成为新的生产力工具在承载海量业务的同时，提升企业的创新效率，创造新的产业价值。云原生区别于早期的虚拟机等，在应用特性与交付架构上进行了重塑，将应用程序代码解耦成独立模块化单元，在实现快速弹性扩容的同时，带来更易拓展的应用。此外，云原生技术的易用性与开放性，从一开始就与开源生态携手，通过不断壮大的应用实例，拓展云原生技术的生态体系，塑造云原生产业生态。

云原生的快速发展，为运维监控带来挑战

2020年CNCF大使Ian Coldwater在Twitter上声称“Kubernetes现已弃用对Docker的支持”，这一事件在造成全球混乱的同时也折射出云原生技术的快速发展所带来一系列问题与挑战，包括技术与产品版本的更新迭代、云原生的存储与安全性，以及对云原生应用的运维管理。

上文提到过，云原生时代，应用（业务）是核心。《CNCF Cloud Native Definition 1.0》中提到云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。当应用真正建构与运行在云原生环境后，运维部门却时常会遇到监控系统显示正常，业务部门反馈“业务系统崩溃”的情况；亦或运维人员已经看到监控系统发出告警，监控系统却无法精准定位故障节点与故障根因。而这些问题背后，总与云原生应用技术有着千丝万缕的关系。

  • 首先，云原生环境，基础设施发生变化：
云原生技术始终处于持续进化阶段。从容器技术的普及，到采用Kubernetes编排容器成为运行容器的默认平台，再到用IaaS、PaaS承载Kubernetes平台，应用变得轻量化；

  • 其次，云原生环境，应用架构发生变化：
传统系统多为单体架构，而云原生环境采用微服务，以独立组件为单位进行部署，应用的架构过渡为松耦合系统，应用间通过RESTFUL API通信，每个应用可以实现独立的部署、更新与重启，应用版本迭代更快，周期也更短；

  • 再次，云原生环境下应用的生命周期发生变化
容器化改变了云原生基础设施，微服务改变了云原生应用架构，DevOps则改变了软件的生命周期。将开发、运维、运营整合于一体，通过自动化的“软件交付”和“架构变更”，使开发、测试、发布与应用软件维护更敏捷、频繁、快速和自动化。

容器、微服务、DevOps等技术在重塑云原生基础设施、应用架构与应用软件生命周期的同时，也不可避免的为监控带来挑战：

  • 规模化的微服务部署对分布式系统要求进一步提升，其动态性与敏捷性造成监控数据收集成本的大幅增加；
  • 容器化造成监控节点成倍扩大，海量的监控数据对数据处理分析能力以及故障快速定位能力提出更高要求；
  • 云原生环境存在大量、可拓展的集群，集群、组件与节点间需要实时、快速、可视化的关联分析与逻辑访问关系梳理能力。
  • ···

传统的监控方式在单体架构下尚能发挥作用，而步入云原生时代，大量的分布式系统、规模化的微服务部署之后，故障可能发生在任意层级，监控所呈现的告警与概况无法进行深入追踪与排查，运维可能需要借助研发的力量去进行剖析。因此，云原生环境下，运维需要具备可观测性能力。

（传统监控能力VS可观测性能力）[1]

最终，还是要回归到去中心化思想，回归到云原生。

我们一再强调，云原生提供的解决方案，是系统不可变基础设施。服务网格（Service mesh）、边车（Sidecar）、服务编排和容器之类的新兴架构模式可以有效地阻止基于云的世界中出现的各类错误实践。

云原生时代，运维须具备可观测性能力

“监控告诉我们系统的哪些部分是工作的。可观测性告诉我们那里为什么不工作了。”

—— Baron SchSchwarz

如果将监控比作显微镜，可观测性能力更像是天文望远镜，它的机体构成更为复杂，从研发到运维，每个团队都需要具备可观测性理念。

主流的可观测性能力基于Logging、Tracing、Metrics三类数据构建：

  • Logging即日志信息，记录处理的离散事件。它展现的是应用运行而产生的信息或者程序在执行任务过程中产生信息，可以详细解释系统的运行状态。此外，日志的存储与查询都会消耗大量的资源；
  • Tracing即处理请求范围内的信息，可以绑定到系统中单个事务对象的生命周期的任何数据。由于面向请求，Tracing可以轻松分析出请求中的异常，但同样会消耗资源；
  • Metrics即可聚合性数据，为一段时间内可度量的数据指标，透过其可以观察系统的状态与趋势，存储空间较小。

（Metrics、Tracing、Logging三者间的关系示意图）[2] 

理想状态下，将Logging、Tracing、Metrics三种数据统一使用，可以构建完整的云原生可观测性运维管理闭环，譬如CNCF推出的Open Telemetry项目：统一Logging、Tracing、Metrics三种数据协议标准，使用一个 Agent 完成所有可观测性数据的采集和传输，适配众多云厂商，兼容CNCF上众多的开源与商业项目···但就目前来看，还未有厂商或开源项目可以统一Open Telemetry后端，三种数据源的统一存储、展示与关联分析仍面临极大挑战。

与云计算发展同频，

天旦保障云原生业务可观测、可扩展

从助力企业“上云”到保障企业业务长在“云上”，天旦始终与云计算技术的发展保持同步；从提供传统的运维监控到打造云原生可观测性运维保障，天旦不断精进技术能力，同用户一道迎接云原生时代的到来。

近日，在北美“KubeCon + CloudNativeCon”峰会上，CNCF宣布天旦（Netis）正式成为CNCF会员，并入选CNCF Landscape 全景图，成为可观测性和分析（Observability and Analysis）领域的推荐厂商。

    （CNCF Landscape全景图-可观测性与分析推荐厂商）

    互联数据技术是天旦产品的技术基石，基于网络数据，天旦通过将Metrics与Tracing相结合，不断增强产品在云原生环境下的可观测性与可扩展性能力。网络数据是应用程序之间通过网络进行传输的独特过程数据，可以提供业务活动、应用性能、安全性与IT基础架构等方面的信息。在云原生环境下仍可以通过多种技术手段，将网络数据复制下来，送至分析服务器进而实现网络、业务、数据库等层面的性能监控与管理。由于网络数据是可聚合性数据，可以透过其观察系统的状态与趋势，因此，通常作为Metrics对云原生应用进行可观测性分析。而天旦独创的SPVD（服务路径视图）可以在云原生环境里自动发现与梳理应用组件之间的逻辑访问关系，并且随着业务应用的弹性扩展自动添加或变更，帮助运维人员构建全链路的可观测性体系，实现单个业务请求全生命周期的观测与分析。

    在云计算技术演进的过程中，天旦逐渐加快性能管理技术的研究脚步，从“迁移上云”时代到“保障云原生应用”时代，为众多用户提供业务可观测性与可扩展性保障。如今，我们将这些行业案例与技术实践集结成册，推出《天旦混合云监控规划指南2021》，助力更多用户迎接云原生时代的来临。

    参考文献：

    [1] 选自《Monitoring in the time of Cloud Native》

    [2] 选自Peter Bourgon，Metrics, tracing, and logging，2017

    关注天旦公众号

    跟旦旦一起，

    让运维稳定无忧，

    运营做你所想。