随着云计算的发展和普及，云原生概念的热度也越来越高，到底什么是云原生？和我们日常工作有什么关系？本文是向大家介绍云原生技术的概念和要点，帮助大家快速了解和学习云原生，，便于大家了解工作的定位，为各系统迭代优化提供方向和思路。

---

01. 什么是云原生

云原生是一种软件开发方法，它充分利用了云计算，使用开源软件技术栈将应用程序部署为微服务。通常，云原生应用程序构建为在Docker容器中运行的一组微服务，在Kubernetes中编排，并使用DevOps和Git Ops工作流进行管理和部署。使用Docker容器的优点是能够将执行所需的所有软件及环境配置打包到一个可执行包中。容器在虚拟化环境中运行，从而将包含的应用程序与其环境隔离。

——维基百科“Cloud Native”

Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念；2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12因素、微服务、自敏捷架构、基于API协作、扛脆弱性；到了2017年，Matt Stine在接受InfoQ采访时又改了口风，将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质；而Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器

2015年云原生计算基金会（CNCF）成立，CNCF掺和进来后，最初把云原生定义为包括：容器化封装+自动化管理+面向微服务；到了2018年，CNCF又更新了云原生的定义，把服务网格(Service Mesh)和声明式API给加了进来。

总而言之，符合云原生架构的应用程序应该是：采用开源堆栈（K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。

企业IT架构经历了单体架构、分布式架构和云计算架构3个阶段的技术演进。

企业应用上云，也经历了从云托管到云原生的架构演进过程。

上云初始阶段，多数企业仅仅是把应用从传统的IDC机房搬迁到云上的虚拟机，这是云托管模式，或者叫作基础设施即服务（Infrastructure as a Service，IaaS）上云。

云原生阶段，从架构设计、开发方式到部署维护的整个软件生命周期管理，都要基于云的特点进行重构，从而构建“原生为云”而设计的应用，这样才能在云上以最优的架构、最佳的模式运行，并充分利用和发挥云平台的弹性以及分布式优势。

---

02. 云原生设计原则

1．去中心化原则：

微服务化，去掉SOA的企业服务总线（ESB），仅保留服务注册中心；

2．松耦合原则：

实现的松耦合、时间的松耦合、位置的松耦合、版本的松耦合；

3．面向失败设计原则：

容错处理、高可用性、无单点故障；

4．无状态化原则：

具有可扩展性、自动弹性伸缩；

5．不变性原则：

容器化、自动化安装部署；

6．自动化驱动原则：

DevOps、CI、CD、自动化测试、全方位监控。

---

03. 云原生应用十二要素

一个优雅的互联网应用，在设计过程中，需要遵循的一些基本原则和云原生有异曲同工之处。十二要素由Heroku创始人Adam Wiggins首次提出并开源，由众多经验丰富的开发者共同完善。这综合了他们关于SaaS应用几乎所有的经验和智慧，是开发此类应用的理想实践标准和方法论指导。

1．基准代码，一份基准代码（codebase），多份部署（deploy）

在类似于SVN等集中式版本控制系统中，“基准代码”是指控制系统中的代码仓库；而在Git等分布式版本控制系统中，“基准代码”则是指最上游的代码仓库。

2．依赖，显式声明依赖关系（dependency）

十二要素规则下的应用程序不会隐式依赖系统级的类库，它一定通过“依赖清单”确切地声明所有依赖项。此外，在运行过程中，通过“依赖隔离”工具来确保程序不会调用系统中存在但清单中未声明的依赖项。这一做法会统一应用到生产环境和开发环境中，比如通过合适的工具（Maven、Bundler、NPM），应用可以很清晰地对部署环境公开和隔离依赖，而不是模糊地对部署环境产生依赖。无论用什么工具，依赖声明和依赖隔离都必须一起使用，否则无法满足十二要素原则。

3．配置，在环境中存储配置

通常，应用的配置在不同部署环境（预发布环境、生产环境、开发环境等）会有很大差异，这其中包括如下内容。

（1）数据库、Memcached，以及其他后端服务的配置。

（2）第三方服务的证书。

（3）每份部署特有的配置，如域名以及所依赖的外部服务地址等。

有些应用在代码中使用常量保存配置，这与十二要素所要求的代码和配置严格分离显然大相径庭。配置文件在各部署间存在巨大差异，代码却完全一致。判断一个应用是否正确地将配置排除在代码之外，一个简单的方法是看该应用的基准代码是否可以立刻开源，而不用担心会暴露任何敏感的信息。

十二要素推荐将应用的配置存储于环境变量（env vars、env）中。

在云环境中，无论是统一的配置中心，还是分布式的配置中心，都有很好的实践方式，比如Nacos通过命名空间实现不同环境的配置隔离，以及Docker的环境变量使用。

在十二要素应用中，环境变量的粒度要足够小，且相对独立。

