云原生架构(微服务、容器云、DevOps、不可变基础设施、声明式API、Serverless、Service Mesh)

前言

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

因题主资源有限, 这里会选用部分云服务商的组件进行讲解, 并不代表只有该服务商才有这项技术; 请知悉, 万变不离其宗,原理是大差不差的。

名词简述

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)函数即服务

一种实现无服务器计算的方法,服务商提供一个平台,允许客户开发、运行和管理应用程序功能,而无需构建和维护通常与开发和启动应用程序相关的基础架构的复杂性。 按照此模型构建应用程序是实现“无服务器”体系结构的一种方式,通常在构建微服务应用程序时使用。

K8S(Kubernetes)容器编排引擎

Kubernetes 简称K8S,用8代替名字中间的8个字符“ubernete”而成的缩写。是Google开源的一个容器编排引擎,用于管理云平台中多个主机上的容器化的应用,Kubernetes的目标是让部署容器化的应用简单并且高效(powerful),Kubernetes提供了应用部署,规划,更新,维护的一种机制。

康威定律(组织学原理)

康威定律是马尔文康威1967提出的:设计系统的架构受制于产生这些设计的组织的沟通结构。通俗的来讲:产品必然是其(人员)组织沟通结构的缩影。

在这里插入图片描述

云原生核心概念

微服务

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

微服务核心点:大的单体要拆小,拆小的微服务接口要通过轻量的http rest接口协同。
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

容器云

云原生里边核心概念容器云,容器云里边的两个核心,一个是Docker容器,一个是k8s的容器资源调度和编排。单纯的Docker容器只是一个IaaS资源层的东西

容器本身是比虚拟机更轻量化的资源隔离单位,虚拟机是独享具体的一个操作系统,容器本身是架在操作系统上面的,多个容器可以共享操作系统,这是容器和虚拟机最大的区别。正是这个原因容器本身的体积会比虚拟机小,创建、销毁、调度的速度也更比传统的虚拟机更快。

容器本身是IaaS层的内容,所以需要结合k8s进行容器的资源调度和编排,来向上层提供PaaS层的服务能力。(当把容器和容器的编排、调度一起谈的时候就会变成Paas概念,当前最火的基于k8s和Docker形成的PaaS容器调度平台)。

容器本身是共享底层的操作系统,同时又能更好的做到CPU、内存、网络等资源的隔离。

DevOps(开发运维一体化)

Development 和Operations 的组合词,核心就是持续集成和持续交付,需要将软件生命周期过程中的从需求开始到设计程序的开发、编译构建打包部署,从测试环境到生产环境整个过程能够实现全部的自动化。同时基于DevOps本身的发展又进一步和敏捷研发和自动化测试相关的最佳实践做了协同和集成。

  • 要点1:指开发、QA和运维三要素如何更好的进行协同,最早的DevOps核心是在CI/CD 持续集成、持续部署,到了DevOps以后把持续集成、持续部署拓展到持续交付。

  • 要点2:当前谈DevOps一般会和Scrum敏捷研发、过程管理一起来谈,因为要做到持续的集成和交付必须要有敏捷的迭代版本和其相配合。

在这里插入图片描述

Immutable Infrastructure(不可变基础设施)

传统的去做软件程序的部署,当部署到生产环境,部署到Tomcat中间件以后,如果要做变更,不管是程序的变更还是配置的变更,都会在原来的生产环境去重新部署或者是对某一个配置直接进行修改。但是在云原生强调的任何一个应用当部署到生产环境,形成一个容器实例以后,这个容器实例本身不应该在做任何的变化,它是不可变的。

如果程序、配置发生修改了要基于容器镜像重新去新生成一个容器实例,同时把旧的容器实例销毁。

Declarative-API(声明式API)

声明式API是和命令式操作相对应的概念,传统的创建一个容器需要执行一个命令行,在声明式API时代下,对于容器的创建首先去写一个yaml配置文件,在配置文件声明要做什么事情,同时做完事情以后期望达到什么状态,只需要把配置文件写好。第二步在平台拿到这个声明式配置文件后,再去解释这个声明式API文件的内容,再去做相应的后端操作,同时操作完以后把各个底层的技术组件协调到需要的状态。

