云原生与业务可观测性

1：什么是云原生？

云原生的概念近几年非常火热，但什么是云原生？什么样的软件算是云原生的软件，什么样的软件不算云原生？很多人都会感觉没有具体的标准和参照物，所以感觉这个名词很虚，看不见摸不着。

为什么会有这种困惑呢？因为，与其说云原生是一门技术，不如说云原生是一套新的理念、新的思想、新的技术方法体系。

2011年，Heroku这个公司根据对上百万应用托管和运维的经验，发布了著名的“十二要素应用宣言”，后来又扩充为15要素。

2013年由Pivotal的Matt Stine根据多年的架构和咨询经验，总结、提炼出了云原生的概念，并被沿用至今。

2015年，谷歌牵头成立CNCF，即云原生计算基金会。

随时间的推移，云原生的概念也不断完善，囊括了DevOps、持续交付、微服务、容器化等主题。

2：容器、DevOps、微服务及持续交付

那么云原生为什么得到大家的认可，为什么具有澎湃的发展动力呢？

我们可以从Pivotal对云原生的定义中做一些分析思考。在Pivotal的云原生定义中包含了4个方面：DevOps、持续交付、微服务、容器。

• 容器技术

首先，我们从容器技术来看：

2013年，dotCloud将Docker开源；2014年，谷歌将K8S开源；很快K8S+Docker就火爆起来，甚至可以称为云原生的事实标准。

Docker通过将进程容器化，实现了软件开发与系统环境的分离，解决了困扰开发人员的跨平台软件移植的问题，而且Docker属于轻量化虚拟化技术，具有启动时间很快、资源利用率高、占用空间小、进程级隔离等优势。

而K8S则实现了容器自动化 大规模编排、管理、部署、启动、回收的能力。

• 微服务

下边再说微服务。

实际上在IT行业，软件架构一直在变革，从单体架构、SOA架构、分布式服务架构、微服务架构。

本质这些变革都在做一件事情：模块化，通过模块化将软件功能解耦，实现高内聚、低耦合，降低软件结构设计难度、软件开发难度、提高迭代效率、降低需求开发周期。

而容器技术的出现，为微服务化提供了利器，极大的推动了SOA架构向微服务架构的发展。通过容器技术，可以将模块以进程级的粒度进行管理，可以弹性扩容，可以快速构建易观测、松耦合、容错性高的系统，从而实现加速创新、降低成本、提高效率。

在传统架构下的软件发布周期以月为单位，而微服务架构下的软件发布周期已经缩短到以天为单位。

• DevOps

微服务的一方面具有开发灵活、部署灵活、可扩展、技术异构、高可靠等优势，但也不可避免的带来一些新的挑战，其中最重要的问题是开发、运维模式。

在原有的开发模式中，设计——开发——测试——运维的界限清晰、分工明确。但微服务粒度越来越小、软件发布周期越来越短，就需要设计、开发、测试、运维能够拉通，适应高内聚的微服务快速开发、快速测试、快速部署的新的组织结构。

由此引出了DevOps，从字面上来理解，是开发人员+运维人员的统称，而实际上，它的核心理念指的是开发、测试、运维的三合一聚合。

DevOps强调的是技术团队，通过自动化工具，进行高效的沟通和协作来完成软件的生命周期管理，从而更快、更频繁的交付。

原来多个大部门间的协助，需要演变为一个一个的“合成作战单元”，比如亚马逊所说的“Two Pizza Team”，2个Pizza可以吃饱的团队能够实现一个微服务的设计、开发、测试和运维。

DevOps即表示的是这种“软件开发（Dev）”和“IT运维（Ops）”之间更紧密沟通、合作的组织结构变革、企业文化变革。

• 持续交付

而持续交付指的是什么呢？这里边包括持续集成、持续交付。

持续集成的基本思想是通过自动化的工具、平台、流程，任何一个开发人员更新的代码随时可以合并或者提交到主干源码仓库中。通过频繁的代码提交、构建、测试加快集成周期和问题反馈速度。

持续交付是指持续的将各类变更，安全、快速、高质量地落实到生产环境或用户手中的能力。持续交付的能力通过自动化流水线的方式实现，减少研发过程中不必要的浪费，缩短整个研发过程中所有需求的交付周期。

2020年2月由阿里开发的健康码为例，可以做到40个小时业务上线、以小时为周期迭代，这就是持续交付的典型例子。

通过以上分析，可以看到云原生概念，并不仅仅指的是技术的发展，更重要的是通过组织结构变革、组织文化变革、流程变革，打破原来的部门壁垒，改变原有的软件架构、软件开发模式、系统交付模式、系统运维模式，从而最大化利用云计算蕴含的原生力量，降低成本，提升效率，提高竞争力，改变世界。

3：为什么需要业务可观测性

为什么我们需要具备可观测性呢？

Google给出的业务可观测性的价值非常简单：“快速排障”。

这个世界上不存在没有bug的系统，而且随着业务系统规模越来越庞大，复杂度越来越高，潜藏的问题和风险也越来越多。

因此，任何一个软件系统的成功，不仅仅要依靠软件架构的合理设计，软件开发的代码质量，更要依靠软件系统的运行维护，而运行维护的基础就是业务可观测性。

银行的交易系统，互联网公司的业务平台，运营商的云化核心网等等运行在云上的各类软件系统，每时每刻均处于一定的运行风险之中。而保证这些系统能够风险可控，稳定运行，需要做的就是能够提前发现异常，快速找到问题源，迅速排除或规避故障。

因此，在CNCF在云原生的定义中，已将可观测性明确列为一项必备要素。

4：什么是业务可观测性

什么是业务可观测性呢？其实就是对一个系统内部状态的测量、观察能力；在有一些领域也叫可维、可测、可控能力。

谈起可观测性的概念，必须要从“三大支柱”这个名词讲起。

2017年，一篇博文总结了可观测性的三大支柱：指标（Metrics）、追踪（Tracing）、日志（Logging），文中将可观测性问题映射到了如何处理指标（metrics）、追踪（tracing）、日志（logging）三类数据上，由此形成了流传很广的业务可观测性三大支柱理论。

那么业务可观测性就可以具体化为：如何定义、获取、分析 Metrics数据、Tracing数据、Logging数据，实现对业务系统的运行状态、异常状况、服务质量的可观测、可发现、可管理的能力。

三大支柱理论出现后的几年间里，这个观点受到了业内的广泛认可，发展为对可观测性能力的基本要求，并且每一个方面都有了众多成熟的解决方案。

例如，开源组件中就有

聚焦于Metrics的Prometheus、Telegraf、InfluxDB、Grafana等；

聚焦于Tracing的Skywalking、OpenTracing等；

聚焦于Logging的Elasticsearch、Kibana等。

构建三大支柱是可观测性能力建设的初级阶段，基于开源组件很容易为每个业务系统搭建一套开箱即用的可观测性设施。