Rayce. Blogs

关于本站本站是本人的私人博客，所有的博客都是经过自己学习总结得出的。可能内容质量比较差，也许您有疑惑，或者说是博客哪里写的有问题，希望各位能够谅解！！！ 如果您方便，也可以添加我的qq(1326507725)或微信(https://wclspace.xyz/comment/ )指出我的不足。 最近更新少说明前期写博客主要的目的是为了总结所学知识，更加偏向于学习笔记。 现在由于时间的原因，还有更重要的一点是想要输出更有质量的文章，所以更新将会不定期。我会尽量将自己的所学清晰明了，通俗易懂的展现给大家。 3-4月面试， 所以没有太多精力更新。 分享一些话 无人扶我青云志，我自踏雪至山巅。倘若命中无此运，孤身亦可登昆仑 喧闹任其喧闹，自有我自为之。我自风情万种，与世无争。别人对你的打分是他对你的看法，他不了解你到时候，你又何必去在乎他的打分呢？关键的是你给你自己打几分。 这世上的事，认真不对，不认真也不对，执着不对，一切视为空气也不对。平平常常自自然然，如上山拜佛，见了佛像就磕头，磕了头，佛像还是佛像，你还是你，生活之累，就该少下来了 在这人世间，有些路是非得单独一个人去面对， ...

需求描述之前我们实现了ChatGPT项目的核心问答业务， 接着为了实现项目的商业化服务和引流， 对接微信公众号实现用户扫码关注、获取验证码登录等一系列的用户引入公众号进行登录。 这样的实现让我们的项目接入微信的广大用户群体，对于以后项目的商业化发展奠定了基调。接着， 为了项目不让有心人恶意利用以及我们自己的apiKey的额度也是有限的， 所以进行了一系列的规则过滤操作。 这样的规则过滤让我们的项目向商业化的道路上又迈进了一步。但是， 虽然我们做了用户限流限频的操作，但是还是相当于免费的产品 。这可不是一个商业化产品应该具有的操作。 如果用户后续还想使用我们的产品， 那当然免不了给钱咯。 所以， 本章节我们通过对于ChatGPT核心业务的扩展，实现了用户支付下单的操作。 并且， 基于DDD架构， 让我们的项目变得可拓展性非常好。我们都知道ChatGPT的更新迭代是非常快的， 所以项目的可拓展性变得至关重要了。 所以使用DDD架构的优点就体现的一览无余。 项目支付领域逻辑 用户下单支付用户选择商品下单，之后生成一个支付URL，用户扫码支付。再接收到支付成功回调后，把用户购买的订单发货【额度 ...

抽象工厂模式和工厂方法模式虽然主要的目的都是为了解决接口选择问题。 但是在实现上， 抽象工厂是一个中心工厂， 它能够创建其他的工厂。 业务背景介绍 随着业务超过预期的快速发展，系统的负载能力也要随着跟上。原有的单机 Redis 已经满足不了系统需求。这时候就需要更换为更为健壮的Redis集群服务，虽然需要修改但是不能影响目前系统的运行，还要平滑过渡过去。随着这次的升级，可以预见的问题会有； 很多服务用到了Redis需要一起升级到集群。 需要兼容集群A和集群B，便于后续的灾备。 两套集群提供的接口和方法各有差异，需要做适配。 不能影响到目前正常运行的系统。 单机的Redis服务操作1234567891011121314151617181920212223242526272829303132/** * 单机Redis服务操作 */public class RedisUtils { private Logger logger = LoggerFactory.getLogger(RedisUtils.class); private Map<String, St ...

策略模式是干什么的 、怎么用 ？定义策略模式（Strategy Pattern）是一种行为设计模式，它定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户，从而达到算法的变化不会影响到客户。这种模式涉及到三个角色： 上下文（Context）：持有一个策略类的引用，最终给客户端调用。 策略（Strategy）：定义所有支持的算法的公共接口。Context使用这个接口来调用某个Concrete Strategy定义的算法。 具体策略（Concrete Strategy）：实现Strategy接口的具体算法。 使用场景 当你想让一个对象有多种行为，而且想避免使用大量的条件语句时，可以使用策略模式。它提供了一种用条件语句以外的另一种选择，当你需要根据不同条件执行不同行为时特别有用。比如，一个排序的类，它支持多种排序算法，如冒泡排序、选择排序等，可以通过策略模式来实现这些算法的互换。 还有就是模拟多种营销类型的时候可以使用策略模式 营销类型实现的策略模式的简图 实现步骤以下是使用Java实现策略模式的基本步骤： 定义策略接口：这个接口声明了算法的方法 ...

容器网络在使用kubernetes之前， 最为火热的技术就是Docker技术了。 它完成了从虚拟机时代的过度，是走向云原生时代的开端。 但是由于docker的故步自封导致被google的开源的kubernetes后来居上， 现在的Docker虽然在积极改进， 但是主流大势已经被kubernetes掌握， 所以也只能起到助力作用。回归正题， 在kubernetes的服务发现， 服务网格等技术火热之前， 是怎么来实现容器之间的通信呢 ？本文我们就来探讨一下。 什么是容器网络及它解决了什么问题 ？容器网络利用Linux的network namespace实现对网络资源的隔离，每个容器都有自己的网络栈，包括网卡、回环设备、路由表和iptables规则。**容器网络需要解决的主要问题包括容器IP的分配、容器之间的互相访问、容器如何访问主机外部网络、以及外部网络如何访问到容器内部。 ** 容器网络实现技术容器网络的实现主要借助了下面两种技术。一个是 Veth Pair ，另一个是Bridge 网桥 Veth Pair：用于实现不同Network Namespace之间的通信。 Bridge：Li ...

PV、PVC到底是什么？简述PVC、PVPersistentVolume（PV）PersistentVolume是一个表示在集群中独立于Pod之外的一块物理存储资源的对象。它抽象了底层存储系统的细节，为Pod提供了统一的接口来访问这些存储资源。PV 描述的，是持久化存储数据卷。这个 API 对象主要定义的是一个持久化存储在宿主机上的目录，比如一个 NFS 的挂载目录 生命周期独立于Pod：即使Pod被删除或重新调度，PV仍然存在并保持其状态。 动态供给：Kubernetes支持动态供给PV，这意味着不需要手动创建PV，而是可以根据PVC的需求自动分配存储资源。 多种存储类型：PV可以支持多种存储类型，如本地存储、网络存储（如NFS、Ceph等）和云存储等。 通常情况下，PV 对象是由运维人员事先创建在 Kubernetes 集群里待用的。比如，运维人员可以定义这样一个 NFS 类型的 PV ， 如下 12345678910111213apiVersion: v1kind: PersistentVolumemetadata: name: nfsspec: storageClass ...

声明式API的交互这篇文章， 我将按照自己的理解结合我阅读过的文章给大家讲讲关于声明式API这个概念 声明式API是一种编程接口设计模式，在Kubernetes中，它允许用户通过描述资源的期望状态来与系统进行交互，而不是像传统的命令式API那样详细指定实现期望状态的具体步骤。所以， 在介绍声明式API与系统交互之前， 我们先来看看传统的命令式交互是怎么实现的，它的实现手段与声明式的有什么不同？ 为什么要转为声明式api的方式来交互呢？ 等等一系列的问题， 下面我都会一一列举 传统的交互方式首先， 我们看几个常用的传统式交互 1234567# 创建操作kubectl create -f nginx.yaml... 修改ing# 更新操作kubectl replace -f nginx.yaml# 删除操作kubectl delete -f nginx.yaml 上面两个式最典型的传统命令式交互的方式。在创建pod的时候通过create ，如果对现有的pod需要进行改动的话， 直接通过 vim 修改之前的yaml文件， 然后再当前目录下通过 replace命令进行修改。 通过这样一套 ...

了解DaemonSetdaemonSet的作用DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。 当有节点加入集群时， 也会为他们新增一个 Pod 。 当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。 简单来说就是能够时刻同步的执行节点上的任务 DaemonSet 的一些典型用法： 在每个节点上运行集群守护进程 在每个节点上运行日志收集守护进程 在每个节点上运行监控守护进程 一种简单的用法是为每种类型的守护进程在所有的节点上都启动一个 DaemonSet。一个稍微复杂的用法是为同一种守护进程部署多个 DaemonSet；每个具有不同的标志， 并且对不同硬件类型具有不同的内存、CPU 要求。 DaemonSet 的特征DaemonSet 的主要作用，是让你在 Kubernetes 集群里，运行一个 Daemon Pod。 所以，这个 Pod 有如下三个特征： 这个 Pod 运行在 Kubernetes 集群里的每一个节点（Node）上； 每个节点上只有一个这样的 Pod 实例； 当有新的节点加入 K ...

为什么我在还没有开始讲解Service之前就要拿出来headless Service说一说呢？因为我自己在回顾知识的时候发现自己并没有想象中的那么懂 Headless Service这个机制。 今天自己再温故学习的同时 输出文档开源供大家公共学习 Headless Service在service中的定位在Service服务中 ，有三种服务类型， 分别是 ClusterIP、NodePort、LoadBalancer前者是供集群内访问的 ，不对外暴露。 后两者是提供给公网用户访问 ，用户可以通过 <NodeIP>:<NodePort> 访问服务 。 当然， LoadBalancer需要提供负载均衡器来实现， 负载均衡器自动将流量分配到 NodePort 上的服务 。说到这里 ，我们都知道 ，他们三个都应该是需要提供ip的。 不管是 对集群内还是集群外。但是， 对于Headless service来说 ，虽然它使用的是ClusterIP， 但它不对外提供ip（他的ClusterIP: None） 没想到吧。 无头服务就是这么来的。 怎么使用？既然他是无头服务， ...

前置在学习StatefulSet之前， 我们先看下什么是有状态应用， 什么是无状态应用。 有状态应用： 简单来说是指那些需要存储和管理持久化数据的应用 无状态应用就是不需要管理存储和持久化数据的应用 之前我们使用的deployment， 他就是管理无状态应用的控制器。 如果想要管理有状态应用， 他是不的 ，为什么呢？首先， 他的设计初衷就是为了管理无状态应用的， 基本上就没考虑过有状态应用。 如果你读过张磊老师的《深入剖析kubernetes》你就会知道 ，云原生时代刚开始的那几年里， 有状态应用一直是界内“禁忌般”的话题 。其次， Deplotment更新pod的时候是直接删除旧的， 然后创建新的。 再通过平滑的滚动更新来实现更新操作。 如果出问题 ，那就直接回滚到之前的pod版本。最后， 对于Deployment来说， 通过ReplicaSet管理副本数量的方式是将多的删除 ，少的创建就行了，并没有考虑创建的顺序、也不需要关心数据一致性等等。这些都说明着deployment不适合管理有状态应用。 管理有状态应用的法宝——StatefulSet首先， 来介绍一下他把， Stat ...