声明式API下面,任何对生产环境、对软件的修改都不是直接去操作一个命令,都是要先写声明、先写配置,写好的这份声明(yaml文件)是可以纳入配置管理里面集中做管控、管理的。方便当生产环境出现问题的时候能够快速去追溯之前对生产环境做过什么样的操作,方便做相关的回退、回滚操作。

在这里插入图片描述

Serverless(无服务器架构)

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

Serverless带来的另外一个变化是:在传统的云原生架构开发下,基于DevOps、微服务和容器云开发应用仍然会选择一个开发框架,仍然会涉及到开发应用的数据层、逻辑层以及上层的展现层,例如三层架构、五层架构。到了Serverless无服务器化以后,开发框架、开发环境、多层架构这些内容全部抛弃。

任何一个功能的实现的核心全部变成一个个代码片段,通过各个代码片段去实现功能。通过代码片段组合、组装来实现复杂业务流程,这是Serverless 未来期望 达到的效果。这一块在Serverless里边对于FaaS层(Function as a Service)功能函数即服务。

注意:Serverless 是指 “无服务器架构”,这里的 “无服务器” 并不是指程序不需要服务器运行,而是指我们的开发工作不需要关注服务器底层的资源。

在这里插入图片描述
在这里插入图片描述

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

在这里插入图片描述
云的时代,硬件软件化软件服务化 成为最显著的两个趋势。

在这里插入图片描述
Serverless包含要素:

  • Serverless 计算是 全托管 的计算服务,客户编写代码构建应用,无需管理和运维服务器等底层基础设施。

  • Serverless 计算是通用、普适的,结合云 API(BaaS 服务)的能力,能够支撑云上所有重要类型的应用。

  • Serverless 计算不但实现了最纯粹的 按需付费(为代码实际运行消耗的资源付费),也应当支持预付费等计量模式,使得客户成本在各种场景下,与传统方式相比都极具竞争力。

  • 不同于虚拟机或容器等面向资源的计算平台,Serverless 计算是面向应用的。要能整合和联动云的产品体系及其生态,帮助用户在价值交付方式上实现颠覆式创新。

对比项自建服务Serverless
任务处理效率取决于用户自建系统的弹性和任务调度的效率, 在大量任务涌入时通常需要排队延时处理与弹性计算等底层资源联动, 实时伸缩, 任务及时处理。配合 Serverless 工作流可实现复杂的任务编排。支持不同任务计算资源随时动态调整, 轻松实现任务优先级处理。
成本取决于用户自建系统任务调度和资源管理的效率资源利用率通常比用户自建高10%-30%, 成本更有优势
开发除了必要的业务逻辑开发, 还需要实现任务处理系统, 确保任务的可靠执行只需要专注业务逻辑的开发, 一键应用部署
运维需要用户从头到尾搭建, 包括相关软件的安装、服务配置、安全更新等一系列问题免运维, 并且提供强大的问题诊断和数据可视化能力
项目上线周期保守估计大约 30 人天, 包括硬件采购、软件和环境配置、系统开发、测试、监控报警、灰度发布系统等预计 3 人天, 开发调试(2人天) + 压测观察(1人天)

腾讯云云函数收费规则

在这里插入图片描述
在这里插入图片描述
以腾讯云为例部署一个website:

  • 进入Serverless应用,新建应用

在这里插入图片描述

  • 选择静态网站(之前是有SpringBoot应用的,部署website的时候也是各种报错,好在终于成功了)

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

  • 部署完成

在这里插入图片描述

  • 访问效果

在这里插入图片描述

  • 你的项目中有变动的话可进行 更新应用 操作

在这里插入图片描述
在这里插入图片描述
这里只是随便写个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个函数,分散各地,怎么去排查?

  • 无服务器仍然不成熟,还没有建立架构模型和健壮的开发工具。

  • 完全依赖于第三方服务。

Service Mesh(服务网格)

一个去中心化的服务治理框架。原来需要对服务、Api接口进行治理和管控,一般会用API网关将api接口注册和接入到api网关,由于 API网关本身是一个中心化的架构 ,所以所有的请求流量都可以通过API网关,这个时候API网关就很容易对流量进行拦截,同时对拦截以后的流量进行安全、日志、限流、熔断、链路监控等各种管控治理。

