之乎者也·的博客

存算分离已成为流行的架构理念，通过存算分离可以提高数据库的弹性能力，降低存储成本、提高可用性。GaiaDB 在架构演进中采用 Quorum 分布式协议和高性能网络技术降低计算和存储之间的访问延迟，提高并发访问性能；通过高可靠的分布式存储引擎实现 RPO=0，同时利用分布式存储的扩展性提升 I/O 带宽和并发性能。

云原生技术通过容器、微服务、DevOps和持续集成/持续部署（CI/CD）、服务网格等技术，实现了软件开发和部署的高效、可靠和可扩展。这些技术共同支持了一个灵活、动态的云计算环境，使得应用可以在最适合的时刻以最适合的规模运行。

在部署上云服务中，做存算分离是云原生实践架构的基本门槛。存指的是数据的存储，云原生架构中根据结构和读写需求的不同，数据会放在数据库或对象存储中，和计算资源分离。在虚拟机里直接跑数据库+文件服务，这不叫云原生实践架构。关于为什么使用对象存储而不是其他，什么情况下应该放对象存储还是放数据库，不是本文要讲的点，如果有兴趣可以阅读下云原生王四条。但很多业务场景下需要的是，所以本文就来详细分享一下如何处理对象存储私有读写，以及附带着分享一些基于资源角色做授权处理的经验。

虽然样本量小，但这项调查表明，向云原生开发过渡中涉及的一些有趣的趋势和一些挑战。需要在这种背景下考虑这项研究的发现：与像云原生计算基金会这样的机构接受的"云原生"的定义相比，研究人员使用的定义明显更广泛。云原生也许正遭受着一个日益模糊的定义——软件开发者和作者马丁·福勒极妙地称之为"语义扩散"。正如Red Hat的高级首席软件工程师Holly Cummins向 The New Stack 表示，"我经常认为我们只是将云原生作为‘现代化和不错’或者‘在 2020 年代建立的’的同义词。

左侧节点被 EgressPolicy 策略命中的 Pod 流量，会通过 iptabels, route, ipset 规则并通过 vxlan 转发到网关节点，然后从网关节点将源 IP 转为 Egress IP 离开集群。稍后可以通过创建 EgressPolicy CR 来选择可使用的 EgressGateway，并通过 label 匹配业务 Pod，使业务流量通过网关节点离开集群。如下图集群 B 中的 Pod 为一组应用，管理员希望右侧同一业务组的 Pod 出集群的流量都使用特定 IP。

突然想写一篇关于eBPF相关的文章，简单的写点部署，功能，解决方案不一定是大家要的，不如把我近些年对这块理解和看法写一写。得益于容器网络接口 （CNI），Kubernetes提供了大量选项来满足咱们的网络需求。经过多年不同场景下的不断迭代，我们面临着对以客户需求为后盾的，高级功能日益增长的需求。Cilium将K8s平台的网络提升到了一个新的水平。大家也都知道，今天有很多CNI选项可用。我们希望坚持使用eBPF，事实证明，eBPF是一项强大的技术，在可观测性、安全性等方面提供了许多好处。

原先冗长、复杂、颇费时费力的技术工作和体力活，现在可以轻轻松松搞定。

定义云原生很多人问：”到底什么是云原生，能否更精确的描述？实际上， 云原生就是最佳路径和实践。更详细的说，云原生为用户提供了以用户友好、灵活、可扩展和可复制的方式，利用云的功能和价值的最佳实践。云原生技术是一种概念， 为软件架构设计，软件设计，软件开发和运维提供了引导和方法论。而基于这样的概念，有以下优势：首先， 它天然的”出生在云端， 生长在云端“。其次，与“云”自然融合，充分利用云的能力，充分发挥“云”的作用。

