第33课：云原生关键技术浅析

本课时我们主要学习云原生关键技术的相关概念。讲到"云原生"大家或多或少了解过这个词，但是要来定义云原生概念可能就比较模糊了。这是由于一方面云原生的关键技术近几年在发生不断的演变；另一方面，只关注的它里边某一部分技术的应用，也不在意云原生的具体概念。

什么是云原生

那么，这节课我们首先就来讲一讲云原生的概念。这些年云计算平台在不断成熟，如：K8s + 容器模式在大部分企业中得到了应用。

另外，就开发层而言，分布式框架也在不断普及和使用，如 Java 语言中的 Dubbo 框架，这种分布式的开发框架，这些都使得应用开发逐渐融合到基于云的构建和运行环境。

这种模式形成的技术体系和方法论，我们就称之为云原生，所以云原生并不是一个很具体的定义，随着云的使用模式、技术差异等因素的影响，不同的组织定义的概念也并不相同。

比如，2017年，Pivotal 公司定义的云原生主要涵盖四个要点，分别是 Devops、持续交付、微服务和容器。但 2018 年 CNCF 又重新定义了云原生的概念，把服务网格和声明式 API 加入其中。

如果我们当前来定义云原生的话，可以结合这几个方面来进行概括，一方面是基于云基础设施，然后结合 Devops 的持续交付能力，以及微服务框架和服务网格，结合云开发模式这几个技术就组成了当前云原生标准了。

云原生关键技术

我们接下来具体讲下这些技术的具体概念，首先是云基础设施，基础设施是云原生的基石，如图所示：

图中最底层便是硬件基础设施，基础设施通过虚拟化技术交付 IaaS 资源给到最上层是应用层使用，应用层并不关心底层的基础设施，因为中间层的虚拟化技术会帮助实现，比如云计算资源，可以使用 K8s\Docker 方式轻量化计算。应用所需的数据库资源，则结合 OpenStack+KVM 或 K8S+Docker 等技术结合到具体的应数据库的服务供应用层调用；应用所需的存储资源则可以通过如 GFS、Ceph、NFS 等共享的分布式存储技术来供 App 调用，所以你发现应用层并不需要关心硬件设施层。

K8s 作为容器管理平台是被普遍应用的，云原生所依赖的基础设施能力在此基础上得到了更大的扩展，比如 Istio 服务网格，Prometheus 针对编排模式提供了特定的服务扩展，它们也随之在不断融入云原生的核心组件中，所以我们 K8s\Docker 的作用举足轻重。

另外一个概念就是 Devops，我们在前面的课程中讲过，Devops 涵盖了开发、测试、部署、运维四大环节，打通了整个开发体系实现了持续交付，在开发层通过 Git 对代码库进行管理，Jenkins 可以完成项目的开发、测试、部署，以及对底层的依赖，使得应用部署发布更加容易，所以通过这几个关键技术就可以帮我们构建一套开源的 Devops 方案。

另外一个关键技术就是服务网格，服务网格是用于处理服务间通信的基础设施层，它负责构建复杂的云原生应用传递可靠的网络请求，在实践中服务网格的实现通常和应用部署在一起，提供轻量化的网络代理服务，对于应用而言它是透明的，如图所示，在 K8s 中最小单元是 Pod，在 Pod 里的应用实例对外部目标应用实例的调用需要通过一个 Sidecar 中间代理，调用协议通过 RPC 协议调用 Sidecar，Sidecar 代理则请求一个统一的服务注册中心，这里基于应用请求的应用名称得到需要请求的具体的目标实例的连接信息，拿到后再去请求目标的实例，整个服务网格中如果聚焦到单元 Pod 里的具体应用实例间的调用关系就是这样的流程，注册中心能维护可用的实例列表，并且对可用的实例列表可以通过评级打分的策略来得出负载均衡的权重，就可以实现负载均衡，另外还可以通过熔断的自动隔离机制实现自动隔离不健康的实例。

基于此，我们再宏观到整个集群，所有实例的相互调用就形成了一张网格状的图表，我们可以看到深蓝色的部分代表的就是具体的微服务应用，而它调用的 Sidecar 关联起每个实例应用，所以这样就形成了一个服务类的服务网格，Sidecar 通信的组织框架可以用 K8s 进行统一管理，常见的 Sidecar 代码实现方式主要是通过 Istio，它是由 Google 和 IBM 主导并支持开源的 Service Mesh 框架。

我们看到有了服务网格以后，整个微服务的层级关系是这样组成的，底层是基础设施层，上层封装具体的容器，如 Docker 和 rkt 等轻量级容器服务，再往上层是通过 K8s 进行容器编排，最上层是服务网格（Istio 和 LINKERD 提供服务）。

最后，我们来聊聊微服务的开发模式演变，传统的部署模式我们会把应用放到一个单体应用里面，比如我们早期做 Java 开发时，会把所有的业务逻辑都封装到一个 war 包里进行部署，虽然这种部署方式简单快速，但仍然有各种各样的问题，当技术演变到今天，单体应用已经很少见了，通过不断地发展，就形成了微服务开发模式，它强调各个服务各个组件个体化，不再依赖特定的环境，降低了对环境的依赖度，另外就是通过虚拟化容器技术实现了隔离。

对于单体应用向微服务拆分，如何设计和安排呢？总结来说：首先通常会把一些通用的服务先拆分到微服务中，比如统一权限、统一存储、统一登录等功能优先拆分；另外就是先处理有状态的服务，比如登录信息、动态路由等存储到共享的数据队列或共享的数据库中，也就是拆分有状态的服务单独进行处理；另外我们还需要掌握整个系统对外的接口与实体之间的关系，还要结合业务的具体流程，优先考虑将一些新的功能拆分到微服务中，因为新服务通常依赖比较少；另外就是新老服务架构同时并行，拆分出微服务上线后，同时老服务平台依然保留；最后就是业务可以考虑垂直拆分，从业务角度把独立的业务线、流程线进行垂直拆分，性能上考虑水平拆分，比如单体服务要求有更多的计算资源时就可以通过水平拆分进行性能优化。