当在去中心化的架构下面就没有这种集中化的流量管控点 ,所有对于流量的拦截就从API网关下沉到各个微服务中去,这就意味着需要在每个微服务端增加一个代理包,通过代理包来做流量的拦截,同时实现对流量的管控。当前在微服务服务网格的微服务治理里面也是同样的思路,例如开源Istio微服务治理框架,它会在为服务端下方一个sidecar(边车)代理,通过代理实现流量的拦截和管控。

去中心化的治理仍然会有一个控制中心,控制中心仍然是中心化的,但是 实际的控制流和接口数据访问的消息流实现了分离,控制流只管服务的注册发现,实际的接口调用、服务访问是不通过控制中心的,即使控制中心宕机也不会影响到接口服务的调用

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

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

当前微服务面临的问题:

  • 1.虽然框架本身屏蔽了分布式系统通信的一些通用功能实现细节,但开发者却要花更多精力去掌握和管理复杂的框架本身,在实际应用中,去追踪和解决框架出现的问题也绝非易事;

  • 2.开发框架通常只支持一种或几种特定的语言,微服务一个重要的特性就是语言无关(没有最好的编程语言, 只有最适合某一场景的编程语言,尤其是AI的兴起,一般大型互联网公司存在 C/C++、Java、Golang、PHP、Python、NodeJs 等语言的项目),但那些没有框架支持的语言编写的服务,很难融入面向微服务的架构体系,想因地制宜的用多种语言实现架构体系中的不同模块也很难做到,这对微服务环境下不同语言开发提出了很大的挑战;

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

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

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

维基百科

在软件架构中,服务网格是一个专用的基础设施层,用于使用代理促进服务或微服务之间的服务到服务通信。专用通信层可以提供许多好处,例如提供对通信的可观察性,提供安全连接,或自动重试和回退失败的请求。

服务网格由与应用程序中的每个服务配对的网络代理和一组任务管理流程组成。代理称为数据平面,管理进程称为控制平面。数据平面拦截不同服务之间的调用并“处理”它们;控制平面是网格的大脑,负责协调代理的行为,并为运维人员提供API 来操作和观察整个网络

在云原生的技术体系之下,容器化已经成为了开发者部署应用的第一选择,在这种上下文之下Kubernetes又是首选的容器编排和调度系统。不过在k8s和容器化极大简化了应用部署之下,仍然有有一个能力需要开发者深度参与进来,那就是服务的治理能力。

服务网格最初脱胎于简化服务和解耦服务治理能力的需求。核心概念就是把服务治理的能力从开发者的代码中抽象出来放到一个单独的sidecar代理中实现,通过为每个服务的工作负载注入sidecar代理服务网格极大简化了服务治理的操作。

同时也将和开发者的代码进行解耦,从此之后开发者只需要关注业务代码而运维人员只需要操作网格里的sidecar就可以实现服务的治理,可以说服务网格是云原生时代下服务治理能力的大势所趋。

在服务网格中,请求将通过所在基础架构层中的代理在微服务之间路由。正因如此,构成服务网格的各个代理有时也被称为"Sidecar"(边车),这是因为它们与每个服务并行运行,而非在内部运行

所以说,这些"Sidecar"代理(与每项服务分离)构成了 网格式网络,同时又与微服务相互协作。作为处理服务间通信的基础设施层,Service Mesh 可以帮助开发者从服务通信问题的困境中解脱出来,节省了开发和维护通信控制逻辑的繁重工作,,所以有些人将 Service Mesh 称作第二代微服务。

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

服务网格的几个特点:

  • 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中文社区

结语

写这篇文章的目的只是为了阐述云原生组件的应用场景及产生的变化; 虽然云原生确实简化了项目后期的绝大多数问题。

但在这里我有必要提醒你

  • 新技术的产生确实解决了某些痛点, 但是你在引入的时候需要注意是否会衍生出其他问题, 想好后续的解决方案。

  • 你在做个人项目的时候可以随意炫技(使用各种新技术), 这是程序员学习之路的重要一环; 但是你在实际企业级的项目中就不太合适了(企业应用考虑的是稳定性), 这时你需要结合实际找到最稳妥的处理方式。不要为了技术而技术!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/795030.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