云原生（Cloud-Native）的概念在国内提及的越来越多，但大部分人对云原生的认识仅限于容器、微服务、DevOps等内容，把容器、微服务、 DevOps就等同于云原生，这显然是不对的。CNCF从其自身的角度定义了云原生技术：云原生技术使企业能够在现代动态环境中构建和运行可扩展的应用程序，如在公共云、私有云和混合云环境中。包括容器、服务网格、微服务、不变的基础设施和声明式API等。采用这些技术可实现系统的松散耦合性、弹性、可管理性和可观察性等。

基于自定义指标的 HPA，自定义指标可以是消息队列长度、增长速率、接口耗时、qps 等，数据源可以是 trace、prometheus、metrics-server 等，然后编写自定义的 scaler 来对接这些不同的数据源。公司基于 loki 建设了服务的日志系统，通过 loki-querier 组件进行分布式的日志查询。它的特点是无查询是基本无资源消耗，当有查询尤其是大查询时，会瞬间需要大量资源，因此很自然的希望借助 K8s 的 HPA 进行弹性扩缩容。

变化与机会总是并存的，对于技术不断变革的今天，机会也一直存在，特别是对于银行科技行业职业生涯来说，没有过硬的技术实力是没法在众多技术人员中出类拔萃的，同时新技术带来变革所产生的机会也是稍纵即逝的，一旦错过将错失多年，而对于那些有技术准备的人来说把握机会的概率相比之下会更大。随着企业改革的不断深入，对于银行业的科技部门来说，市场化需求也在不断加强，面对市场化这一趋势，岗位的考核力度不断加大，特别是新技术的岗位需求度不断加大，传统岗位需求度呈下降趋势，如不能满足趋势的要求，注定是要被淘汰，挑战可想而知；

为了解决这两个问题，目前一个解决思路就是软硬结合，讲云平台的管理进程，如调度管理，网络的虚拟交换机，存储的虚拟存储网关从操作系统进程中剥离出来，让这些进程跑在专门设计的服务器板卡上，这些板卡专门设计的，通常含有定制化的芯片（FPGA），可以进行编程，从而可以保持虚拟化话的优势的同时，使的管理进程和业务进程隔离，避免相互影响；为了解决容器的隔离性上的弱点，安全容器为容器的运行提供了一层沙箱（Sandbox），容器在沙箱中运行的应用程序有自己的内核和虚拟设备，与主机和其它沙箱区分开来。

随着项目的推进，对云计算理解的越来越多，也有了一些自己的体会，再次看云原生的概念的时候，有了新的认知。云原生架构是云原生应用的架构，云原生方法论是实现云原生应用的方法论，云原生程序就是云原生应用，云原生体系就是构建、发布、运行云原生应用的理论、方法、工具、环境、流程、文化等等。应用云原生思想，可以采用微服务架构、容器、DevOps等技术构建轻量、无状态的云原生应用，使应用具备云端部署、可远程访问、弹性、共享、按需自助服务、高可用、与位置无关等特征，使之天生就具备云的基因，适合云环境部署运行。

网络策略（Network Policies）：在Kubernetes等容器编排系统中，可以定义网络策略来控制不同Pod间的网络通信。通过标签选择器来决定哪些Pod可以互相通信。命名空间（Namespaces）：Kubernetes中的命名空间提供了逻辑上的隔离，不同的服务可以在各自的命名空间中运行，从而实现一定程度的网络和资源隔离。服务网格（Service Mesh）：例如Istio等服务网格组件提供细粒度的流量管理和安全策略实施。

那么回到 AIGC 模型推理场景，Fluid 为这个场景带来了许多优化方案。首先，一种常见的挑战是，分布式缓存的使用复杂度高且运行环境差异大。对于 AI 和大数据应用来说，我们可能需要适配多种运行时，例如已经被广泛使用的 Alluxio、Jindo、JuiceFS，以及最新的 Dragonfly。同时，这些应用可能会在各种运行时环境中执行，包括公共云、私有云、边缘云和 Serverless 云。在这样的背景下，Fluid 提供了一种一键部署的解决方案，使各种环境能够无缝衔接。

