云原生架构的核心技术（微服务、DevOps、容器云、Service Mesh、Serverless、声明式API）

天上飞的理念☁️☁️☁️☁️☁️，必然有落地的实现

文章介绍

读完本文，你将对云原生下的核心概念微服务、DevOps、容器云、Service Mesh、Serverless、Immutable Infrastructure、Declarative-API等有一个详细的了解，帮助你快速掌握云原生的核心和要点。

文章目录

• • 名词扫盲
  • 1. 云原生核心概念
  • • 1.1 微服务
    • 1.2 DevOps
    • 1.3 容器云
    • 1.4 Service Mesh
    • 1.5 Serverless
    • 1.6 Immutable Infrastructure
    • 1.7 Declarative-API
  • 2. Service Mesh（详细介绍）
  • 3. Serverless（详细介绍）
  • 4. 展望未来
  • 5. 总结

名词扫盲

• IaaS（Infrastructure-as-a-Service基础设施即服务）：
  提供给消费者的服务是对所有设施的利用，包括处理、存储、网络和其它基本的计算资源，用户能够部署和运行任意软件，包括操作系统和应用程序。主要功能就是讲底层的硬件资源以服务的方式对外暴露，为上层提供服务。IaaS模式下，只提供云计算服务的基础设施，用户可以部署和运行任意软件
• SaaS（Software-as-a-Service软件即服务）：
  提供给客户的服务是运营商运行在云计算基础设施上的应用程序，用户可以在各种设备上通过客户端界面访问，如浏览器。SaaS模式下，用户可以直接通过客户端使用云计算服务，不需要管理任何软硬件
• PaaS（Platform-as-a-Service平台即服务）：
  是云计算的重要组成部分，提供给消费者的服务是把客户采用提供的开发语言和工具开发的或收购的应用程序部署到供应商的云计算基础设施上去。PaaS模式下，用户不需要管理和控制云计算底层基础设施，直接使用和控制应用程序即可
• BaaS（Backend as a Service）后端即服务：
  应用架构由大量第三方云服务器和API组成的，使应用中关于服务器的逻辑和状态都由服务提供方来管理的。比如典型的Web应用和移动APP客户端应用，前后端交互主要是以RestAPI调用为主。只需要调用服务提供方的API即可完成相应的功能，比如常见的身份验证，云端数据/文件存储，消息推送，应用数据分析等。
• FaaS（Function as a Service）函数即服务：
  是一种实现无服务器计算的方法，服务商提供一个平台，允许客户开发、运行和管理应用程序功能，而无需构建和维护通常与开发和启动应用程序相关的基础架构的复杂性。 按照此模型构建应用程序是实现“无服务器”体系结构的一种方式，通常在构建微服务应用程序时使用。
• Xaas…
• Kubernetes：
  简称k8s，用8代替名字中间的8个字符“ubernete”而成的缩写。是Google开源的一个容器编排引擎，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful），Kubernetes提供了应用部署，规划，更新，维护的一种机制。
• 康威定律：
  康威定律是马尔文康威1967提出的：设计系统的架构受制于产生这些设计的组织的沟通结构。通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。

1. 云原生核心概念

1.1 微服务

微服务☁️： 微服务的核心就是传统的大的单体应用拆为更小的组件或模块，组件或模块就叫微服务。这个拆分是一个纵向的拆分。需要做到从底层的基础设施到数据库到应用中间件到软件应用部署包都能做到完全独立的一套。可以单独的从需求设计、开发、打包、部署，全部都能独立。实现各个微服务之间彻底的松耦合，同时各个微服务之间又能通过轻量的http rest接口进行交互和协同。微服务的核心就两点：大的单体要拆小，拆小的微服务接口要通过轻量的http rest接口协同。

1.2 DevOps