LeetCode:1026. 节点与其祖先之间的最大差值(DFS Java)

目录 1026. 节点与其祖先之间的最大差值 题目描述&#xff1a; 实现代码与解析&#xff1a; DFS 原理思路&#xff1a; 1026. 节点与其祖先之间的最大差值 题目描述&#xff1a; 给定二叉树的根节点 root&#xff0c;找出存在于 不同 节点 A 和 B 之间的最大值 V&#xff…

11-1(2)-CSS 背景+CSS 精灵图

个人主页&#xff1a;学习前端的小z 个人专栏&#xff1a;HTML5和CSS3悦读 本专栏旨在分享记录每日学习的前端知识和学习笔记的归纳总结&#xff0c;欢迎大家在评论区交流讨论&#xff01; 文章目录 一、CSS 背景1 背景颜色2 背景色半透明3 背景图片4 背景平铺5 背景图片位置6 …

深度剖析:网络安全中的红蓝对抗策略

红蓝对抗 红蓝对抗服务方案 在蓝队服务中&#xff0c;作为攻击方将开展对目标资产的模拟入侵&#xff0c;寻找攻击路径&#xff0c;发现安全漏洞和隐患。除获取目标系统的关键信息&#xff08;包括但不限于资产信息、重要业务数据、代码或管理员账号等&#xff09;外&#x…

如何在iPhone上恢复永久删除的照片?

2007 年&#xff0c;Apple Inc. 推出了这款震撼人心的智能手机&#xff0c;后来被称为 iPhone。您会惊讶地发现&#xff0c;迄今为止&#xff0c;Apple Inc. 已售罄 7 亿台 iPhone 设备。根据 2023 年 8 月的一项调查数据&#xff0c;95% 的智能手机利润都落入了苹果公司的口袋…

跨平台的组播测试工具mping、udp_sender及udp_reciver的源码及使用教程

文章目录 1.前言2.mping工具编译3.mping工具使用3.1 参数说明3.1 组播播发&#xff08;-s&#xff09;3.1 组播播发&#xff08;-r&#xff09;3.3 Linux下mping测试 4.Linux组播udp_sender及udp_reciver使用4.1 udp_sender源码4.1 udp_reciver源码4.3 编译方法4.4 测试使用4.4…

android11 SystemUI入門之KeyguardPatternView解析

view层级树为&#xff1a; 被包含在 keyguard_host_view.xml中 。 <?xml version"1.0" encoding"utf-8"?> <!-- This is the host view that generally contains two sub views: the widget viewand the security view. --> <com.andro…

并发编程01-深入理解Java并发/线程等待/通知机制

为什么我们要学习并发编程&#xff1f; 最直白的原因&#xff0c;因为面试需要&#xff0c;我们来看看美团和阿里对 Java 岗位的 JD&#xff1a; 从上面两大互联网公司的招聘需求可以看到&#xff0c; 大厂的 Java 岗的并发编程能力属于标配。 而在非大厂的公司&#xff0c; 并…

Ubuntu22.04中基于Qt开发Android App

文章目录 前言在Ubuntu22.04中配置开发环境案例测试参考 前言 使用Qt开发手机应用程序是一种高效且灵活的选择。Qt作为一个跨平台的开发框架&#xff0c;为开发者提供了统一的开发体验和丰富的功能库。首先&#xff0c;Qt的跨平台性让开发者可以使用相同的代码库在不同的操作系…

Error: TF_DENORMALIZED_QUATERNION: Ignoring transform forchild_frame_id

问题 运行程序出现&#xff1a; Error: TF_DENORMALIZED_QUATERNION: Ignoring transform for child_frame_id “odom” from authority “unknown_publisher” because of an invalid quaternion in the transform (0.0 0.0 0.0 0.707) 主要是四元数没有归一化 Eigen::Quatern…

【PostgreSQL】技术传承:使用Docker快速部署PostgreSQL数据库

前言 PostgreSQL的重要贡献者Simon Riggs因一起坠机事故不幸离世。Simon Riggs是英国著名的软件与服务领导者&#xff0c;也是PostgreSQL的主要开发者和贡献者。事故发生在英国当地时间3月26日13:41分&#xff0c;当时他驾驶的私人通用航空Cirrus SR22飞机在英国达克斯福德机场…