本文深入地介绍了 Meshery 这一款强大的云原生管理平台，它以直观和高效的方式帮助用户管理和部署服务网格和工作负载。总的来说，借助 Meshery，用户可以更轻松地掌握他们的云原生环境，并探索和扩展 Service Mesh 的可能性。无论你是云原生技术的初学者，还是经验丰富的专家，Meshery 都将是你理想的工具，帮助你更好地发挥云原生技术的潜力！

Promtail用来将容器日志发送到 Loki 或者 Grafana 服务上的日志收集工具该工具主要包括发现采集目标以及给日志流添加上 Label 标签 然后发送给 LokiPromtail 的服务发现是基于 Prometheus 的服务发现机制实现的Loki受 Prometheus 启发的可水平扩展、高可用以及支持多租户的日志聚合系统使用了和 Prometheus 相同的服务发现机制，将标签添加到日志流中而不是构建全文索引。

Q3：Higress 和阿里巴巴的另一款开源网关 Tengine 有哪些不同？

随着企业应用上云越来越多地选择使用容器化方式，容器服务在不同的云厂商中都有大幅度的业务增长，容器服务已经逐步成为云原生时代新的基础设施和最佳使用云资源的入口。容器是随时可以销毁，当容器消失时，数据也会随之消失，因此容器数据的持久化，是必不可少的。存储系统作为承载业务稳定运行的核心组件，在云原生的架构下，也面临着新的挑战。对于数据一致性要求比较高的应用场景，分布式存储的性能可能就稍弱了，因为分布式的结构，数据同步是一个大问题，虽然现在技术一致在进步，但是也不如传统存储设备数据存储方式可靠。

云原生是一个非常抽象的概念，对于云原生往往是用抽象的解释解释抽象，话有些绕，但我想你能理解它的意思，用“不可变基础设施、声明式、弹性“这样的描述会让云原生的概念更加难以理解。，让云提供保姆式服务。不过受限于当时技术，虚拟化始终只是一个概念和对未来的畅想，在虚拟化技术成熟之前，市场一直处于物理机时代，当时如果要启用一个新的应用，需要购买一台或者一个机架的新服务器。Kubernetes 的崛起标志着微服务时代的新篇章，但它并未能完全解决所有的分布式问题，原因在于某些问题位于应用系统与基础设施的交界处，而。

Istio是不是可以替换掉Ingress-controller?开题还是从一个问题入手吧，相信在容器化、Mesh化过程中，我们想替换掉的不仅仅是ingress-controller吧，例如各种ServiceProxy、Api Gateway等，因为云原生架构下有更好的扩展支持，但是请大家先不要急着说答案。下面我们先来看下Tyk博客上的一篇文章节选。标题：“ServiceProxy，ServiceMesh，API gateway 我们怎么选?服务代理、服务网格还是API网关？

微服务的容器与宿主机的监控离不开CPU、内存、磁盘、网卡这些基础的性能指标，对于宿主机的监控来说，我们可以依然使用原始的监控方式，每个宿主机安装一个代理来采集服务器的性能指标，代理在采集性能指标的时候可以打上时间戳和相应的标签来区分不同性能指标的数据维度（metric），然后将监控数据汇总到时间序列数据库，里面的数据可以对接目前一些开源的组件来进行可视化的展示，也可以对接报警服务（结合报警服务的报警策略）进行报警。运维人员可以通过Topology迅速发现某一个服务潜在的问题，并进行下一步的排查并做到预防。

展望未来两三年，云原生网关的发展将主要围绕如下三项能力的完善：全能力网关建设：不局限于南北向流量，网关结合编排、多协议转换能力，去分布式化，应用于东西向流量中。生产级别稳定性保障：聚焦在精准化监控，细粒度观测，提供精准化告警。提升问题快速恢复，确保流量无损。AI 洞察：结合已有的专家经验，结合 LLM 大模型的能力，完善根因分析体系，构建分析平台，更好地做到问题前置，洞察问题及故障。