DevOps（开发运维一体化）：Development和Operations的组合词，核心就是持续集成和持续交付，需要将软件生命周期过程中的从需求开始到设计程序的开发、编译构建打包部署，从测试环境到生产环境整个过程能够实现全部的自动化。同时基于DevOps本身的发展又进一步和敏捷研发和自动化测试相关的最佳实践做了协同和集成。（要点1. 指开发、QA和运维三要素如何更好的进行协同，最早的DevOps核心是在CI/CD 持续集成、持续部署，到了DevOps以后把持续集成、持续部署拓展到持续交付。2. 当前谈DevOps一般会和Scrum敏捷研发、过程管理一起来谈，因为要做到持续的集成和交付必须要有敏捷的迭代版本和其相配合。）

1.3 容器云

容器云：云原生里边核心概念容器云，容器云里边的两个核心，一个是Docker容器，一个是k8s的容器资源调度和编排。单纯的Docker容器只是一个IaaS资源层的东西。容器本身是比虚拟机更轻量化的资源隔离单位，虚拟机是独享具体的一个操作系统，容器本身是架在操作系统上面的，多个容器可以共享操作系统，这是容器和虚拟机最大的区别。正是这个原因容器本身的体积会比虚拟机小，创建、销毁、调度的速度也更比传统的虚拟机更快。容器本身是IaaS层的内容，所以需要结合k8s进行容器的资源调度和编排，来向上层提供PaaS层的服务能力。（当把容器和容器的编排、调度一起谈的时候就会变成Paas概念，当前最火的基于k8s和Docker形成的PaaS容器调度平台）。容器本身是共享底层的操作系统，同时又能更好的做到CPU、内存、网络等资源的隔离。

1.4 Service Mesh

Service Mesh（服务网格）：一个去中心化的服务治理框架。原来需要对服务、Api接口进行治理和管控，一般会用API网关将api接口注册和接入到api网关，由于 API网关本身是一个中心化的架构 ，所以所有的请求流量都可以通过API网关，这个时候API网关就很容易对流量进行拦截，同时对拦截以后的流量进行安全、日志、限流、熔断、链路监控等各种管控治理。当在去中心化的架构下面就没有这种集中化的流量管控点 ，所有对于流量的拦截就从API网关下沉到各个微服务中去，这就意味着需要在每个微服务端增加一个代理包，通过代理包来做流量的拦截，同时实现对流量的管控。当前在微服务服务网格的微服务治理里面也是同样的思路，例如开源Istio微服务治理框架，它会在为服务端下方一个sidecar（边车）代理，通过代理实现流量的拦截和管控。去中心化的治理仍然会有一个控制中心，控制中心仍然是中心化的，但是 实际的控制流和接口数据访问的消息流实现了分离，控制流只管服务的注册发现，实际的接口调用、服务访问是不通过控制中心的，即使控制中心宕机也不会影响到接口服务的调用。

1.5 Serverless

Serverless（无服务器架构）：首先在云原生发展到后期以后。云原生的核心就是实现从资源到服务不断的向上抽象，开发人员越来越不会接触到底层的IT基础设施，只会接触各种技术服务能力，这些技术服务能力在Serverless架构里叫做BaaS（后端能力即服务）。

Serverless带来的另外一个变化是：在传统的云原生架构开发下，基于DevOps、微服务和容器云开发应用仍然会选择一个开发框架，仍然会涉及到开发应用的数据层、逻辑层以及上层的展现层，例如三层架构、五层架构。到了Serverless无服务器化以后，开发框架、开发环境、多层架构这些内容全部抛弃。任何一个功能的实现的核心全部变成一个个代码片段，通过各个代码片段去实现功能。通过代码片段组合、组装来实现复杂业务流程，这是Serverless未来期望达到的效果。这一块在Serverless里边对于FaaS层（Function as a Service）功能函数即服务。
注意：Serverless 是指 “无服务器架构”，这里的 “无服务器” 并不是指程序不需要服务器运行，而是指我们的开发工作不需要关注服务器底层的资源。

