云原生架构的核心技术_云原生的核心

名词扫盲

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

语言	主要用途
C	操作系统、嵌入式、驱动开发
C++	图形图像、科研、通信、桌面软件、游戏、游戏服务器
C#	Window桌面软件、.Net web、服务器
Java	Java SE跨平台的桌面应用Android
	Java EE企业级应用、web开发、服务器后端
	Java ME手机应用流行于非智能机时代
	Java Android用于开发安卓应用
Go	或Golang高性能的服务器应用高并发性比较年轻
Erlang	高并发服务器应用多用于游戏
Python	Web、科学计算、运维
Ruby	Web
Perl	运维、文本处理用的较少
Lisp	科研、一种逻辑语言用于人工智能
Node	一个JavaScript运行环境(runtime)
Haskell	Haskell是一种标准化的、通用纯函数式编程语言数学逻辑方面
Scala	一种类似Java的编程语言集成面向对象编程和函数式编程的各种特性
JavaScrpit	前端在Node中可以做后端
HTML/CSS	标记语言主要是给前端工程师构建页面应用
Groovy	用于Java虚拟机的一种敏捷的动态语言完全兼容java的语法
......	......

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 计算是通用、普适的结合云 APIBaaS 服务的能力能够支撑云上所有重要类型的应用。
• 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说的好生产力决定生产关系云计算的概念层出不穷其本质上还是对生产关系和生产力的配置与优化生产者抛开场景意味追求高大上的技术将譬如“大炮打蚊子”小题大做鼓励大家为了满足大家的好奇心进行折腾毕竟那么多科学发现和重大发明都是因为折腾出来的不想要一匹跑的更快的马而是发明汽车的福特捣鼓炸药的诺贝尔种豌豆的孟德尔……同时还是要考虑将技术产业化或许能改变生产关系提高生产力。