在保证稳定性的前提下，降本增效目标拆解：保障稳定性建设高可用性：基础组件（Master三大件/Etcd等）高可用、多机房、多集群、Pod 高可用持续进行风险治理：耦合度、故障发现、容量、容灾、变更及可运维性、安全性建设可观测性：Metrics、Logging、Tracing、Events、Chaos、Dashboard、Inspection故障演练：Apiserver 高可用故障演练、Etcd 高可用故障演练、双机房切换故障演练。

随着云计算、微服务和容器化技术的快速发展，现代应用程序的架构变得越来越复杂。这种复杂性为运维人员和开发者带来了新的挑战，特别是在监控、追踪和诊断分布式系统的行为和性能方面。传统的监控工具和框架往往专注于单一的领域，如日志记录、度量收集或分布式追踪。然而，这些工具之间的互操作性和数据标准化程度有限，导致在大规模、多语言的云原生环境中实施全面可观测性变得困难且成本高昂。OpenTelemetry 与 Kubernetes 结合，构建了一套强大的云原生环境下的可观测性解决方案。

大多数情况下，用户使用特权账号并不需要所有的操作权限，根据用户申请操作业务的不同，可实现操作命令的分级处理，不在授权范围的用户操作无效，并对同一时间点其他用户在同一台系统进行监控和统计，对于影响其他用户操作的命令会对用户进行提醒并中止执行，用户不用担心因操作失误产生的风险问题，对运维的体验有明显提升。通过以云平台为核心的现代化 IT 基础架构，企业可以有效提升应用开发和交付效率，简化员工的工作，让员工聚焦业务创新和客户服务，提升企业的市场响应能力和竞争力，将企业的数字化建设和业务升级带入新的发展阶段。

随着微服务架构逐渐成为主流，开发者们开始将多个服务组合在一起来构建应用程序。微服务架构强调服务的独立性和自主性，使得服务间的通信变得复杂。Service Mesh在这种背景下应运而生，为服务间的通信提供了新的解决方案。Service Mesh定义如下：Service Mesh是在基础架构层处理服务间的通讯，实现云原生复杂的服务拓扑情况下的可靠请求分发。在实现上是一组轻量化的网络代理，这些代理透明的部署在应用周边，无需应用感知。

针对使用 GPU 的任务，因每种 GPU 卡的 CPU/内存/显存规格配比都是不一样的，我们定义了针对每种 GPU 卡的 CU 单位，用户只需要选择相应的 CU，填写 CU 数量即可。针对 VPA 的需求，目前 Kubernetes 层面还没有比较稳定的可用功能，因为对一个 Pod 实例做资源规格的调整，会涉及到宿主机上资源账本的管理问题、监控问题，也会涉及到 Pod 的重建/容器重启动作，影响面会比较大，目前社区中依然在讨论。所以为了挖掘出可以用来混部的资源，我们为不同等级的服务设置不同的绑核策略。

云原生、DevOps和平台工程都是十分繁杂的概念，其边界不断延伸，有许多重合的部分。三者的出发点却并不相同，却可以形成有机的整体。

与单体应用相比微服务架构的服务调用链路更加复杂，微服务的拆分虽然提升了系统的总体能力，但同时也增大了级联错误出现的可能性，多个服务之间存在依赖调用，如果某个服务无法及时响应请求，故障向调用源头方向传播，可能引发集群的大规模级联故障，造成整个系统不可用。一旦熔断器开启，之后的一段时间内所有的调用都将直接失败，而不会再请求远程服务。通常情况下，本地限流对保护应用不被高流量冲击有的显著的作用，由于本地限流是作用在每个应用的边车上并进行单点的令牌桶计算，本质是客户端级别的限流方案，无法实施服务级别的整体限流措施。

