云原生架构技术分享

Posted 2021-04-06 南京德睿能源研究院

什么是云原生？

1

Pivotal最初的定义

早在2015年Pivotal公司的Matt Stine写了一本叫做迁移到云原生应用架构的小册子，其中探讨了云原生应用架构的几个主要特征：

• 符合12因素应用

• 面向微服务架构

• 自服务敏捷架构

• 基于API的协作

• 抗脆弱性

2

CNCF最初的定义

到了2015年Google主导成立了云原生计算基金会（CNCF），起初CNCF对云原生（Cloud Native）的定义包含以下三个方面：

• 应用容器化

• 面向微服务架构

• 应用支持容器的编排调度

云原生（Cloud Native）的定义

到了2018年，随着近几年来云原生生态的不断壮大，所有主流云计算供应商都加入了CNCF基金会，且从Cloud Native Landscape中可以看出云原生有意蚕食原先非云原生应用的部分。CNCF基金会中的会员以及容纳的项目越来越多，该定义已经限制了云原生生态的发展，CNCF为云原生进行了重新定位。以下是CNCF对云原生的重新定义：（中英对照）： 

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

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

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

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

图：云原生定义

---

为什么是Kubernetes

2

容器

Cloud Native的基石

容器最初是通过开发者工具而流行，通过cgroup和namespaces，使得进程之间相互隔离，即进程虚拟化，可以使用它来做隔离的开发测试环境和持续集成环境，这些都是因为容器轻量级，易于配置和使用带来的优势。

2

容器编排

Kubernetes是容器编排系统的事实标准，让容器应用进入大规模工业生产。

在单机上运行容器，无法发挥它的最大效能，只有形成集群，才能最大程度发挥容器的良好隔离、资源分配与编排管理的优势，而对于容器的编排管理，Swarm、Mesos和Kubernetes的大战已经基本宣告结束，Kubernetes成为了无可争议的赢家。

3

微服务

微服务——Cloud Native的应用架构。

微服务带给我们很多开发和部署上的灵活性和技术多样性，但是也增加了服务调用的开销、分布式系统管理、调试与服务治理方面的难题。将微服务与容器结合，极大的方便了我们开发运维人员，通过容器编码工具，我们可以轻松实现服务动态伸缩、服务故障转移、服务灰度发布等等原本很难实现的功能，这就是云原生架构带来的好处。

---

发展现状

图：当前架构现状

当前云平台是基于kubernetes（简称k8s）集群搭建的，集群功能包括服务注册/发现、负载均衡、应用伸缩、存储服务PV/PVC/storage class，对外有Ingress、网关，证书管理服务cert-manager，用户UI等等。仅仅有kubernetes集群还是不够的，为了满足上云应用的基本需求，至少还需要以下组件的支撑

 1    镜像仓库

随着云上应用越来越多的采用容器方式部署，版本更新迭代迅速，容器镜像的数量势必增长很快，我们需要一个统一的镜像仓库，用来集中管理这些镜像文件。

Harbor是由VMware 公司中国团队为企业用户设计的 Registry server 开源项目，包括了权限管理(RBAC)、LDAP、审计、管理界面、自我注册、HA 等企业必需的功能，同时针对中国用户的特点，设计镜像复制和中文支持等功能。

作为一个企业级私有 Registry 服务器，Harbor 提供了更好的性能和安全。提升用户使用 Registry 构建和运行环境传输镜像的效率。Harbor 支持安装在多个 Registry 节点的镜像资源复制，镜像全部保存在私有 Registry 中， 确保数据和知识产权在公司内部网络中管控。另外，Harbor 也提供了高级的安全特性，诸如用户管理，访问控制和活动审计等。

---

 2    统一日志

应用通过容器部署之后，由于容器本身销毁创建非常简单，以及k8s动态调度等原因，原本保存在本地的日志，可能随时会丢失，容器的数量越来越多，日志查找也非常不方便，需要一个统一的日志收集查询服务。

业界比较成熟的框架是基于Elasticsearch做日志存储，Fluentd做日志收集，Kibana做查询展示，但是这次结合实际场景，我们对日志查询的需求远远大于对日志分析的需求，我们采用了成本更低，使用更方便的方案——Loki。

Loki是 Grafana Labs 团队最新的开源项目，是一个水平可扩展，高可用性，多租户的日志聚合系统。它的设计非常经济高效且易于操作，因为它不会为日志内容编制索引，而是为每个日志流编制一组标签。项目受 Prometheus 启发，官方的介绍就是：Like Prometheus, but for logs. 。与其他日志聚合系统相比，Loki具有下面的一些特性：

• 不对日志进行全文索引。通过存储压缩非结构化日志和仅索引元数据，Loki 操作起来会 更简单，更省成本 。
• 通过使用与 Prometheus 相同的标签记录流对日志进行索引和分组，这使得日志的扩展和操作 效率更高 。
• 特别适合储存 Kubernetes Pod 日志; 诸如 Pod 标签之类的元数据会被自动删除和编入索引。
• 受 Grafana 原生支持。

Loki 由以下3个部分组成：

• loki是主服务器，负责存储日志和处理查询。

• promtail是代理，负责收集日志并将其发送给 loki 。

• Grafana用于 UI 展示。

---

 3   告警监视

应用通过容器部署之后，销毁创建更加频繁，应用也更容易出现问题，应用何时出现问题，问题的严重程度需要我们及时掌握。我们采用业界比较成熟的基于Prometheus方案。Prometheus 是一个开源监控系统，它本身已经成为了云原生中指标监控的事实标准，几乎所有 Kubernetes 的核心组件以及其它云原生系统都以 Prometheus 的指标格式输出自己的运行时监控信息。基本框架如下：