4．后端服务，把后端服务（backing service）当作附加资源

后端服务是指程序运行所需的通过网络调用的各种服务，如数据库、消息队列、简单邮件传输协议（Simple Mail Transfer Protocal，SMTP）邮件服务，以及缓存等。

十二要素应用不会区别对待本地或第三方服务。

每个不同的后端服务是一份资源。

部署可以按需加载或卸载资源。

5．构建、发布、运行，严格分离构建和运行

将基准代码转化为一份部署（非开发环境）需要经过以下3个阶段。

（1）构建阶段：是指将代码仓库转化为可执行包的过程。构建时会使用指定版本的代码，获取和打包依赖项，编译成二进制文件和资源文件。

（2）发布阶段：会将构建的结果和当前部署所需配置相结合，并能够立刻在运行环境中投入使用。

（3）运行阶段（或者说“运行时”）：是指针对选定的发布版本，在执行环境中启动一系列应用程序进程。

十二要素应用严格区分构建、发布、运行3个阶段。举例来说，直接修改处于运行状态的代码是非常不可取的做法，因为这些修改很难再同步回构建阶段。

每一个发布版本必须对应一个唯一的发布ID，例如可以使用发布时的时间戳（2011-04- 06-20:32:17）或是一个自增的数字（v100）。发布的版本就像一本只能追加的账本，一旦发布就不可修改，任何的变动都应该产生一个新的发布版本。

新的代码在部署之前，需要开发人员触发构建操作。

6．进程，以一个或多个无状态进程运行应用

在运行环境中，应用程序通常是以一个和多个进程运行的。十二要素应用的进程必须无状态且无共享。任何需要持久化的数据都要存储在“后端服务”内，如数据库。所有的应用在设计时就被认为随时随地会失败，面向失败而设计，因此进程可能会被随时拉起或消失，特别是在弹性扩缩容阶段。

黏性session是十二要素极力反对的，session中的数据应该保存在诸如Memcached或Redis等带有过期时间的缓存中。

7．端口绑定，通过端口绑定（port binding）来提供服务

互联网应用有时会运行于服务器的容器之中。例如PHP经常作为Apache httpd的一个模块来运行，正如Java运行于Tomcat中。十二要素应用完全自我加载，不依赖任何网络服务器即可创建一个面向网络的服务。互联网应用通过端口绑定来提供服务，并监听发送至该端口的请求。

在容器应用中，应用统一通过暴露端口来提供服务，尽量避免通过本地文件或进程来通信，每种服务通过服务发现来路由调用。

8．并发，通过进程模型进行扩展，以支持并发

在十二要素应用中，进程是“一等公民”。十二要素应用的进程主要借鉴于Unix守护进程模型。开发人员可以运用这个模型去设计应用架构，将不同的工作分配给不同的进程类型。

9．易处理，快速启动和优雅终止可使健壮性最大化

十二要素应用的进程是易处理的（disposable），即它们可以瞬间开启或停止。这有利于快速、弹性地伸缩应用，迅速部署变化的代码或配置，稳健地部署应用。

进程应当追求最短启动时间。

一旦接收终止信号（即SIGTERM），进程就会优雅地终止。

就网络进程而言，优雅终止是指停止监听服务的端口，即拒绝所有新的请求，并继续执行当前已接收的请求，然后退出。

对worker进程来说，优雅终止是指将当前任务退回队列，有锁机制的系统则需要确定释放了系统资源。

进程还应当在面对突然死亡时保持健壮，例如底层硬件故障。

10．环境等价，尽可能地保持开发环境、预发布环境和线上环境相同

从以往经验来看，开发环境和线上环境之间存在着很大差异，主要表现在以下3个方面。

（1）时间差异：开发人员正在编写的代码可能需要几天、几周，甚至几个月才会上线。

（2）人员差异：开发人员编写代码，运维人员部署代码。

（3）工具差异：开发环境或许使用Nginx、SQLite、Windows，而线上环境使用Apache、MySQL以及Linux。

十二要素应用想要做到持续部署，就必须缩小本地与线上差异，对应上面所述的3个方面如下。

（1）缩小时间差异：开发人员可以在几小时，甚至几分钟内就部署代码。

（2）缩小人员差异：开发人员不仅要编写代码，还应该密切参与部署过程以及关注代码在线上的表现。

（3）缩小工具差异：尽量保证开发环境与线上环境的一致性。

在容器化应用中，通过运行Dockerfile文件构建的环境能做到版本化，因此可保证各个不同环境的差异性，同时能大大减少环境不同带来的排错等沟通成本问题。

11．日志，把日志当作事件流

日志使应用程序运行的动作变得透明。在基于服务器的环境中，日志通常被写在硬盘的一个文件里，但这只是一种输出格式。日志应该是事件流的汇总，将所有运行中进程和后端服务的输出流按照时间顺序收集起来。尽管在回溯问题时可能需要看很多行，但日志最原始的格式确实是一个事件占一行。日志没有确定开始和结束，但随着应用在运行会持续增加。