1.6 Immutable Infrastructure

Immutable Infrastructure（不可变基础设施）：传统的去做软件程序的部署，当部署到生产环境，部署到Tomcat中间件以后，如果要做变更，不管是程序的变更还是配置的变更，都会在原来的生产环境去重新部署或者是对某一个配置直接进行修改。但是在云原生强调的任何一个应用当部署到生产环境，形成一个容器实例以后，这个容器实例本身不应该在做任何的变化，它是不可变的。如果程序、配置发生修改了要基于容器镜像重新去新生成一个容器实例，同时把旧的容器实例销毁。

1.7 Declarative-API

Declarative-API（声明式API）：声明式API是和命令式操作相对应的概念，传统的创建一个容器需要执行一个命令行，在声明式API时代下，对于容器的创建首先去写一个yaml配置文件，在配置文件声明要做什么事情，同时做完事情以后期望达到什么状态，只需要把配置文件写好。第二步在平台拿到这个声明式配置文件后，再去解释这个声明式API文件的内容，再去做相应的后端操作，同时操作完以后把各个底层的技术组件协调到需要的状态。声明式API下面，任何对生产环境、对软件的修改都不是直接去操作一个命令，都是要先写声明、先写配置，写好的这份声明（yaml文件）是可以纳入配置管理里面集中做管控、管理的。方便当生产环境出现问题的时候能够快速去追溯之前对生产环境做过什么样的操作，方便做相关的回退、回滚操作。

2. Service Mesh（详细介绍）

当前，基于微服务架构搭建应用已成为主流的开发方式，构建微服务应用是每个开发者都可能要面对的工作。

然而，软件开发行业从来没有银弹，微服务架构在带给我们一系列便利的同时，依然存在缺点，其中的核心问题就是如何管理服务间的网络通信和服务治理，特别是当你的应用规模变得越来越庞大时，这个问题会变得越发突出。（ps：银弹比喻为具有极端有效性的解决方法，作为杀手锏、最强杀招、王牌等的代称。可以理解为绝对的好）

当前微服务面临的问题：❓

1️⃣虽然框架本身屏蔽了分布式系统通信的一些通用功能实现细节，但开发者却要花更多精力去掌握和管理复杂的框架本身，在实际应用中，去追踪和解决框架出现的问题也绝非易事;
2️⃣开发框架通常只支持一种或几种特定的语言，微服务一个重要的特性就是语言无关（没有最好的编程语言, 只有最适合某一场景的编程语言，尤其是AI的兴起，一般大型互联网公司存在 C/C++、Java、Golang、PHP、Python、NodeJs 等语言的项目），但那些没有框架支持的语言编写的服务，很难融入面向微服务的架构体系，想因地制宜的用多种语言实现架构体系中的不同模块也很难做到，这对微服务环境下不同语言开发提出了很大的挑战；

3️⃣框架以lib库的形式和服务联编，复杂项目依赖时的库版本兼容问题非常棘手，同时，框架库的升级也无法对服务透明，服务会因为和业务无关的lib库升级而被迫升级；

所以，Service Mesh 技术就是为解决这些难题而生的， Service Mesh 解决了当下的微服务痛点。

维基百科

在软件架构中，服务网格是一个专用的基础设施层，用于使用代理促进服务或微服务之间的服务到服务通信。专用通信层可以提供许多好处，例如提供对通信的可观察性，提供安全连接，或自动重试和回退失败的请求。
服务网格由与应用程序中的每个服务配对的网络代理和一组任务管理流程组成。代理称为数据平面，管理进程称为控制平面。数据平面拦截不同服务之间的调用并“处理”它们；控制平面是网格的大脑，负责协调代理的行为，并为运维人员提供 API 来操作和观察整个网络

