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实现策略模式的基本步骤： 定义策略接口：这个接口声明了算法的方法 ...

浅识SpringIOC 小小了解一下 Spring 家族 官网地址：spring.io/ 项目列表：spring.io/projects Spring 是最受欢迎的企业级 Java 应用程序开发框架，数以百万的来自世界各地的开发人员使用 Spring 框架来创建性能好、易于测试、可重用的代码。 Spring 框架是一个开源的 Java 平台，它最初是由 Rod Johnson 编写的，并且于 2003 年 6 月首 次在 Apache 2.0 许可下发布。 Spring 是轻量级的框架，其基础版本只有 2 MB 左右的大小。 Spring 框架的核心特性是可以用于开发任何 Java 应用程序，但是在 Java EE 平台上构建 web 应 用程序是需要扩展的。 Spring 框架的目标是使 J2EE 开发变得更容易使用，通过启用基于 POJO 编程模型来促进良好的编程实践 通过上面的粗略介绍 ,我们可以简单的了解一下Spring家族的厉害之处下面就是我们今天学习的重点 Spring IOC( Inversion of Control )反转控制 First : ...

了解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 ...

工作负载在上一章中， 我们简要的了解了工作负载的作用及其概要， 在这章节的学习中 ， 在学期容器编排之前 ， 让我们来再加深一下对工作负载的理解。 在Kubernetes中，工作负载是对一组Pod的抽象模型，用于描述业务的运行载体。这些工作负载类型帮助用户定义和管理他们的应用程序，确保它们在容器化环境中高效运行。 借用我阅读的过的文章的一个图， 来表示一下工作负载到底再干什么？ 从图中清晰明了的看到，工作负载管理者一组pod ，而pod其实是一组或者一个容器的集合。 所以说， 工作负载是一组pod的抽象模型。 Deployment是一种工作负载，在Kubernetes中用于描述期望的状态。具体来说，Deployment是用于部署、扩展和管理Pod的API对象，它代表用户期望的Pod集合的状态。 为什么要有工作负载？为了减轻用户的使用负担，通常不需要用户直接管理每个 Pod。 而是使用负载资源来替用户管理一组 Pod。 这些负载资源通过配置 控制器 来确保正确类型的、处于运行状态的 Pod 个数是正确的，与用户所指定的状态相一致。这就是我前面所说的工作负载代表用户期望pod的状 ...

容器、镜像、Pod三者的关系 在正式学习pod这个概念之前， 我想先和读者共同学习一下容器、镜像、pod这几个我们在云原生环境中经常听到的名词的概述， 以及他们三者之间究竟有者怎么样的关联关系， 使得我们在云原生中常常用到。 镜像——部署项目的基石定义：容器镜像是一个只读的模板，包含了运行应用程序所需的所有代码、运行时库、环境变量和配置文件等。它是一个特殊的文件系统，用于提供容器运行时所需的程序、库、资源、配置等文件，并包含了一些为运行时准备的一些配置参数作用：在制作镜像时 ， 常常用到的就是Docker技术 。制作成的镜像使得应用程序及其依赖项可以在不同的环境中进行部署和运行， 无需担心环境问题而导致的问题。它是创建容器的起点，通过在镜像上添加一个可写层，容器可以在镜像的基础上进行变化，而不会影响到原始镜像 ， 其实对于相关的配置文件在现网中不是打包到镜像中的，而是通过环境变量的方式读取的， 这就是在可写层执行的一个实例。 容器——应用运行的实例定义：容器是Docker的核心概念之一，是一个独立运行的应用程序及其所有运行时依赖项的轻量级、可执行单元。它与镜像几乎一模一样，区别在于 ...