十二要素应用本身从来不考虑存储自己的输出流，不应该试图去写或者管理日志文件。相反，每一个运行的进程都会直接地标准输出（stdout）事件流。在开发环境中，开发人员可以通过这些数据流实时地在终端看到应用的活动。

在预发布或线上部署中，每个进程的输出流由运行环境截获，并将其与其他输出流整理在一起，然后一并发送给一个或多个最终的处理程序，用于查看或长期存档。对应用来说，这些存档路径不可见也不可配置，而是完全交给程序的运行环境管理。

日志是系统运行状态的部分体现，无论是系统诊断、业务追踪，还是后续大数据的分析处理服务。Docker提供标准的日志服务，用户可以根据需求进行自定义的插件开发来处理日志。

12．管理进程，后台管理任务当作一次性进程运行

进程构成（process formation）是指用来处理应用的常规业务（比如处理Web请求）的一组进程。与此不同，开发人员经常希望执行一些管理或维护应用的一次性任务，举例如下。（1）运行数据移植。（2）运行一个控制台（也被称为REPL shell）来执行一些代码，或针对线上数据库做一些健康检查或安全巡检。（3）运行一些提交到代码仓库的一次性脚本。

云原生十二要素进阶

在十二要素发布之后，就职于Pivotal公司的Kevin Hoffman出版了Beyond theTwelve-Factor App一书，书中不仅对原十二要素进行了更加详细的阐述，还增加了三个新要素，具体如下。

1.优先考虑API设计（API first）

在云原生应用中，系统之间的跨进程调用是不可避免的，因此对于开发者而言，设计出合理的、具有高兼容性的交互API是首要任务。

API如同契约，一旦生效，就应该尽可能少地被改动。

每次对API 进行改动都需要做到向后兼容，并为每次改动提供唯一的版本号。应尽量避免废止原有的API，以及修改原有API中已经存在的属性，而应该通过增量的方式增加新的功能。

2.通过遥测感知系统状态（Telemetry）

对于部署在云环境上的应用，其系统环境是封闭且隔离的，在出现状况时不应该登录有问题的物理服务器去观察和收集应用的状态，云原生应用需要通过遥测来感知应用以及服务器本身的状况，暴露尽量多的监测信息为运维工程师或云调度系统提供判断和处理问题的依据，应用本身则需要提供包括 APM 信息、健康检查、系统日志在内的采集数据。

3.认证和授权（Authentication and Authorization）

虽然十二要素中并没有提到安全问题，但在云环境中，安全是至关重要的。将安全问题完全抛给云平台是很危险的，因此建议采用OAuth2认证和RBAC授权等比较完善的安全机制。

---

04. 云原生计算基金会