在云原生的技术体系之下，容器化已经成为了开发者部署应用的第一选择，在这种上下文之下Kubernetes又是首选的容器编排和调度系统。不过在k8s和容器化极大简化了应用部署之下，仍然有有一个能力需要开发者深度参与进来，那就是服务的治理能力。服务网格最初脱胎于简化服务和解耦服务治理能力的需求。核心概念就是把服务治理的能力从开发者的代码中抽象出来放到一个单独的sidecar代理中实现，通过为每个服务的工作负载注入sidecar代理服务网格极大简化了服务治理的操作。同时也将和开发者的代码进行解耦，从此之后开发者只需要关注业务代码而运维人员只需要操作网格里的sidecar就可以实现服务的治理，可以说服务网格是云原生时代下服务治理能力的大势所趋。

在服务网格中，请求将通过所在基础架构层中的代理在微服务之间路由。正因如此，构成服务网格的各个代理有时也被称为”Sidecar”（边车），这是因为它们 与每个服务并行运行，而非在内部运行 。所以说，这些”Sidecar”代理（与每项服务分离）构成了 网格式网络，同时又与微服务相互协作。作为处理服务间通信的基础设施层，Service Mesh 可以帮助开发者从服务通信问题的困境中解脱出来，节省了开发和维护通信控制逻辑的繁重工作，，所以有些人将 Service Mesh 称作第二代微服务。

Sidecar 模式从跨语言、更新发布和运维等方面入手，实现对业务服务的零侵入，更解藕于开发语言和单一技术栈，实现了完全隔离，为部署、升级带来了便利，做到了真正的基础设施层与业务逻辑层的彻底解耦，让开发人员专注于业务。另一方面，Sidecar 可以更加快速地为应用服务提供更灵活的扩展，而不需要应用服务的大量改造。

举个栗子： 拿健康设备例如小米手环来举例，人体的一些指标都会在设备上显示，设备就是自己个人的一个缩影。在服务网格里通过Sidecar模式，一个业务应用在跑的时候，时刻有一个Sidecar对业务容器进行管控。比如说有一个网站的容器在运行，旁边有一个对应的Sidecar容器，它可以接管网站的流入、流出流量，也能够看到网站的状态。结合微服务大趋势，可以想象企业里如果有一个复杂的企业业务，能拆解成一百个微服务，每个微服务都有一个Sidecar容器在旁边时刻去管控着业务服务。

另一方面，云原生是未来的软件构建方向，正在席卷整个软件开发行业。你所开发的应用不是已经上云，就是在上云的路上，而且或多或少已经引入了一些云原生架构的技术。而 Service Mesh 就是构建云原生应用中，不可或缺的一环。

总结一下服务网格的几个特点：

1️⃣ 非侵入式代理：服务网格引入的sidecar作为业务微服务的代理，承担了非业务功能：如流量管理、安全认证、监控运维等。sidecar卸载掉了业务微服务的通用功能，使得业务开发人员专注于业务逻辑开发，无需关注其他非业务需求。
2️⃣ 非业务公共能力解耦：业务微服务功能与sidecar非业务功能分离解耦，业务微服务专注于业务逻辑，与业务逻辑无关的DFX特性，如流量管理、安全认证、监控运维等，全部旁路到sidecar容器统一处理；
3️⃣ 管理面数据面分离：这也是服务网格的一大优势，通过将控制面与数据面分离解耦，达到不同问题域的解耦目标。控制面只聚焦安全、监控、流量等策略的处理和下发，数据面只聚焦如何执行策略，各自的故障不会相互影响，例如控制面的故障不会影响数据面的流量转发。

服务网格service-mesh是一个形象化的词语表达：service（服务）-mesh（网格），它描述了服务间的依赖形态，就像下面这张网一样：

深色 的是我们平时工作中接触最多的 业务微服务 ，旁边 蓝色 的被称为边车（sidecar）服务，sidecar作为业务微服务的“代理”，处理与其他业务微服务sidecar之间的非功能需求，如网络通信、安全、监控、流量控制等。多个sidecar之间的连接和交互组成了“网格（mesh）”。

