版本选择Docker Desktop:4.34.2 (167172)
Kubernetes:v1.30.2
下载 Docker Desktophttps://hub.docker.com/?uuid=1E11669E-3462-47D4-B114-8CE9405EE842
Docker Desktop 开启 Kubernetes配置镜像加速
123456789101112{ "builder": { "gc": { "defaultKeepStorage": "20GB", "enabled": true } }, "experimental": false, "registry-mirrors": [ "https://jeona3e2.mirror.aliyuncs.com" ]}
为 Kubernetes 配置 C ...
从 3.3 版本后,Kafka 引入了 KRaft 来替代 ZooKeeper,所以我们不必再部署 zk 了。
版本选择v3.3.1
单机部署创建Kafka目录1mkdir kafka-cluster
编写docker-compose.yml12345678910111213141516171819202122232425262728293031323334353637383940414243version: "3"services: kafka1: image: 'bitnami/kafka:3.3.1' network_mode: kafka-net container_name: kafka1 # 解决镜像挂载权限问题 user: root ports: - 9192:9092 - 9193:9093 environment: ### 通用配置 # 允许使用kraft,即Kafka替代Zookeeper - KAFKA_ENABLE_KRAFT=y ...
LVS是什么LVS(LinuxVirtual Server)即Linux虚拟服务器,是由章文嵩博士主导的开源负载均衡项目,目前LVS已经被集成到Linux内核模块中。终端互联网用户从外部访问公司的外部负载均衡服务器,终端用户的Web请求会发送给LVS调度器,调度器根据自己预设的算法决定将该请求发送给后端的某台Web服务器,比如,轮询算法可以将外部的请求平均分发给后端的所有服务器,终端用户访问LVS调度器虽然会被转发到后端真实的服务器,但如果真实服务器连接的是相同的存储,提供的服务也是相同的服务,最终用户不管是访问哪台真实服务器,得到的服务内容都是一样的,整个集群对用户而言都是透明的。
LVS基于内核网络层工作,有着超强的并发处理能力,单台LVS可以承受上万的并发连接。
LVS是基于四层网络协议的负载均衡软件,因此LVS在所有负载均衡软件中性能最强,稳定性最高,消耗CPU和内存少,并且可以对应用层的所有协议作负载均衡,包括http、DNS、ftp等。
LVS分层及组成LVS负载均衡分为3层:
第一层:负载调度器(load balancer/Director),它是整个集群的总代理,它有两 ...
docker搭建zookeeper集群zookeeper版本v3.8
创建zk集群目录1mkdir zk-cluster
编写docker-compose.yml1234567891011121314151617181920212223242526272829303132333435363738394041424344454647version: '3'networks: zk-net: name: zk-net # 网络名services: zoo1: image: zookeeper:3.8 container_name: zoo1 # 容器名称 restart: always # 开机自启 hostname: zoo1 # 主机名 ports: - 2181:2181 # 端口号 environment: # 当前zk实例的id ZOO_MY_ID: 1 # 整个zk集群的机器端口列表(2181:对client端提供服务的端口, ...
docker搭建etcd集群etcd版本v3.3.27
创建etcd目录1mkdir etcd-cluster
编写docker-compose.yml123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159version: "3.0"networks: etcd-net: ...
二叉搜索树退化链表在树的数据结构中,最先有点是二叉查找树,也就是英文缩写 BST 树。在使用数据插入的过程中,理想情况下它是一个平衡的二叉树(左右子树高度差不超过1),但实际上可能会出现二叉树都一边倒,让二叉树退化为像链表一样的数据结构。从而树形结构的时间复杂度也从 O(logn) 升级到 O(n),如下图:
二叉搜索树的数据插入过程是,插入节点与当前节点做比对,小于在左,大于在右。
随着数据的插入顺序不同,就会出现完全不同的数据结构。可能是一棵平衡二叉树,也极有可能退化成链表的树。
当树结构退化成链表以后,整个树索引的性能也跟着退化成链表。
2-3 树解决平衡问题2-3 树是一种非常巧妙的结构,在保持树结构的基础上,它允许在一个节点中可以有两个元素,等元素数量等于 3 个时候再进行调整。通过这种方式来保证整个二叉搜索树的平衡性。
左侧是二叉搜索树,右侧是 2-3 平衡树,分别插入节点 4、5,观察树形结构变化。
二叉搜索树开始出现偏移,节点一遍倒。
2-3 树通过一个节点中存放 2 到 3 个元素,来调整树形结构,保持平衡。
所谓的保持平衡就是从根节点,到每一个最底 ...
DDD是什么MVC模式那我们就先看看没有DDD,软件开发都是怎么做的?
拿大家熟悉的MVC模式举例,这里的Model是数据库模型,业务逻辑在Controller中实现(一般会由Service来辅助实现),View层主要负责视图展示。
对于业务逻辑不复杂的软件开发,MVC是简单高效的方法。但是随着业务逻辑愈来愈复杂,MVC会开始力不从心。主要体现在这几个方面:
MVC模式仅仅反应了软件层面的架构,它不包含业务语言,无法使用该设计直接和业务对话。
MVC模式天然切割了数据和行为,然后用数据库实现数据,用服务实现行为,容易造成需求的首尾分离。
缺乏明确的边界划分,至少在顶层设计层面没有边界划分的规范要求,更多地是靠技术负责人根据经验进行划分,大规模团队协作容易出现职责不清晰、分工不明确。
传统的开发模式或多或少都存在上面的问题。
DDD定义领域驱动设计(英文:Domain-Driven Design,缩写DDD)是一种模型驱动设计的方法,通过领域模型捕捉领域知识,使用领域模型构造更易维护的软件。
模型在领域驱动设计中,有三个重要用途:
通过模型直接反映软件实现的结构。
以模型为基础形 ...
@SpringBootApplication 注解。它可以看作是 @EnableAutoConfiguraion、@ComponentScan、@Configuration 注解的集合。
@EnableAutoConfiguraion:启动 SpringBoot 的自动配置机制。
@ComponentScan:扫描被 @Component(@Service、@Controller)注解的 Bean,注解默认会扫描该类所在包下的所有类。
@Configuration:允许在上下文注册额外的 Bean 或导入其他配置类。
@EnableAutoConfiguraion注解通过 Spring 提供的 @Import 注解导入了 AutoConfigurationImportSelector 类( @Import 注解可以导入配置类或者 Bean 到当前类)
AutoConfigurationImportSelector 类中 getCandidateConfigurations 方法会将所有自动配置类的信息以 List 的形式返回,作为 Bean 被 Spring 容器管理。
@Cond ...
在网关系统合并的工程下,拉取分支完善功能流程。包括:算力关联、接口上报、调用反馈。
设计本章的扩展功能主要从几个方面来考虑:
网关的注册中心需要提供一个网关算力与RPC服务的分配关系。
groupld —1vn-> gatewayld —1vn—> systemld
10001 -> api-gateway-g3 -> api-gateway-test-01-provider
10001 -> api-gateway-g3 -> api-gateway-test-02-provider
10001 -> api-gateway-g4 -> api-gateway-test-03-provider
10001 -> api-gateway-g4 -> api-gateway-test-04-provider
10002 -> api-gateway-g5 -> api-gateway-test-05-provider
10002 -> api-gateway-g5 -> api-gatewav-tes ...
项目笔记
未读通过合并网关六个模块 【admin、center、core、assist、engine、sdk】 到统一服务下管理,完成 API 网关的多模块组装,为后续功能迭代做铺垫。
模块服务截止到本章整个 API 网关的核心流程就已经全部开发完成了,并可以完成基本测试调用。从本章开始将是对网关功能的细节迭代,因为这些内容会涉及到对网关六个模块 【admin、center、core、assist、 engine、sdk】的开发。所以到本章开始把整个工程合并,后续的章节将按照创建分支的方式进行开发。
目前网关系统的六大模块工程,主要分为三个大的部分在运行:
网关算力:由 api-gateway-core、api-gateway-assist、api-gateway-engine 组成,core 提供算力、assist 处理封装、engine 镜像打包和启动。
管理中心:由 api-gateway-admin、api-gateway-center 组成,admin 后台运营、center 注册中心。
接口上报:由 api-gateway-sdk 提供,它被应用系统引入,在应用系统中以注解的方式提取 ...