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 提供，它被应用系统引入，在应用系统中以注解的方式提取 ...

基于第25章 Nginx 的负载模型，第26章动态刷新 Nginx 的配置和实现，把网关算力节点动态刷新到 Nginx 配置中，完成动态负载的功能实现。 设计这里我们要实现的核心功能就是当有网关算力节点注册到注册中心的时候，可以被动态的配置到 Nginx 负载中，这样就可以实现动态的变更操作了。 在不使用 Nginx 代理的时候，前面章节使用网关都是通过直接方式的方式操作，如 http://10.20.111.132:7397/wg/activity/sayHi?str=1 那么现在因为有负载的设计，希望把来自于不同 URL的请求负载到不同的网关算力上去，所以这里的访问地址将变更为：http://10.20.111.132:8090/10001/wg/activity/sayHi?str=10001 从第1个地址到第2个地址来看，变化的点主要是端口由原来的访问网关算力节点到访问 Nginx，同时多了一个 10001 的路径。这个 10001 就是数据库中 group_id 网关分组的配置。我们也是用这个配置来区分访问哪一组网关。 api-gateway-center 管理着网关算力的 ...