如何设置资源需求是一个难题，目前往往基于人工经验来填写，用户通常会将 Request 设置得远高于其实际所需的资源使用量，从而保证服务的可靠性，而这种基于人工经验的设置会导致资源在非高峰期的大部分时间被浪费，从而导致资源使用率低下，节点装箱率低等问题。operate 的原意在于成本运营，这个概念相对来说，更强调组织、文化、意识等，它希望 FinOps 将技术，业务，财务等不同角色通过规范的流程，共同的意识和文化，一起来增加云的业务价值。应用的场景包括查看集群消费趋势，消费分布，多周期的观测等。

Hadoop 的诞生改变了企业对数据的存储、处理和分析的过程，加速了大数据的发展，受到广泛的应用，给整个行业带来了变革意义的改变；随着云计算时代的到来， 存算分离的架构受到青睐，企业开开始对 Hadoop 的架构进行改造。今天与大家一起简单回顾 Hadoop 架构以及目前市面上不同的存算分离的架构方案，他们的利弊各有哪些，希望可以给正在存算分离架构改造的企业一些参考和启发。

而大数据因为数据计算量很大，会利用数据本地性加速任务的运行。这里以一个spark任务的执行为例，用户在Tenant集群提交一个Spark任务，在k8s集群上会启动了一个 driver pod，然后调度器会根据与该Tenant相关的所有物理集群负载情况进行调度，接着Syncer会把这个pod同步到物理集群上，物理资源启动以后会Pod status反向同步到Tenent，同时driver连接的API Server也会修改到Tenent的API master上，最后新申请的Executor Pod。

将耗时最长的Stage展开，进一步看下具体的耗时比对，先看下Shuffle Read的耗时，由于原生Spark Shuffle需要从各个Executor上拉取数据，涉及到大量的网络开销以及磁盘的随机IO，耗时非常长，甚至达到了2分钟，而Remote Shuffle Service由于读取时降低了网络开销，且读取的是整块Shuffle数据，所以耗时短且较为稳定。这种shuffle方式多用于类MR的框架，比如MapReduce、Spark，它的特点是具有较高的容错性，适合较大规模的批处理作业。

混部资源治理以降低作业的失败率，确保作业的稳定性为主要目标，同时需要提高整个集群的 Shuffle 性能，减少资源浪费。，与刚才介绍的 ESS 模式不同，在 Push Based Shuffle 模式下，不同 Mapper 的同一个 Reducer Partition 数据都会发送到一个共同的远程服务上，在这个服务上进行合并，最后在某个 Worker 上写上一个或者多个文件，使得 Reduce 阶段可以通过 Sequential Read 模式读取这些 Partition 数据，减少随机 IO 的开销。

① 部署运维难度大目前我们大家所熟悉的Spark集群都是在传统的 Hadoop 集群内部，比如CDH，或者早期的云上的EMR集群，这种全家桶式的部署方式的好处在于组件比较丰富，但是部署组件繁多，无论是安装、部署、运维都比较复杂，带来比较大的运维和人力成本。② 弹性能力不足这种部署模式需要比较固定的资源预估，比如跑作业需要多少 master，多少worker，都要提前准备好，还要事先完成环境的安装和组件的部署。这样，弹性扩容的效率就比较差。③ 存储与计算耦合传统 Spark 集群既要部署HDFS 的 data

通过前两步的抽象，形成了所谓的领域模型与领域服务。业务层业务层我想聊聊model到dto的转换，从领域层接收到的数据为model，然而我希望传给应用层的是dto。为何不能直接将领域对象用于数据传递？领域对象更注重领域，而DTO更注重数据。传输对象DTO本身并不是业务对象。数据传输对象是根据UI的需求进行设计的，而不是根据领域对象进行设计的。避免直接将领域对象的行为暴露给表现层。同时对外的DTO不应感知领域的变化，无论内部如何变化，对外都不能直接耦合，应该经过convertor转化后保持一致。

要穿透 云原生 Service Mesh（服务网格），首先要理解 其宏观架构模式。在宏观架构模式上，云原生 Service Mesh（服务网格）的核心思想，就是进行微服务Provider 的架构解耦。