CNCF(Cloud Native ComputingFoundation，CNCF）由Google于2015年7月发起成立，隶属于Linux基金会。其目标愿景是“致力于使云原生计算具有普遍性和可持续性，维护和集成云原生开源技术，围绕一系列高质量项目建立社区，支持容器化编排的微服务架构应用”。

其职责范围是促进云原生标准制定，促进生态系统的发展和演变，管理项目，推进云原生社区发展。CNCF自成立开始，便得到业界的广泛关注，众多世界知名云厂商以及相关云生态公司参与其中，短短几年，CNCF会员（白金会员、金牌会员、银牌会员）就达到四五百家（国内的阿里云、华为云、京东相继成为CNCF的白金会员）。

CNCF生态蓝图

从2016年11月开始，CNCF开始维护了一个名为Cloud Native Landscape的生态蓝图（读者可在GitHub官网搜索“Cloud Native Landscape”查看），汇总目前比较流行的云原生产品及其技术，并加以分类，希望能为企业构建云原生体系提供参考。

CNCF把目前所涉及的云原生相关的产品、技术和生态分为8个主要的领域及方向，具体如下。

1．云基础设施（cloud）按云的部署位置可以分为公有云和专有云（私有云）。

2．环境部署（provisioning）有了物理机和虚拟机，在运行容器服务之前，我们还需要为容器准备标准化的基础环境，如自动化部署工具、容器镜像工具、安全工具等，以支持基础设施的运维自动化。IaaS层提供了硬件网络基础，环境部署提供了软件工具底座，二者共同支撑了容器运行平台的地基。

3．运行时（runtime）运行时是容器核心的云原生技术，为容器运行提供虚拟化隔离的运行支撑环境，包括虚拟化的计算资源、虚拟化的存储资源、虚拟化的网络环境。

4．编排和管理（orchestration & management）当在生产环境中使用容器时，单台主机上的容器已经不能满足需求，因而需要管理多主机容器集群，也就需要有一个工具能够提供资源管理、容器调度和服务发现等功能，保证多主机容器能够正常工作。可以说，对于云原生系统，容器编排调度才是核心。Kubernetes 是世界上最受欢迎的容器编排平台和第一个 CNCF 项目。

5．应用层（App definition and development）容器平台最终还是要运行应用的，最主要的应用当然是各个公司的业务，除此之外还有一些比较通用的行业应用，可以根据需求提供类似于应用市场的功能。应用层提供的技术及产品，既包括涉及跟应用开发相关的基础产品（如数据库、消息队列、缓存、流计算等），也包括跟应用开发相关的软件过程管理（如代码库、镜像库、DevOps）。技术是为业务服务的，应用仍旧是所有应用系统的最终目的。

6．平台服务（platform）平台服务是指基于容器技术的更上一层的封装，对开发人员、运维人员提供更加友好的、便捷的、基于容器的应用开发能力，让容器作为一种基础设施服务开箱即用——容器即服务（Container as a Service，CaaS）。随着Kubernetes的快速发展，很多以Kubernetes为容器管理平台和应用管理的公司应运而生，大幅降低了用户使用Kubernetes管理容器的门槛。容器关心的是应用，那么Serverless关心的则是函数，由此也催生出一些新的应用开发模式，如函数即服务开发模式（Functions as a Service，FaaS）、后端即服务开发模式（Backend as a Service，BaaS）、小程序开发模式等。

7．监控分析（observability & analysis）监控系统的运行健康，以确保业务的稳定可靠，是运维工作的主要内容。基于云原生的应用平台建立起来之后，我们要保证整个平台能够正常工作，保证运行在其上的服务不会因为平台错误而不可用，而且还要知道应用整体的运行情况，提前对某些可能出错的地方进行预警，一旦出错能够提供合适的信息进行调试和修复等，这都是监控（observability）和分析（analysis）要做的工作。监控分析包括运行监控（主机监控、容器监控、应用监控）、分布式日志（日志采集、实时流计算、日志分析）、分布式追踪（全链路追踪、架构感知）等应用领域。

8．合作伙伴（special）一个生态的良性发展一定少不了众多领域的参与者及合作伙伴。CNCF成立短短几年时间，得到国际知名云厂商以及众多软件服务商的支持和参与。截至2019年，CNCF会员（白金会员、金牌会员、银牌会员）已将近500家。

CNCF路线图

为了帮助企业推动云原生应用的落地，从而更好地适应环境与业务的发展，CNCF给出了云原生应用路线图——Trail Map（参考CNCF在GitHub官网的Landscape页面），以便在应用上云过程中为用户提供指导建议。路线图分成10个步骤来实施，每个步骤都涉及用户或平台开发者将云原生技术在实际环境中落地时需要循序渐进思考和处理的问题，企业在不同的步骤可以结合Landscape中列出的产品或服务进行选择。

（1）容器化。容器化是云原生的第一步，如果不对应用程序进行容器化，就无法实现云原生。

（2）CI/CD。设置CI/CD环境，从而使源代码上的任意修改都能够自动通过容器进行编译、测试，并被部署到预生产环境，甚至生产环境中，部署过程中如果有任何异常，可以方便快速地回滚到上一个稳定的版本。

（3）应用编排。容器编排主要是管理容器的生命周期，尤其是在大规模复杂的生产环境中，软件团队使用容器编排来控制和自动化许多任务。

（4）监控和分析。在这个步骤中，用户需要为平台选择监控、日志以及跟踪的相关工具。例如，将Prometheus用于监控、Fluentd用于日志、Jaeger用于整个应用调用链的追踪。

（5）微服务及服务网格。容器技术激发了微服务及服务网格的快速发展，微服务是云原生架构下应用之间交互的主要方式。服务网格，顾名思义就是连接服务、发现服务、健康检查、路由，并用于监控来自互联网的入口。服务网格通常还具有更复杂的操作要求，如灰度发布、限流降级、访问控制和端到端身份验证。Istio 提供了对整个服务网格的行为洞察和操作控制，提供了完整的解决方案以满足微服务应用程序的各种需求。CoreDNS 是一种快速灵活的工具，可用于发现服务。Envoy 和 Linkerd 都提供服务的健康检查、请求路由和负载均衡等功能，以支持服务网格体系结构。

（6）网络及策略。云原生架构下启用更灵活的网络层非常重要。要启用更灵活的网络，要使用符合容器网络接口（Container Network Interface，CNI）的网络项目，如 Calico、Flannel以及Weave Net等软件用于提供更灵活的网络功能。Open Policy Agent（OPA）是一种通用策略引擎，其使用范围包括从授权和准入控制到数据过滤等。

（7）分布式数据库和存储。实现持久层的分布式，根据其实现方案分为分布式数据库中间件与分布式数据库两种形式，其目标都是为了实现数据库持久层的弹性和伸缩能力。分布式数据库中间件本身不是一个数据库，而是数据库之上的一层分布式代理，如阿里巴巴的分布式关系型数据库服务（Distributed Relational DatabaseService，DRDS）以及开源的Vitess、Mycat。分布式数据库本身提供了分布式的能力，不会出现单机数据库中可能会出现的单机资源性能的瓶颈。如阿里巴巴的PolarDB数据库产品。

（8）流和消息处理。当应用需要比JSON-REST这个模式更高的性能时，可以考虑使用gRPC或者NATS。gRPC是一个通用的远程过程调用（Remote ProcedureCall，RPC）框架（类似各种框架中的RPC调用），NATS是一个发布、订阅和负载均衡的消息队列系统。

（9）容器镜像库和运行环境。可以使用Harbor作为镜像私库进行存储以及对镜像的内容进行扫描。容器并非只有Docker一种，容器的运行环境更是如此，可以选择不同的容器运行环境，但需要注意选择具有OCI兼容性的方案，比如containerd或cri-o。

（10）软件分发。最后可以借助Notary等软件用于软件的安全发布。Notary实现了更新框架（The Update Framework，TUF）；TUF提供了一个框架（一组库、文件格式和使用程序），可用于保护新的和现有的软件更新系统。

---

05. 微服务治理

微服务治理的好坏决定了企业实施分布式微服务架构的成败。总体来说，微服务治理包括服务目录、服务路由、服务管控、服务监控4个部分的内容。服务治理的手段是从不同角度来确保服务调用的成功率。

1．服务目录

服务注册发现：服务治理领域最重要的问题就是服务发现与注册。绝大部分微服务框架中引入了一个服务注册中心的概念，服务的注册与发现主要依赖这个服务注册中心。

健康检查：服务注册中心还需实时监听所有服务节点的健康状态，以及节点的上下线消息，及时更新推送服务地址信息。

服务配置：服务配置中心统一管理所有服务的路由规则，如黑白名单机制、同机房优先、服务权重等。

2．服务路由

服务路由规则：根据配置中心配置的路由规则进行服务的路由指向，既可以在调用方本地路由，也可以由专门的组件（如负载均衡）进行路由处理。

灰度发布：服务路由必须支持灰度发布（金丝雀发布）的能力，将灰度流量路由到专门的灰度环境服务上。

服务负载均衡：对集群的服务调用进行负载均衡分发，确保集群内所有服务节点的流量分摊；负载均衡既可以在调用方本地处理，也可以由单独的负载均衡组件处理。

服务容错：服务调用并不总是一定成功的，可能的原因包括服务提供者节点自身死机、进程异常退出或者服务消费者与提供者之间的网络出现故障等。对于服务调用失败的情况，需要有手段自动恢复，来确保调用成功。

优雅上下线：确保服务上下线过程中对业务不造成任何影响，满足业务7×24小时不间断运行的要求。

3．服务管控

服务隔离：提供不同环境（如开发、测试、生产）的服务隔离机制，以及不同租户之间的服务隔离。

服务鉴权：根据特定的安全策略对服务请求进行鉴权处理，确保每一次调用都在安全许可控制范围内。

限流降级：限流和降级是保护自身服务正常运行的两方面的手段。限流指的是当外部请求量太大时，进行主动拒绝（或者放入缓冲队列），确保系统不被压垮；降级指的是当依赖的第三方系统性能异常（或不可用）时，为了不被第三方系统拖垮，服务采取的降级处理，在一定时间段内用内部默认的逻辑替代第三方的处理，降级仅限于非核心链路上的第三方依赖。

4．服务监控

服务拓扑：能够生成（或导出）当前有效的服务列表，以及服务之间的上下游依赖关系。

服务报表：记录每一次服务请求的审计日志，以不同维度生成服务报表（调用量、调用时长、状态分布、错误率等）。

服务调用链：支持服务调用链的追踪分析；在微服务架构下，由于进行了服务拆分，一次请求往往涉及多个服务，每个服务可能由不同的团队开发，使用了不同的编程语言，还有可能部署在不同的机器上，分布在不同的数据中心。服务追踪系统可以跟踪记录一次用户请求发起了哪些调用，经过哪些服务处理，并且记录每一次调用所涉及的服务的详细信息，通过日志快速定位是调用失败的环节。

---

06. 云原生数据服务

云原生数据服务DaaS依托大数据相关的技术，为应用提供从业务数据化到数据业务化的双轮驱动引擎，助力企业的数字化转型及升级。如图所示，DaaS数据服务主要包含大数据平台、数据资源池和数据集成平台。

1. 大数据平台

大数据平台一般由离线计算、流式计算、实时计算、机器学习、数据开发、数据运维、数据管理、可视化报表工具和数据可视化工具等计算引擎和工具组成，如图所示。

2. 数据资源池

数据资源池的数据库包括业务库、专题库、模型库、知识库、训练库、日志库、事件库和测试库，构建各类专题数据库，从而更好地进行数据分析，为各类数据技术负责数据资源整理分类及业务库（结构化/非结构化数据）提供技术支撑。

3. 数据集成平台

数据集成平台支持RDBMS、NoSQL、OLAP等数据源之间的数据迁移同步。它提供数据库不停服迁移、实时数据订阅及数据实时同步等多种数据传输方式。通过数据集成平台，可以在源数据库正常运行的情况下平滑地完成数据迁移。同时，还可以利用数据集成平台进行业务库实例间的数据实时同步，有效解决数据异地容灾、减少跨地区访问等业务问题。除此之外，数据集成平台还支持业务库实例增量数据实时订阅，通过数据订阅实现轻量级缓存更新、异步消息通知及定制化数据实时同步等业务场景。

数据集成平台提供对业务方数据库进行抽取和监控功能，能对数据源的数据资源进行统一清点，并能够在复杂的网络情况下对异构的数据源进行数据同步与集成，包括对关系型数据库、NoSQL数据库、大数据数据库、FTP等数据库类型的支持，支持离线数据的批量、全量、增量同步，支持以分钟、小时、日、周、月来自定义同步时间。

---

07. 云原生监控

1. 监控体系建设目标

1）趋势分析：长期收集并统计监控样本数据，对监控指标进行趋势分析。例如，通过分析磁盘的使用空间增长率，可以预测何时需要对磁盘进行扩容。

2）对照分析：随时掌握系统的不同版本在运行时资源使用情况的差异，或在不同容量的环境下系统并发和负载的区别。

3）告警：当系统即将出现故障或已经出现故障时，监控可以迅速反应并发出告警。这样，管理员就可以提前预防问题发生或快速处理已产生的问题，从而保证业务服务的正常运行。

4）故障分析与定位：故障发生时，技术人员需要对故障进行调查和处理。通过分析监控系统记录的各种历史数据，可以迅速找到问题的根源并解决问题。

5）数据可视化：通过监控系统获取的数据，可以生成可视化仪表盘，使运维人员能够直观地了解系统运行状态、资源使用情况、服务运行状态等。

2. 监控系统分类

一个完善的监控系统是IT系统构建之初就该考虑的关键要素。监控系统可以贯穿于移动端、前端、业务服务端、中间件、应用层、操作系统等，渗透到IT系统的各个环节。

通常情况下，监控系统分为端监控、业务层监控、应用层监控、中间件监控、系统层监控这5层。

1）端监控：针对用户在体验上可以感知的对象进行监控，如网站、App、小程序等。有些公司会设置专门的端用户体验团队负责进行端监控。在移动客户端的系统中，端监控的对象主要有H5、小程序、Android系统、iOS系统等，完善的端监控可以反馈地域、渠道、链接等多维度的用户体验信息；用户终端为传统的Web页面时，端监控仍会围绕用户体验采集数据，比如页面打开速度（测速）、页面稳定性（JS）和外部服务调用成功率（API），这3个方面的数据反映了Web页面的健康度。在阿里内部，对于端上数据的采集和监控，除了有SPM[1]（超级位置模型）、SCM[2]（超级内容模型）、黄金令箭[3]（交互采集模型）等理论支撑外，还有一系列相关工具、相关系统与大数据分析提供实践支撑。

2）业务层监控：对于业务层，可按需深度定制监控系统，实现对业务属性的监控告警功能，生成业务数据监控大盘。比如用户访问QPS、DAU日活、转化率、业务接口（如登录数、注册数、订单量、支付量、搜索量）等都是常见的监控对象。

3）应用层监控：主要是对分布式应用和调用链应用的性能进行管理和监控，如对Spring Boot、JVM信息、服务链路、Dubbo等应用在进行诸如RPC调用、Trace链路追踪动作时产生的数据进行监控。

4）中间件监控：监控的主要对象是框架自身的埋点、延迟、错误率等。这里的中间件包括但不限于消息中间件（RabbitMQ、Kafka、RocketMQ等）、数据库中间件（MySQL、Oracle、PostgreSQL、TIDB、PolarDB等）、数据库连接池中间件（HikariCP、Druid、BoneCP等）、缓存中间件（Redis、Memcached等）和Web服务中间件（Tomcat、Jetty等）。

5）系统层监控：如何对系统层进行监控，是运维工程师最关心的问题。小米通过Open-Falcon提炼出了Linux系统的运维基础采集项[4]，主要包含CPU、Load、内存、磁盘I/O、网络相关参数、内核参数、ss统计输出、端口、核心服务的进程存活情况、关键业务进程资源消耗、NTP offset采集、DNS解析采集等指标。这些都可以作为对系统层监控的关键指标。另外，网络监控也是系统监控中很重要的部分，对交换机、路由器、防火墙、VPN进行的监控都属于网络监控的范畴，内网和外网的丢包率、网络延迟等也都是很重要的监控指标。

市面上的监控系统可以说是五花八门，Apache的SkyWalking、百度的DP、美团的CAT、蚂蚁金服的九色鹿、宜信的UAVstack、滴滴的Omega、360和头条的Sentry、腾讯的badjs、阿里云的arms，以及已经商业化的Fundbug、听云和神策等，都是很知名的监控系统。每种监控系统都有各自的价值，通常来说，Zabbix是针对系统层的监控系统，ELK（Elasticsearch+Logstash+Kibana）主要是做日志监控的，而Prometheus和Grafana可以实现对端、业务层、应用层、中间件、系统层进行监控，因此Prometheus是打造一站式通用监控架构的最佳方案之一。

3. MDD指标驱动开发

MDD（Metrics-Driven Development）主张整个应用开发过程由指标驱动，通过实时指标来驱动快速、精确和细粒度的软件迭代。指标驱动开发的理念，不但可以让程序员实时感知生产状态，及时定位并终结问题，而且可以帮助产品经理和运维人员一起关注相关的业务指标，如图所示。

MDD的关键原则

·将指标分配给指标所有者（业务、应用、基础架构等）。·创建分层指标并关联趋势。·制定决策时使用的指标。

TDD主张在业务代码之前先编写测试代码，MDD则主张将上线、监控、调试、故障调查及优化等纳入设计阶段，而不是等到实施后才补充。

MDD是DevOps文化的纽带，对于敏捷开发、持续集成、持续交付，以及各个职能岗位提升DevOps意识有很大的帮助。·

对软件研发人员来说，可以实时感知应用各项指标、聚焦应用优化。·

对运维人员来说，可以实时感知系统各项指标、快速定位问题。·

对产品经理、商务人士来说，可以实时掌控业务各项指标，通过数据帮助自己做出决策。

4. 三大监控指标定义方法论

1.Google的四大黄金指标有4个来自Google SRE手册的黄金指标，这4个指标主要针对应用程序或用户部分。·

延迟（Latency）：服务请求所需耗时，例如HTTP请求平均延迟。需要区分成功请求和失败请求，因为失败请求可能会以非常低的延迟返回错误结果。

·流量（Traffic）：衡量服务容量需求（针对系统而言），例如每秒处理的HTTP请求数或者数据库系统的事务数量。·

错误（Errors）：请求失败的速率，用于衡量错误发生的情况，例如HTTP 500错误数等显式失败，返回错误内容或无效内容等隐式失败，以及由策略原因导致的失败（比如强制要求响应时间超过30ms的请求为错误）。

·饱和度（Saturation）：衡量资源的使用情况，例如内存、CPU、I/O、磁盘使用量（即将饱和的部分，比如正在快速填充的磁盘）。

2.Netflix的USE方法USE是Utilization（使用率）、Saturation（饱和度）、Error（错误）的首字母组合，是Netflix的内核和性能工程师Brendan Gregg提出的，主要用于分析系统性能问题，可以指导用户快速识别资源瓶颈及错误。

·使用率：关注系统资源的使用情况。这里的资源主要包括但不限于CPU、内存、网络、磁盘等。100%的使用率通常是系统性能瓶颈的标志。·

饱和度：例如CPU的平均运行排队长度，这里主要是针对资源的饱和度（注意，不同于四大黄金指标）。任何资源在某种程度上的饱和都可能导致系统性能的下降。·

错误：错误数。例如，网卡在数据包传输过程中检测到以太网络冲突了14次。

3.Weave Cloud的RED方法RED方法是Weave Cloud基于Google的4个黄金指标再结合Prometheus及Kubernetes容器实践得出的方法论，特别适用于对云原生应用以及微服务架构应用进行监控和度量。在四大黄金指标的原则下，RED方法可以有效地帮助用户衡量云原生以及微服务应用下的用户体验问题。RED方法主要关注以下3种关键指标。·

（Request）Rate：每秒接收的请求数。·

（Request）Errors：每秒失败的请求数。·

（Request）Duration：每个请求所花费的时间，用时间间隔表示。

5. 五种常见的监控系统

1.NagiosNagios[1]原名NetSaint，是Nagios Ain’t Gonna Insist On Sainthood的缩写，Sainthood译为圣徒，而Agios是saint希腊语的表示方法。它是由EthanGalstad开发并维护的一款开源且老牌的监控工具，用C语言编写而成。Nagios虽然开发时被定义为在Linux下使用，但在UNIX下也工作得非常好。

Nagios能有效监控Windows、Linux和UNIX的主机状态（CPU、内存、磁盘等），以及交换机、路由器等网络设备（SMTP、POP3、HTTP和NNTP等），还有Server、Application、Logging，用户可自定义监控脚本实现对上述对象的监控。Nagios同时提供了一个可选的基于浏览器的Web界面，以方便系统管理人员查看网络状态、各种系统问题以及日志等。

2.ZabbixZabbix是一款拥有超过21年的历史、100%免费开源、全世界安装次数超过30万的监控软件（截至2019年），旨在从成千上万的服务器、虚拟机和网络设备中收集指标进行监控，是适用于绝大多数IT基础架构、服务、应用程序、云、资源等的解决方案。Zabbix长期以来一直在瓜分Nagios的蛋糕，但它是一个成熟的系统，而不是简单的Nagios的分支，它的主要特征是对监控具有非常全面的视角，而不是仅仅监控状态，这恰是Nagios存在严重不足的地方。Zabbix的配置文件也不像Nagios那么复杂。

Zabbix可以通过Agent及Proxy的形式（见图1-11），比如JVM Agent、IPMI Agent、SNMP Agent等采集主机性能、网络设备性能、数据库性能的相关数据，以及FTP、SNMP、IPMI、JMX、Telnet、SSH等通用协议的相关信息，采集信息会上传到Zabbix的服务端并存储在数据库中，相关人员通过Web管理界面就可查看报表、实时图形化数据、进行7×24小时集中监控、定制告警等。

3.GangliaGanglia直译为神经节、中枢神经，这一名称其实已经反映了作者的设计思路，即将服务器集群理解为生物神经系统，每台服务器都是独立工作的神经节，这些神经节通过多层次树突结构联结起来，既可以横向联合，也可以从低到高逐层传递信息。具体例证就是Ganglia的收集数据可以工作在单播（unicast）[6]或多播（multicast）[7]模式下（默认为多播模式）。很多通过cacti或者Zabbix看不出来的集群总体负载问题，都能在Ganglia中体现，其集群的熵图可以明确集群负载状况，这是Ganglia最大的亮点。

Ganglia的核心包含gmond、gmetad以及一个Web前端，其主要用来监控系统性能，如CPU使用率、硬盘利用率、I/O负载、网络流量情况等，通过曲线很容易查看每个节点的工作状态，这对合理调整、分配系统资源，提高系统整体性能起到重要作用。Ganglia与Falcon、Zabbix相比，主要区别体现在集群的状态集显示上，Ganglia可以很便捷地对比各主机的性能状态。但随着服务、业务的多样化，Ganglia表现出一些不足：覆盖的监控面有限，且自定义配置监控比较麻烦，在展示页面查找主机烦琐，展示图像粗糙且不精确。

4.Open-FalconFalcon是猎鹰、隼的意思，鹰眼具有精准、洞穿的特点。Open-Falcon[9]是小米开源的监控系统，是为了解决Zabbix的不足而出现的产物，它由Go语言开发而成，小米、滴滴、美团等超过200家公司都在不同程度上使用Open-Falcon。

Open-Falcon具有数据采集免配置、容量水平扩展、告警策略自动发现、告警设置人性化、历史数据高效查询、Dashboard人性化、架构设计高可用等特点。Open-Falcon的文档目前分为0.1和0.2版本，且每个版本都有中、英两个版本[10]，社区贡献了MySQL、Redis、Windows、交换机、LVS、MongoDB、Memcache、Docker、Mesos、URL监控等多种插件支持

5.ZMon如果公司规模较小，不需要Prometheus这种级别的监控系统，那么可以考虑使用荷兰电商Zalanado公司开源的ZMon[11]这款天然的分布式监控及告警系统。ZMon和Prometheus一样，都采用拉模式，但需要在监控的目标上安装Check[12]来抓取指标信息，这些Check都分布在一个个Python编写的Worker上，其可对目标和站点进行Check操作（类似于Prometheus中的Exporter的概念）。

6. 主流监控系统对比

---

08. 云原生案例——阿里云

参考资料

1、什么是云原生？这回终于有人讲明白了：https://zhuanlan.zhihu.com/p/150190166

2、《企业级云原生架构：技术、服务与实践》

3、《Prometheus云原生监控：运维与开发实战》

4、SPM（Super Position Model）全称超级位置模型，是Web端Aplus日志体系和App端UserTrack日志体系共同使用的重要规范。SPM的作用类似于IP地址，可以直接定位前端控件区块。阿里的SPM位置编码由A.B.C.D四段构成，其中A代表站点/业务，B代表页面，C代表页面区块，D代表区块内的点位。

5、SCM（Super Content Model）全称超级内容模型，是一种与业务内容一起下发的埋点数据，用来唯一标识一块内容。在客户端埋点时，将SCM编码作为埋点的参数上传给UT服务器，SCM编码也采用含义与SPM相同的A.B.C.D格式。

6、黄金令箭，即用户在页面上进行交互行为触发的一个异步请求，用户按照约定的格式向日志服务器发送请求，展现、点击、等待、报错等都可以作为交互行为。规则为/goldenkey_xxx，其中x为一串数字，用于标识某个具体的交互事件。