一句话概括Service Mesh就是微服务的 网关、负载均衡等独立出来成为底层基础服务，从架构上剥离微服务，让开发者只关心服务业务开发的技术。

我们应该使用服务网格吗？
尽管已经看到了使用服务网格的足够理由，但下面列举了一些可能促使我们不使用它的原因：

• 服务网格处理所有服务到服务的通信，而部署和操作服务网格则需要支付额外的费用。对于较简单的应用程序，这可能是不合理的。
• 由于我们已经习惯于处理一些此类问题，例如应用程序代码中的熔断，因此可能导致服务网格中的重复处理。
• 越来越依赖于诸如服务网格之类的外部系统可能会损害应用程序的可移植性，尤其是因为没有针对服务网格的行业标准。
• 由于服务网格通常通过拦截通过代理的网格流量来工作，因此它可能会给请求增加不希望的延迟，同时Service Mesh 方式的服务调用，相比服务框架的直接调用，增加了与 Service Mesh 中 Sidecar 的交互，必然会牺牲部分性能。
• 服务网格增加了许多其他组件和配置，需要精确处理。这需要专业知识，并增加了学习曲线。
• 最后，我们可能最终将操作逻辑（应在服务网格中存在）与业务逻辑（不应在服务网格中）混合在一起。

因此，正如我们看到的，服务网格的故事不仅仅涉及好处，但这并不意味着它真的好。对我们来说，重要的是要仔细评估我们的需求和应用程序的复杂性，然后权衡服务网格的好处和它们所增加的复杂性。

Service Mesh应用框架

• Linkerd
  Linkerd 是 Kubernetes 的服务网格(service mesh)
  Linkerd官网Linkerd中文社区
• Istio
  Istio是由Google、IBM和Lyft开源的微服务管理、保护和监控框架。
  Istio官网 Istio中文社区
• …

3. Serverless（详细介绍）

Serverless 官网 Serverless 中文社区

整个计算机技术发展史，我们会发现 “ 抽象、解耦、集成 ” 的主题贯穿其中。产业每一次的抽象、解耦、集成，都将创新推向新的高度，也催生出庞大的市场和新的商业模式。

云的时代，硬件软件化 和 软件服务化 成为最显著的两个趋势。

Serverless包含要素：

• Serverless 计算是 全托管 的计算服务，客户编写代码构建应用，无需管理和运维服务器等底层基础设施。
• Serverless 计算是通用、普适的，结合云 API（BaaS 服务）的能力，能够支撑云上所有重要类型的应用。
• Serverless 计算不但实现了最纯粹的 按需付费（为代码实际运行消耗的资源付费），也应当支持预付费等计量模式，使得客户成本在各种场景下，与传统方式相比都极具竞争力。
• 不同于虚拟机或容器等面向资源的计算平台，Serverless 计算是面向应用的。要能整合和联动云的产品体系及其生态，帮助用户在价值交付方式上实现颠覆式创新。

腾讯云云函数收费规则

以腾讯云为例部署一个website：

1. 首先进入Serverless应用，新建应用

2. 选择静态网站（之前是有SpringBoot应用的，部署website的时候也是各种报错，好在终于成功了）

1. 部署完成

这里部署花费大概1-2分钟，部署个静态页面而已，太慢了 看来还是要继续优化

访问

4. 更新应用

这里就随便写个html页面采用本地上传方式进行部署，也支持代码托管平台Github、Gitlab、Gitee、CODING、自定义仓库拉取部署。

测试使用的代码如下：

<!DOCTYPE html><html lang="en"><head><meta charset="UTF-8"><meta http-equiv="X-UA-Compatible" content="IE=edge"><meta name="viewport" content="width=device-width, initial-scale=1.0"><title>website</title></head><body><h1>hello world</h1></body></html>

部署后的效果

