官方文档：Apache ShardingSphere
前置内容：MySQL:（五）分库分表
第章 高性能架构模式互联网业务兴起之后，海量用户加上海量数据的特点，单个数据库服务器已经难以满足业务需要，必须考虑数据库集群的方式来提升性能。高性能数据库集群的第一种方式是“读写分离”，第二种方式是“数据库分片”。
、读写分离架构读写分离原理：读写分离的基本原理是将数据库读写操作分散到不同的节点上，下面是其基本架构图：
读写分离的基本实现：
主库负责处理事务性的增删改操作，从库负责处理查询操作，能够有效的避免由数据更新导致的行锁，使得整个系统的查询性能得到极大的改善。
读写分离是根据 SQL 语义的分析，将读操作和写操作分别路由至主库与从库。
通过一主多从的配置方式，可以将查询请求均匀的分散到多个数据副本，能够进一步的提升系统的处理能力。
使用多主多从的方式，不但能够提升系统的吞吐量，还能够提升系统的可用性，可以达到在任何一个数据库宕机，甚至磁盘物理损坏的情况下仍然不影响系统的正常运行。
下图展示了根据业务需要，将用户表的写操作和读操路由到不同的数据库的方案：
CAP 理论：
...
参考内容：Istio(四)：创建部署Gateway并使用网关暴露服务-博客园
ingressgateway、service、VirtualService流量路径：从浏览器到后端服务.用户访问 后端服务
用户在浏览器中输入 http://exam.com/getList。
浏览器通过 DNS 查询 exam.com 的 IP 地址。
.DNS 解析
exam.com 的 DNS 记录指向 istio-ingressgateway的外部 IP。
如果 Kubernetes Service 类型是 LoadBalancer，则 DNS 指向云负载均衡器的 IP。
如果是 NodePort 类型，DNS 可以指向集群节点的外部 IP。
.流量到达 Kubernetes Service（istio-ingressgateway）
外部流量通过 IP 和端口（如 ）进入 Kubernetes Service istio-ingressgateway。
此处忽略pod：istio-ingressgateway是clusterIP类型，我也不知道这个项目为什么对外暴露是clus ...
环境准备部署官网：地址同步 | Apache Dubbo。
官网部署下来绝对是有问题的，因为缺少了部分配置，只能说提供了参考。这篇文档中在官方部署的基础上增加配置文件需要的配置以及注意事项等，并且附上解决方向和思路。
ks集群中的环境准备：
ks中已经安装了istio，并且istio-system下的pod都处于running状态
有provider-v、v，consumer镜像（私有仓库等）
# 测试是否安装istioistioctl version# 查看istio-system下的podkubectl get pods -n istio-system
查看webhook注入服务网格的条件）使用kubectl get mutatingwebhookconfiguration istio-injection--- -o yaml > istio-injection---.yaml 命令输出yaml文件，命名空间下自动注入sidecar的表达式如图，条件为：命名空间的标签应该有istio.io;revD;-- ...
. ks架构整体架构图官方提供的整体架构图如下：
主节点既可以做主节点，也可以做从节点，最小要求一主一从作为学习要求。
下边是对官方的结构图进行解释后的架构图：
通过kubectl或者可视化ui操作ks对外开放的api-server，即从节点的kubelet去管理从节点或pod。
核心组件（主节点，或者叫控制面板）：
api-server 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机制；
etcd 保存了整个集群的状态；
etcd是构建一个高可用的分布式键值(key-value)数据库。etcd内部采用raft协议作为一致性算法，etcd基于Go语言实现 ;主要用于共享配置和服务发现 ;
原理动画演示：http://thesecretlivesofdata.com/raft/
controller manager 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
scheduler 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上；
从节点的组件：
kubelet 负责维护容器的生命周期，同 ...
软件技术未读
docker：容器化项目Docker 是什么Docker 是一个开源的应用容器引擎，基于 Go 语言 并遵从 Apache. 协议开源。
Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。
容器是完全使用沙箱机制，相互之间不会有任何接口（类似 iPhone 的 app）,更重要的是容器性能开销极低。
docker 三个重要概念. Dockerfile这是一个文本文件，包含了一系列的指令，用于描述如何构建一个镜像。可以使用 docker build 命令根据 Dockerfile 中的指令逐步构建镜像。
. Image;镜像一、概念
Docker 镜像可以看作是一个包含了运行特定软件所需的所有文件和配置的静态文件包。它就像是一个软件的安装包，但更加轻量级和灵活。
一个镜像通常由以下几个部分组成：
基础操作系统层：可以基于常见的 Linux 发行版，如 Ubuntu、CentOS 等。
应用程序及其依赖：包括应用程序的二进制文件、库文件、配置文件等。
元数据：描述镜像的信息，如作者、版本号、标签等。
...
什么是线程安全这篇博客内容很好，直接偷过来：
什么是线程安全？如何保证线程安全？-CSDN博客
如何保证线程安全第一种：加锁。
在 Java 中通过添加synchronized关键字实现，对方法或者代码块进行互斥。
第二种：CAS非阻塞同步。
通过不断自旋进行重试，避免线程进入阻塞状态，挂起和唤醒都需要性能开销。
前面两种方式可以参考上面的博客和我写的锁的内容：Java多线程：（三）多线程锁、JUC锁的实现
第三种：ThreadLocal无同步方案。
线程本地存储：将共享数据的可见范围限制在一个线程中。这样无需同步也能保证线程之间不出现数据争用问题。
这种方式我结合后端开发一起介绍。
SpringBoot + ThreadLocal通常，我们会使用 synchronzed 关键字 或者 lock锁 来控制线程对临界区资源的同步顺序，但这种加锁的方式会让未获取到锁的线程进行阻塞，很显然，这种方式的时间效率不会特别高。
线程安全问题的核心在于多个线程会对同一个临界区的共享资源进行访问，那如果每个线程都拥有自己的“共享资源”，各用各的，互不影响，这样就不会出现线程安全的问题了，对吧？
顾名 ...
Sentinel 规则持久化一、修改order-service服务修改OrderService，让其监听Nacos中的sentinel规则配置。
具体步骤如下：
.引入依赖在order-service中引入sentinel监听nacos的依赖：
<dependency> <groupId>com.alibaba.csp</groupId> <artifactId>sentinel-datasource-nacos</artifactId></dependency>
.配置nacos地址在order-service中的application.yml文件配置nacos地址及监听的配置信息：加的是datasource往下的内容。
spring: cloud: sentinel: datasource: flow: nacos: server-addr: localhost: ...
后端开发未读
微服务保护：sentinel微服务保护
.初识Sentinel..雪崩问题及解决方案...雪崩问题微服务中，服务间调用关系错综复杂，一个微服务往往依赖于多个其它微服务。
如图，如果服务提供者I发生了故障，当前的应用的部分业务因为依赖于服务I，因此也会被阻塞。此时，其它不依赖于服务I的业务似乎不受影响。
但是，依赖服务I的业务请求被阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：
服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，那么当前服务也就不可用了。
那么，依赖于当前服务的其它服务随着时间的推移，最终也都会变的不可用，形成级联失败，雪崩就发生了：
...超时处理解决雪崩问题的常见方式有四种：
•超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待
...仓壁模式（线程隔离）方案：仓壁模式
仓壁模式来源于船舱的设计：
船舱都会被隔板分离为多个独立空间，当船体破损时，只会导致部分空间进入，将故障控制在一定范围内，避免整个船体都被淹没。
于此 ...
resiliencej在 Spring Cloud 中使用 ResilienceJ 断路器进行配置非常直观。下面我会提供一个简单的示例，展示如何在 Spring Boot 应用程序中配置 ResilienceJ 断路器。
一、circuitbreaker（断路器）. 添加依赖首先，确保你的项目中包含了必要的依赖。对于非响应式应用程序，你需要添加以下依赖：
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-circuitbreaker-resiliencej</artifactId> <version>$&#;spring-cloud.version&#;</version></dependency>
对于响应式应用程序，则需要使用：
<dependency> <groupId& ...
后端开发未读
分布式事务：Seata微服务下的事务场景在以下场景中，用户支付成功后，订单服务创建业务，同时使用 restTemplate 或者 feign 对其他服务发起远程调用，完成整个业务流程。
照理来说所有业务要么都成功，要么都失败，在没有加上事务管理时，是否能保证事务一致性？
实际上不会。假设在第三个库存服务中，商品库存不够了，那么后端确实会给前端报错信息（报状态码），但是在前面两个服务不会同时失败。也就是说，订单确实创建了，钱也确实少了，但是给不了货儿，明白了吧？此时事务就不是一致的。
在分布式系统中，一个业务跨越了多个服务或数据源，每个事务都是一个分支事务，而整个事务称为全局事务。保证所有分支事务的最终一致性，这样的事务就是分布式事务。
那么，如何保证分布式事务？先从基本的理论开始~
理论基础CAP定理四张图介绍CAP定理。
Base理论在CAP中，P是一定会发生的。想想看，网络故障，或者仅仅是普通的网络波动等其他原因，都有可能会导致集群中的节点不可用。因此满足P的前提下，能产生的模式也就只有两个了，那就是CP模式和AP模式。
无论是AP模式还是CP模式，他俩都在一开始我们提出分布式事务中遇 ...