java——文件上传

一、文件上传——简介 文件上传的简介&#xff1a;文件上传是指将本地计算机中的文件传输到网络上的服务器或另一台计算机上的过程。在 Web 开发中&#xff0c;文件上传通常指的是将用户通过 Web 页面提交的文件&#xff08;如图像、文档、音频、视频等&#xff09;传输到服务器…

设计模式总结-原型设计模式

原型设计模式 模式动机模式定义模式结构模式分析深拷贝和浅拷贝原型模式实例与解析实例一&#xff1a;邮件复制&#xff08;浅克隆&#xff09;实例二&#xff1a;邮件复制&#xff08;深克隆&#xff09; 模式动机 在面向对象系统中&#xff0c;使用原型模式来复制一个对象自…

MySQL 50 道查询题汇总,足以巩固大部分查询(附带数据准备SQL、题型分析、演示、50道题的完整SQL)

目录 MySQL 50 道查询题&#xff0c;足以巩固大部分查询数据准备&#xff1a;创建表sql添加表数据sql 50道查询题目汇总01 - 05 题&#xff1a;1、查询 “01” 语文成绩比 “02” 数学成绩高的学生的信息及课程分数2、查询 "01语文课程"比"02数学课程"成绩…

Linux云计算之网络基础9——园区网络架构项目

要求构建大型园区网络架构&#xff0c;方案如下&#xff1a; 园区A 园区c 公司B 要求&#xff1a; 1、A公司园区网络 一台汇聚层三层交换机&#xff0c;两台接入层二层交换机。 出口有一台路由器。 2、A园区有五台服务器。 分别为两台 WEB 服务器&#xff0c;…

java数据结构与算法刷题-----LeetCode405. 数字转换为十六进制数

java数据结构与算法刷题目录&#xff08;剑指Offer、LeetCode、ACM&#xff09;-----主目录-----持续更新(进不去说明我没写完)&#xff1a;https://blog.csdn.net/grd_java/article/details/123063846 文章目录 分组位运算 分组位运算 这道题正常来说可以用转换7进制的思想来&…

PTA C 1050 螺旋矩阵(思路与优化)

本题要求将给定的 N 个正整数按非递增的顺序&#xff0c;填入“螺旋矩阵”。所谓“螺旋矩阵”&#xff0c;是指从左上角第 1 个格子开始&#xff0c;按顺时针螺旋方向填充。要求矩阵的规模为 m 行 n 列&#xff0c;满足条件&#xff1a;mn 等于 N&#xff1b;m≥n&#xff1b;且…

【蓝桥杯-读数据】

蓝桥杯-读数据 P8598 [蓝桥杯 2013 省 AB] 错误票据 P8598 [蓝桥杯 2013 省 AB] 错误票据 这道题本身很简单&#xff0c;最大的难点在于读入数据。 #include<bits/stdc.h> using namespace std; #define int long long const int N 2e5 10; int a[N]; signed main()…

探寻马来西亚服务器托管的优势与魅力

随着全球跨境业务的不断增加&#xff0c;境外服务器成为越来越受欢迎的选择。在这其中&#xff0c;马来西亚服务器备受关注&#xff0c;其机房通常位于马来西亚首都吉隆坡。对于客户群体主要分布在东南亚、澳大利亚和新西兰等地区的用户来说&#xff0c;马来西亚服务器是一个理…

SV学习笔记(七)

类型转换 写在前面 类型转换可以分为 静态转换和动态转换 。静态转换即需要在转换的表达式前 加上单引号 即可&#xff0c;该方式并不会对转换值做检查。如果发生转换失败&#xff0c;我们也无从得知。动态转换即需要使用 系统函数$cast(tgt&#xff0c; src) 做转换。静态转…

CountDownLatch 详解

CountDownLatch 用法详解 CountDownLatch 详解1 原理2 常见用法3 方法介绍4 示例及使用 CountDownLatch 详解 CountDownLatch&#xff08;倒计时门闩&#xff09;是Java并发包中的一个工具类&#xff0c;用于协调多个线程之间的同步。它允许一个或多个线程等待其他线程完成操作…