这里部署从头到尾我们都没有去接触服务器，也不用去考虑web服务器是用IIS还是Tomcat、Apache Http、Nginx等这样的容器，甚至不知道服务器的IP的情况下就完成的一个网站的搭建。
在Serverless时代下，我们再也不用担心流量洪峰下服务器能不能抗住，要不要扩容，服务器被黑客攻击怎么办。

Serverless特点：

• 默认弹性：可以轻松应对大量 API 请求和任务，不会再因为扩容不及时，导致资源耗尽引起的业务不可用了！
• 无流量时支持缩容到 0：省钱神器，再也不用买虚拟机和负载均衡了，对我们来说降本效果杠杠滴！
• 免运维：免去了虚拟机的运维成本！
• 更安全：它不能被 SSH 登陆，而且也不会像虚拟机一样一直开着，等着被人扫描和攻破！
• 零改造：无需修改代码，之前虚拟机上的 JAR 包直接就可以跑在函数计算 FC 上！

Serverless缺点：

• Serverless 在请求到来时才运行。这意味着，当应用不运行的时候就会进入 “ 休眠状态 ”，下次当请求来临时，应用将会需要一个启动时间，即冷启动。这个时候，可以结合 CRON 的方式或者 CloudWatch 来定期唤醒应用。尽管这个冷启动时间大部分情况下，可以在 50ms 以内。而这是对于 Node.js 应用来说，对于拥有虚拟机的 Java 和 C# 可能就没有那么幸运了。
• 目前各大云平台支持框架有限。
• 在云函数场景下（Faas）业务大的要拆分很多小小的函数，如何管理维护之间的关系？如何关联管理。
• 排查调试问题怎么办？一个业务假设有100个函数，分散各地，怎么去排查？
• 无服务器仍然不成熟，还没有建立架构模型和健壮的开发工具。
• 完全依赖于第三方服务。

4. 展望未来

从长在云上到生到云上☁️☁️☁️

原生代表什么？相信通过上边的内容已经有了简单的了解，这里我们再举个贴合实际的例子：平常我们听到的原生就是在说原生家庭的时候，比如一个小孩不是抱养，是从一出生就在家庭里面，对应到IT应用和云上也是一个道理。

传统的用云平台的方式都是一个软件应用最终开发完成，构建打包成一个完整的部署包以后再托管到云平台去运行。在云原生下面希望应用一开始就生在云上，从有构建应用的想法开始到需求、设计、开发、测试、构建、打包、部署最终交付云平台所有的软件生命周期、软件开发过程全部都在云上面进行，这就是云原生。

云原生核心的变化就是从传统云服务IaaS（基础设施即服务）转变到Paas（平台能力及服务），也就是说整个抽象的过程不断的向上移，从资源层到服务，举个栗子：传统我们用云平台，传统的方式不管是阿里云还是华为云申请一个虚拟机，自己安装数据库，在云原生下面更希望直接用阿里云提供的数据库服务，也就是说虚拟机这个层面，不要去接触。

云原生是随着云平台云服务的发展出现的一系列技术实践和管理实践的融合。技术实践包括微服务、容器云、服务网格、声明式API、不可变基础设施，管理实践包括敏捷研发、DevOps、持续交付、康威定律，如果简单从技术实践和管理实践这两个层面很难理解云原生的核心逻辑。

5. 总结

Karl Marx说的好，生产力决定生产关系，云计算的概念层出不穷，其本质上还是对生产关系和生产力的配置与优化，生产者抛开场景意味追求高大上的技术将譬如“大炮打蚊子”，小题大做，鼓励大家为了满足大家的好奇心进行折腾，毕竟那么多科学发现和重大发明都是因为折腾出来的，不想要一匹跑的更快的马，而是发明汽车的福特，捣鼓炸药的诺贝尔，种豌豆的孟德尔……同时还是要考虑将技术产业化（或许能改变生产关系），提高生产力。