云原生
文章平均质量分 94
夜雨风云
求实求真
展开
-
Kafka架构概述
Kafka是由Apache软件基金会管理的一个开源的分布式数据流处理平台。Kafka具有支持消息的发布/订阅模式、高吞吐量与低延迟、持久化、支持水平扩展、高可用性等特点。可以将Kafka应用于大数据实时处理、高性能数据管道、流分析、数据集成和关键任务应用等场景。原创 2024-04-02 23:47:04 · 1702 阅读 · 1 评论 -
Kubernetes编排概述
Kubernetes是由谷歌开源的面向应用的容器集群部署和管理的系统,为容器化应用提供了资源调度、部署运行、服务发现、扩缩容等一整套功能。Kubernetes最主要的设计思想就是,以统一的方式抽象底层基础设施能力,定义任务编排的各种关系,将这些抽象以声明式API的方式对外暴露,从而允许平台构建者基于这些抽象进一步构建自己的PaaS乃至任何上层平台。Kubernetes的目标旨在消除编排物理/虚拟计算、网络和存储等基础设施的负担,并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。原创 2024-02-27 11:40:27 · 856 阅读 · 0 评论 -
云原生概述
云原生已经成为业内开发主流,对于一些大型企业,云原生应用已经成为事实标准。本文关注于什么是云原生,云原生涉及的领域,云原生实践需要注意的因素。原创 2022-05-22 23:38:35 · 1406 阅读 · 1 评论 -
深入联合文件系统
Union File System(联合文件系统,UnionFS)是一种轻量级的高性能分层文件系统,它支持将文件系统中的修改信息作为一次提交,并层层叠加,同时可以将不同目录挂载到同一个虚拟文件系统下,应用看到的是挂载的最终结果。联合文件系统将多个文件系统层以一种有效的方式组合在一起,形成了一个单一的可读写的文件系统。联合文件系统是实现Docker镜像的技术基础。原创 2024-03-13 10:09:40 · 999 阅读 · 0 评论 -
Dockerfile指令大全
Dockerfile文件由一系列指令和参数组成。指令的一般格式为INSTRUCTION arguments。具体来说,包括"配置指令"(配置镜像信息)和"操作指令"(具体执行操作)。每条指令,如FROM,都是大小写不敏感的。但是为了区分指令和参数,强烈建议统一使用大写字母。Dockerfile中的指令会按顺序从上到下执行,所以应根据需要合理安排指令的顺序。一个Dockerfile文件以FROM指令作为构建开始的第一个指令。每条指令都会创建一个新的镜像层并对镜像进行提交。原创 2024-03-10 21:53:29 · 941 阅读 · 0 评论 -
Dockerfile编写实践篇
Dockerfile是一个文件,它由构建镜像的指令组成,用户可以使用Dockerfile来快速创建自定义的镜像。指令由Docker镜像构建者自上而下排列,能够被用来修改镜像的任何信息。 Dockerfile具有信息表达性,且易于理解,这些都要归功于Dockerfile支持注释的简洁语法。开发者可以使用任何版本控制工具来跟踪Dockerfile文件的变动。维护多个版本的镜像就和管理多个Dockerfile一样简单。原创 2024-03-10 21:52:43 · 1487 阅读 · 0 评论 -
Docker常见命令使用
Docker命令是使用Docker的基础。这里记录下Docker日常运维过程中经常使用到的一些命令,更全面的命令还请参考Docker官网。原创 2024-03-05 20:03:43 · 1318 阅读 · 0 评论 -
容器化技术
容器化技术并不是由Docker引入,而是有其发展历程。容器有效地将由单个操作系统管理的资源划分到孤立的组中,以更好地在孤立的组之间平衡有冲突的资惊使用需求。容器可以在核心CPU运行指令,而不需要任何专门的解释机制。容器避免了准虚拟化(para-virtualization)和系统调用替换中的复杂性。原创 2024-03-05 10:58:38 · 1007 阅读 · 0 评论 -
Docker架构概述
Docker是基于Go语言实现的开源容器项目,能够把开发的应用程序自动部署到容器的开源的应用容器引擎。Docker的构想是要实现"Build, Ship and Run Any App, Anywhere",即通过对应用的封装(Packaging)、分发(Distribution)、部署(Deployment)、运行(Runtime)生命周期进行管理,达到应用组件级别的"一次封装,到处运行"。可以说,Docker首次为应用的开发、运行和部署提供了"一站式"的实用解决方案。原创 2024-03-03 21:22:01 · 1029 阅读 · 0 评论 -
Docker与虚拟机比较
在对比Docker和虚拟机前,先简单了解下虚拟化,明确Docker和虚拟机分别对应的虚拟化级别,然后对Docker和虚拟机进行比较。需要注意的是,Docker和虚拟机并没有什么可比性,而是Docker使用的容器技术和虚拟机使用的虚拟化技术的比较。原创 2024-03-01 16:15:45 · 1248 阅读 · 0 评论 -
Docker概述
Docker是基于Go语言实现的开源容器项目,由Docker公司的团队编写,能够把开发的应用程序自动部署到容器的开源的应用容器引擎。使用Docker后,开发人员只需要关心容器中运行的应用程序,而运维人员只关心如何管理容器,Docker的设计目的就是要加强开发人员写代码的开发环境与应用程序要部署的生产环境的一致性,从而降低那种"开发时一切都正常,肯定是运维的问题"的风险。原创 2024-03-01 16:15:22 · 1220 阅读 · 0 评论 -
Kubernetes 声明式API
声明式API践行了"将简单留给用户,将复杂流程系统"的设计理念。对于用户来说,只需掌握API对象的使用,无需关心内部的实现细节。系统会使用控制器模式将资源对象调谐到API对象指定的"期望状态"。声明式API是Kubernetes最核心的设计理念,正因为实现了对声明式API的支持,才可在基于Kubernetes构建的上层平台使用一致的编程范式和交互编程界面,才使得今天整个云原生生态中诞生了如此多的Kubernetes插件能力和扩展。原创 2024-02-23 15:45:59 · 1054 阅读 · 0 评论 -
Kubernetes 控制器
在Kubernetes中,所有的控制器都是由Kubernetes Controller Manager统一管理。可以将Kubernetes Controller Manager看成一系列控制器的集合。在Kubernetes中,每一个控制器都以独有的方式负责某种编排功能,并遵循一种通用的编排模式————控制循环(Control Loop,也称控制回路)或调谐循环(Reconcile Loop)或同步循环(Sync Loop)。原创 2024-02-23 13:22:52 · 990 阅读 · 0 评论 -
Kubernetes API对象
API对象(也常被称作对象)是Kubernetes中的管理操作单元。Kubernetes系统每支持一项新功能,引入一项新技术,一定会新引入对应的API对象,支持对该功能的管理操作。也就是说,API对象可以帮助实现特定功能的管理操作。如Kubernetes最常用的Pod负责一个或多个容器的管理,Deployment负责Pod副本的部署、升级和回滚、扩容和缩容等自动化运维。API对象是一种"意向表达(Record of Intent)"。原创 2024-02-03 18:52:45 · 927 阅读 · 0 评论 -
Kubernetes Pod使用
Pod是Kubernetes中可以创建、调度和部署的最小,也是最简单的单元。Pod是基于Kubernetes部署和运维应用的基础。本文重点介绍下Pod各字段的含义及Pod的使用。原创 2024-02-03 18:51:54 · 1053 阅读 · 0 评论 -
Kubernetes Service详解
Service是Kubernetes实现微服务架构的核心概念,通过创建Service,可以为一组具有相同功能的容器应用提供一个统一的入口地址,并且将请求以负载均衡的方式分发到后端的各个容器应用上。原创 2024-01-30 17:21:17 · 1043 阅读 · 0 评论 -
Kubernetes HPA使用
在生产环境中,经常会遇到由于业务发展迅速需要增加某个服务实例数量的场景,也可能会遇到由于资源紧张或者工作负载降低而需要减少服务实例数量的场景。Kubernetes对Pod的扩缩容操作提供了手动和自动两种模式,手动模式通过运行kubectl scale命令或通过修改ReplicaSet中Pod副本数量的方式实现。自动模式则需要用户根据某个性能指标或者自定义业务指标,并指定Pod副本数量的范围,系统将自动在这个范围内根据性能指标的变化进行调整。这里介绍下自动模式,也即Kubernetes HPA的使用。原创 2024-01-30 17:19:37 · 1096 阅读 · 0 评论 -
Kubernets Deployment详解
Deployment自动化的完成了Pod副本的部署、升级和回滚、扩容和缩容等运维能力。开发者只需在 Deployment声明文件中描述期望状态,然后 Deployment Controller 就会自动将 Pod 从实际状态改变到期望状态。Deployment提供了运行Pod的能力,并且为Pod提供副本管理、升级和回滚、水平扩容和缩容等功能,一般用于运行无状态的应用。原创 2024-01-25 20:10:47 · 897 阅读 · 0 评论 -
Kubernetes Pod详解
如果说容器是未来云计算系统中的进程,容器镜像是这个系统里的安装包,那么Kubernetes就是云计算系统的操作系统。而Pod就是基于容器技术的操作系统里的"进程组",负责一个或多个容器的管理。Pod 是Kubernetes中可以创建、调度和部署的最小也是最简单的单元。一个Pod里可以封装一个容器或多个容器(多个容器间可能存在拓扑关系–也即依赖关系),Pod里的容器共享存储、网络、容器运行配置等。同一个Pod里的所有容器都被统一安排和调度,所以可将Pod看成是对容器的编排。原创 2024-01-25 09:30:00 · 1095 阅读 · 0 评论 -
Kubernetes架构概述
Kubernetes 是由谷歌开源的面向应用的容器集群部署和管理的系统,为容器化应用提供了资源调度、部署运行、服务发现、扩缩容等一整套功能。Kubernetes 最初来源于谷歌内部的Borg。Kubernetes 的目标旨在消除编排物理/虚拟计算,网络和存储基础设施的负担,并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。原创 2024-01-19 10:57:00 · 909 阅读 · 0 评论 -
Kubernetes网络模型概述
Kubernetes网络模型设计的一个基础原则是:每个Pod都拥有一个独立的IP地址,并假定所有Pod都在一个可以直接连通的、扁平的网络空间中。所以不管这些Pod是否运行在同一个Node中,都要求它们可以直接通过对方的IP进行访问。由于Kubernetes的网络模型假设Pod之间访问时使用的是对方Pod的实际地址,所以一个Pod内部的应用程序看到的自己的IP地址和端口与集群内其他Pod看到的一样。原创 2024-01-17 17:44:39 · 1159 阅读 · 0 评论 -
kubectl命令行工具用法简介
kubectl作为客户端CLI工具,可以让用户通过命令行对Kubernetes集群进行操作。本节对kubectl的子命令和用法进行详细说明。原创 2024-01-05 17:39:34 · 1115 阅读 · 0 评论 -
服务网格概述
服务网格是一种在分布式(如微服务)软件系统内管理所有服务对服务(东西向)流量的基础设施层。服务网格负责构成现代云原生应用的复杂服务拓扑来可靠地交付请求。服务网格既提供以业务为重点的功能操作,如路由,也提供非功能支持,如执行安全策略、服务质量和速率限制。它通常(尽管不是唯一的)使用 sidecar 代理来实现,所有服务都通过 sidecar 代理进行通信。sidecar 作为轻量级网络代理,与应用程序代码部署在一起,对应用程序来说无需感知其存在。原创 2023-09-26 11:49:52 · 170 阅读 · 0 评论 -
数据库设计规范
现代软件架构的复杂性要求需要多人或多团队协同完成开发。在这种背景下,如何高效地协同完成软件的开发呢?对软件工程来说,数据库设计规范是在数据库设计层面对软件开发者的规范或标准。对软件来说,适当的规范和标准绝不是为了消除代码内容的创造性、优雅性,而是**限制过度个性化,并以一种普遍认可的统一方式一起做事,提升协作效率,降低沟通成本**。代码的字里行间流淌的是软件系统的血液,质量的提升是**尽可能少踩坑,杜绝踩重复的坑**,切实提升系统稳定性,码出质量。原创 2022-11-06 18:27:35 · 2024 阅读 · 0 评论 -
分布式系统(Distributed Systems)概述
随着互联网的持续发展(以Web应用为代表)、计算机应用的深入、分布式系统构建技术的日益成熟,分布式系统逐渐深入到人们的日常生活,并渗透到社会、经济、文化生活的各个方面。现如今,分布式系统已成为主流的软件系统。本文主要介绍下分布式系统的特征和在进行分布式系统设计过程中所必须解决的问题:可伸缩性、异构性、安全性和故障处理等。原创 2022-11-05 19:39:52 · 8555 阅读 · 3 评论 -
分布式事务(Distributed Transactions)概述
分布式事务是分布式领域必须要面对的问题,同时也是衡量一个分布式系统成熟度的重要指标。那么什么是分布式事务,哪些场景会涉及到分布式事务,如何实现分布式事务?本文将重点讨论以上问题。原创 2021-04-25 23:53:19 · 886 阅读 · 0 评论 -
分布式锁(Distributed Lock)理论介绍
在多线程环境中,线程之间通常使用互斥锁实现共享资源的独占访问。在多进程环境,特别是分布式环境,常使用分布式锁来实现共享资源的独占访问。简单来说,分布式锁就是指在分布式环境下,通过加解锁实现多节点对共享资源的互斥访问。原创 2022-10-16 23:33:51 · 4086 阅读 · 0 评论 -
BASE理论
BASE理论是Dan Pritchett于2008年在CAP 理论的基础上提出的。BASE 理论是对 CAP理论中AP方案的一个补充。Base理论强调即使系统无法做到强一致性(Strong Consistent),但每个应用都可以根据自身业务特点,使用适当的方法来使系统达到最终一致性(Eventually Consistent)。原创 2022-10-16 15:01:51 · 1467 阅读 · 1 评论 -
可靠/可用性介绍
可靠/可用性主要目的是保护业务零中断和高用户体验。原创 2022-09-04 19:43:25 · 6056 阅读 · 0 评论 -
API Gateway介绍
APIGateway是一种服务,作为从防火墙外部进入微服务应用的唯一入口点。它类似于面向对象设计中的外观(Facade)模式。APIGateway封装了应用的内部架构,并为其客户端提供API。它还可能具有其他职责,如身份认证、流量监控和速率限制。......原创 2022-07-24 20:04:30 · 8148 阅读 · 4 评论 -
微服务测试
传统应用(基于单体架构开发的应用)的测试通常在开发完成后执行。传统的测试大多是手动执行,但存在手动测试效率极低、代价高等问题。使用微服务架构的一个关键动机是提高可测试性。但微服务架构的复杂性对测试提出了更多的挑战。......原创 2022-07-17 22:33:08 · 2159 阅读 · 0 评论 -
微服务部署
微服务应用开发完毕后,接下来要做的就是将已开发好的微服务应用部署到环境中。部署包含两个相互关联的概念:流程和架构。部署流程包括一些由开发人员和运维人员执行的步骤,以便将软件投入到生产环境(商用环境,任何修改都会影响到用户)。部署架构则定义了该软件运行的环境结构。随着自动化、虚拟化技术的发展和完善,早先将代码构建产物手动部署生产环境的历史,已经逐渐被基于流水线自动化部署替代,之前由物理机组成的生产环境,也已逐渐被轻量级、短生命周期的计算基础设施取代。 ...原创 2022-07-10 20:10:39 · 5982 阅读 · 0 评论 -
鸿沟理论(The Chasm Theory)介绍
鸿沟理论由Jeffery Moore(杰弗里 摩尔)于1991年提出,距今已有 30 年时间,但该理论至今依然奏效,另外该理论也在 CNCF 项目的中得到应用。本文将介绍”鸿沟理论“相关的一些知识,希望能够引发大家对技术选型、新技术推广的一些思考。...原创 2022-07-10 20:02:43 · 7149 阅读 · 0 评论 -
微服务注册与发现
微服务架构下多服务间通信,需要解决的一个问题就是如何实现服务发现。本文将从为什么需要服务发现、什么是服务发现、如何实现服务发现等四个方面对其进行简要介绍。原创 2022-07-03 15:23:13 · 1569 阅读 · 3 评论 -
微服务间通信
微服务架构基于多个服务构建应用,这些服务必须经常协作才能处理各种外部请求。因为服务实例通常是在多台机器上运行的进程,所以它们必须使用进程间通信进行交互。因此,进程间通信技术在微服务架构中比单体架构中扮演着更重要的角色。本文将探讨各种进程间通信机制,并讨论如何进行权衡。注意,需要牢记“没有银弹”这个大原则。 选择合适的进程间通信机制是一个重要的架构决策。它会影响应用程序可用性。更重要的是,进程间通信甚至与实务管理相互影响。一个理想的微服务架构应该是在内部由松耦合的若干服务组成,这些服务使用异步消息相互通信原创 2022-07-03 15:15:21 · 4954 阅读 · 3 评论 -
微服务拆分
微服务拆分是落地微服务架构的关键。然而,世界上并没有一个机械化的流程可以遵守,然后指望这个流程输出一个合理的架构。这里只能介绍一个笼统的方法,现实世界中,这是一个不断迭代和持续创新的过程。跟所有的软件开发一样,微服务拆分是一项艺术而非技术。 ...原创 2022-06-26 23:10:06 · 2631 阅读 · 0 评论 -
软件架构介绍
架构显然很重要。许多开发人员的目标是成为一名架构师。但什么是架构,为什么架构如此重要?为了回答这个问题,这里首先定义软件架构的含义。然后,讨论应用程序的架构是多维的,并使用一组视图或蓝图进行描述。接着,本文将强调软件架构的重要性,因为它对应用程序的质量有显著的影响。 ...原创 2022-06-19 20:49:13 · 4908 阅读 · 0 评论 -
微服务架构演进
本文主要介绍微服务架构是如何演进而来。微服务架构从单体架构演进而来。在单体应用相对较小时,应用的开发、测试和部署相对简单,但随着时间的推移,更多的功能被添加到应用中,代码的规模也进一步增长。作为功能扩展的结果,单体应用很快陷入单体地狱。开发变得缓慢和困难,因为系统本身过于庞大和复杂,以至于任何一个开发者都很难理解它的全部。这种复杂性逐渐形成一个恶性循环:由于代码库太难于理解,因此开发人员在更改时更容易戳错,且每一次更改都会让代码库变得更复杂、更难懂。针对大型复杂单体应用的开发,越来越的共识趋向于使用微服务架原创 2022-06-12 23:56:41 · 1575 阅读 · 3 评论 -
微服务概念及介绍
本文主要介绍什么是微服务、微服务的特征有哪些,微服务的优点及缺点原创 2022-05-29 22:54:24 · 2123 阅读 · 0 评论 -
分布式计算的八大谬论
分布式计算的八个谬论在四十多年已提出,但是这八个谬论在如何仍有极大的参考意义,尤其是分布式应用盛行的今天。原创 2022-05-22 23:43:31 · 712 阅读 · 0 评论