为什么要用nexus代理yum和apt源 大多数情况下，生产环境的服务器处于受限制的网络环境中，无法访问公网的yum或apt源。因此可以架设一个代理服务器，让代理服务器获取软件包。 Nexus是一种流行的仓库管理工具，用于管理和组织各种类型的软件包、构建工件和依赖项。它的主要用途是创建、维护和管理软件仓库，以支持开发者团队在软件开发和部署过程中的需要。Nexus支持的仓库类型有: apt, bower, cocapods, cona, docker, gitfs, go, helm, maven, npm, nuget, p2, raw, rubegems, yum。
距离 Jeffrey Palermo发布他关于洋葱架构（Onion Architecture）系列的第一篇博客已经接近15年了。在那篇博文中，他总结了一些实际上是Alistair Cockburn提出的六边形架构（Hexagonal Architecture）方法的延续的想法。尽管我一直认为这两种代码组织方法并不一定构成“架构”，但我始终发现它们对于形成一个关于如何构建代码基础结构的心智模型非常有帮助。多年来，我见过很多团队试图遵循这些模型，并在实践中遇到了一些误解和问题。在本博客文章中，我想总结其中的一些发现，并提出一种对洋葱架构的更加精炼的看法。
并发是Go语言的一个强大特性，它允许开发者编写高效且可扩展的应用程序。在Go中，用于管理并发的两种常用机制是Channel和WaitGroup。本文将探讨Channel和WaitGroup之间的相似之处和区别，并讨论何时以及如何有效地使用它们。
本文的目的是提供对云原生模式的一般理解和概述。 1.介绍 云原生模式（Cloud Native Patterns）指的是一组架构和设计原则，使得应用程序能够在云计算环境中进行开发和部署。这些模式专门设计用于充分利用云平台提供的能力，如可扩展性、弹性、伸缩性和易于管理性。通过采用云原生模式，组织可以构建和运营在云原生生态系统中高度适应的、可移植的和高效的应用程序。
Spring Framework 6.1 M2引入了RestClient，这是一个新的同步HTTP客户端。正如名称所示，RestClient提供了WebClient的fluent API，并结合了RestTemplate的基础设施。 十四年前，在Spring Framework 3.0中引入RestTemplate时，我们很快发现，在一个类似模板的类中公开HTTP的每个能力会导致方法过多。因此，在Spring Framework 5中，我们为响应式的WebClient使用了的fluent API。通过RestClient，我们引入了一个类似于WebClient的HTTP客户端，它使用RestTemplate的消息转换器、请求工厂、拦截器和其他底层组件。
Cilium是一个基于eBPF的数据平面的网络、观测和安全解决方案。它提供了一个简单的扁平化第三层网络，能够以本地路由或覆盖模式跨多个集群进行部署。 Cilium的基础是名为eBPF的Linux内核技术，它支持在Linux内核的各个集成点（如网络IO、应用程序套接字和跟踪点tracepoints）动态插入eBPF字节码，以实现安全、网络和可见性逻辑。eBPF具有高效和灵活的特性。 本文将介绍如何使用Helm安装Cilium。与Cilium快速安装相比，这需要进行一些额外的步骤，并要求你手动选择最适合你特定环境的数据路径(datapath)和IPAM模式(IPAM mode)。
1.Rook介绍 1.1 Rook简介 Rook是一个开源的云原生存储编排器，为Ceph存储提供平台、框架和支持，使其能够与云原生环境进行本地集成。 Rook是云原生计算基金会（CNCF）的一个项目，从2018年成为孵化项目，并在2020年成为毕业项目。 Ceph是一个分布式存储系统，提供文件(file)、块(block)和对象存储(object storage)，并在大规模生产集群中部署。
1. 可观测性 OpenTelemetry Collector提供了多种方法来评估其自身的健康状况以及如何排除故障。 1.1 日志 日志对于识别问题非常有帮助。始终从检查日志输出并查找潜在问题开始。日志的级别默认为INFO。 在配置中设置日志级别: service: telemetry: logs: level: "debug" 1.2 Metrics OTEL Collector的Prometheus指标在本地通过端口8888和路径/metrics公开。并可以通过配置文件中的service.telemetry.metrics.address进行配置。
1. 基于OpenTelemetry的可观测性方案 最近将一个项目的可观测性方案从Logs(ElasticSearch,Fuentbit,Kibana), Traces(Jaeger+OpenTracing)迁移到了OpenTelemetry。此项目由多个微服务组成，部署在一个Kubernetes集群中。 OpenTelemetry Collector由OpenTelemetry K8S Operator管理，并以DaemonSet的形式部署在Kubernetes集群的各个节点上。即每个K8S节点上都有一个OTEL Collector Agent进程负责收集并处理本节点上微服务Pod实例的Logs, Traces, Metrics数据，并将Logs, Traces数据发送到后端的日志存储(Loki或ES)、Traces数据存储(Jaeger或Tempo)，同时将Metrics数据暴露给Prometheus。
启用多租户支持 Tempo是一个支持多租户的分布式追踪系统。它通过使用一个名为X-Scope-OrgID的header来实现多租户支持。 前面我们部署了Tempo，但使用OTEL Collector向其中推送追踪数据时并没有启用多租户支持，通过查看我们的MinIO存储中的数据也能确认。