Prometheus server是一个时序数据库，与一般时序数据库不同的是，Prometheus是专门存储应用指标的，只能通过主动拉取的方式采集指标。拉取的终端可以是专门定制的exporters，如node exporter、mysql exporter、redis exporter等，也可以是pushgateway。

 Prometheus提供了一套查询语言用来查询指标——PromQL。通过PromQL我们可以很好的查询历史指标，也可以通过设置一些规则对异常指标进行告警。

与Prometheus结合比较好的前端框架有Grafana，它可以自定义展示风格。

Alertmanager是一个专门处理告警的模块，可以设置一些静默规则，一旦Prometheus通过了静默规则，alertmanager就会将告警信息以邮件、webhook等方式发送出去。

钉钉告警是我们自己开发的告警平台，通过与alertmanager对接，我们可以将告警信息进行分类，指定责任人，发送到不同的钉钉群等。

---

  未来计划 

1

服务治理

• Kubernetes 提供平台基础设施层强大的容器编排与调度能力

– 服务部署与弹性伸缩：Deployment

– 服务拆分与服务发现：Service

• Kubernetes 提供简单的负载均衡

– 负载均衡：基于IPVS或Iptables的简单均衡机制

• 服务治理能力不足

- 动态路由

- 熔断限流

- 灰度发布

- 故障注入

2

调用链分析

在一个分布式系统中，追踪一个事务或者调用流一般如上图所示。虽然这种图对于看清各组件的组合关系是很有用的，但是，它不能很好显示组件的调用时间，是串行调用还是并行调用。

这种展现方式增加显示了执行时间的上下文，相关服务间的层次关系，进程或者任务的串行或并行调用关系。这样的视图有助于发现系统调用的关键路径。通过关注关键路径的执行过程，项目团队可能专注于优化路径中的关键位置，最大幅度的提升系统性能。

3

服务网格

不管是服务治理还是调用链分析，服务网格都能满足我们的需求

服务网格（ Service mesh ）是服务间通信的基础设施层 。 它对全局流量和通信进行监控和管理，提供包括可观察性、流量转移（用于灰度发布）、弹性能力（例如断路和重试/超时）等一系列功能，并为服务之间的通信提供双向 TLS 认证能力，让网格能够对请求和响应进行自动加密和解密。特点：

• 治理能力独立（Sidecar）

• 应用程序无感知

• 服务通信的基础设施层

Istio是一个开放服务网格，提供了一种连接，管理和保护微服务的统一方法。它支持管理服务之间的流量，执行访问策略以及汇总遥测数据，所有这些都无需更改微服务代码。

---

4

DevOps

DevOps 是指对企业文化、业务自动化和平台设计等方面进行全方位变革，从而实现迅捷、优质的服务交付，提升企业响应能力和价值。只有通过 快速迭代的 IT 服务交付 ，这一切才能实现。 DevOps 可以将传统应用和最新的云原生应用与基础架构彼此相连。

从字面上来看，"DevOps"一词是由英文 Development（开发）和 Operations （运维）组合而成，但它所代表的理念和实践要比这广阔的多。DevOps 涵盖了安全、协作方式、数据分析等许多方面。

      DevOps 强调通过一系列手段来实现既快又稳的工作流程，使每个想法（比如一个新的软件功能，一个功能增强请求或者一个 bug 修复）在从开发到生产环境部署的整个流程中，都能不断地为用户带来价值。这种方式需要开发团队和运维团队密切交流、高效协作并且彼此体谅。此外，DevOps 还要能够方便扩展，灵活部署。有了 DevOps，需求最迫切的工作就能通过自助服务和自动化得到解决；通常在标准开发环境编写代码的开发人员也可与 IT 运维人员紧密合作，加速软件的构建、测试和发布，同时保障开发成果的稳定可靠。

DevOps 可以加快一个想法从提出到部署的整个过程。DevOps 的核心在于，在应用的整个生命周期中，都要确保日常运维任务自动化和环境的标准化。容器可以提供标准化的环境，你需要一个平台来管理它们，同时提供内置的自动化功能并支持各种基础架构。

选择支持流程的工具对于 DevOps 的成功至关重要。运维团队要跟上快速开发周期，就需要利用高度灵活的平台，并像开发团队对待代码一样，对待平台的基础架构。手动部署不仅速度慢，而且可能出错。因此，您也可通过自动化来简化平台调配和部署。

持续集成和持续部署管道（CI/CD）是实施 DevOps 的一大重要成果。CI/CD 可帮助您频繁地向客户交付应用并检验软件质量，而且只需极少的人工干预。

具体而言，CI/CD 在整个应用生命周期内（从集成和测试阶段，到交付和部署）都引入了持续自动化和持续监控，让您能够快速识别和改正问题与缺陷。这些彼此关联的实践通常被统称为“CI/CD 管道”，需要开发和运维团队以敏捷方式协同支持。

图：CI/CD的一种实现思路

CI/CD的一种实现具体流程：

1. 用户本地完成开发；

2. 代码提交到GitLab上；

3. Gitlab收到代码提交请求后通过webhook触发Jenkins;

4. Jenkins被触发后，首先从代码仓库拉取源码，进行构建、静态分析和单元测试，然后创建镜像推送到镜像仓库Harbor，最后调用Kubernetes API更新应用；

5. Kubernetes从Harbor拉取最新镜像，更新应用。

---

往期推荐

点击“阅读原文”发现惊喜

在看点这里