daobuxinzi的博客

而 Spring Cloud 就像品牌机，在 Spring Source 的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解。一个通俗的描述是：客户端在不知道调用细节的情况下，调用存在于远程计算机上的某个对象，就像调用本地应用程序中的对象一样。Spring Cloud 基于 Spring Boot，为微服务体系开发中的架构问题，提供了一整套的解决方案——服务注册与发现，服务消费，服务保护与熔断，网关，分布式调用追踪，分布式配置管理等。

当你发现相同业务的不同前端应用，通过API获取到数据后请求多个接口，或转换或过滤了一些响应数据，或都进行了相同的基于结果数据的进一步计算，此时，你需要考虑把这些代码迁移到BFF。一个BFF可以对接多个前端应用，取决于前端应用需求的相似度，如，相同业务不同平台（Android、iOS）的App。前面已经说了，BFF是后端的前端，既然他不是处于整个系统的底层，他有自己的后端，所以，一般BFF不应当包含数据库的操作。8、控制：BFF应当有能力根据前端应用的性质不同，控制哪些数据应当或不应该提供给哪个应用。

分布式数据库其实没有一个官方的定义，只是我们技术人员提出的一个约定俗成的说法。在数据库领域，当产品不断演进逐渐被大家认识和认可后，就会成了一个标准，比如说微软的 SQL Server 数据库，其他数据库都喜欢拿它作为对比，那 SQL Server 数据库就会成为一个标准。但是分布式数据库也是最近几年才被大家提出，还是比较新的，也没有参照。不过我们可以通过这些大厂大牛们总结的经验来认识分布式数据库。分布式数据库就是用分布式架构实现的数据库。

还是拿前面的例子来说，假如小公司的全栈工程师有点异常情况（请假、跑路、忙不过来等等）老板会考虑招多个这样的人，这就形成了一个集群，好处就是能干更多的活（负载分流）和互补（高可用），但本质上还是一个人做所有事。最常见的数据库就是每个人都用过的 Excel 文档，一个文件可以看成一个数据库，每个 sheet 就是数据表，表里的列就是字段，每一行就是存储的数据。项目开发中的“分布式。对于数据库系统来说，可靠性的最好情况就是服务永不停机，但这是不可能实现的，因为本身硬件层面就存在一定的故障率。

但是对于服务发现来说，情况就不太一样了，针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。因为对于服务消费者来说，能消费才是最重要的，消费者虽然拿到可能不正确的服务实例信息后尝试消费一下，也要胜过因为无法获取实例信息而不去消费，导致系统异常要好。Nacos除了服务的注册发现之外，还支持动态配置服务。总之，服务注册中心到底选用CP模型还是AP模型，还是要依照业务场景进行决定，如果对数据一致性要求较高，且可以容忍一定时间的不可用，就选用CP模型。

Spring Cloud Eureka 是在 Netflix 的 Eureka 的基础上进行二次开发而诞，采用了 C-S 的设计架构，Spring Cloud Eureka 提供 Eureka Server 服务端与 Eureka Client 客户端 ，服务端即是 Eureka 服务注册中心，客户端完成微服务向 Eureka 服务的注册与发现。服务端和客户端均采用 Java 语言编写。

（1）Zookeeper 选举会发生在服务器初始状态和运行状态下。（2）初始状态下会根据服务器sid的编号对比，编号越大权值越大，投票过半数即可选出Leader。（3）Leader 故障会触发新一轮选举，zxid 代表数据越新，权值也就越大。（4）在运行期选举还可能会遇到脑裂的情况，大家可以自行学习。Zookeeper 的选举机制也不过如此！- 腾讯云开发者社区-腾讯云。

Eureka集群中各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。但是别忘了，选举是需要时间的，哪怕30s到120秒，这一段时间之内，zookeeper集群是不能给外部提供服务的，处于不可用的状态，所以从这个角度来讲它丧失了一定的系统可用性（即CAP中的A）。这个时候就体现出注册中心的作用了，让B服务把自己的实例信息注册到 服务注册中心上，然后A去注册中心上获取B服务的信息不就行了，这样的话，A服务就可以调用B的服务了，so easy, OK!

最后，RPC Client 从本地缓存的服务节点列表中，基于负载均衡算法选择一台 RPC Sever 发起调用。

下面的代码是单节点 Redis 的配置。/*** 对 Redisson 的使用都是通过 RedissonClient 对象* @return*/@Bean(destroyMethod="shutdown") // 服务停止后调用 shutdown 方法。// 1.创建配置// 集群模式// 2.根据 Config 创建出 RedissonClient 示例。}}复制代码。...

Redis 以其高性能著称，但使用其实现分布式锁来解决并发仍存在一些困难。Redis 分布式锁只能作为一种缓解并发的手段，如果要完全解决并发问题，仍需要数据库的防并发手段。参考：1.“Redis 分布式锁的正确实现方式（ Java 版 ）”Redis 分布式锁的正确实现方式（ Java 版 ）2.“漫画：什么是分布式锁？”漫画：什么是分布式锁？3.“搞懂“分布式锁”，看这篇文章就对了”搞懂“分布式锁”，看这篇文章就对了4.《Redis 深度历险：核心原理与应用实践》...

在《技术中台与业务中台都是啥玩意》一文中留下一个问题：BFF是啥？为啥在API网关和业务中台之间加入了一层BFF？考虑到在实际工作中，我的大部分同事都问过这个问题，这里我也总结一下进行答复。为了讲清BFF是个啥，这里引用我在波波老师的课程《Spring Boot与K8s云原生应用开发》中学到的一个案例，来跟大家分享一下，并尽力说清楚BFF是啥，又是如何演化出来的。假设我们在一个开发团队中，开发了一个叫做MyShop的电商项目，它采用的是微服务的架构风格。它经历过几次架构调整，我们就跟着它的调整来看看BFF是

如果我们打开支付宝首页，去看我们的余额，它会展示你的总资产，昨日收益、累计收益等信息。假如这个页面所展示的信息，都来自各个不同的系统/应用，我们通过各个接口把这些数据展示出来。如果我们现在要在前端页面展示这几项数据的话，我们应该怎么去展示呢？在这种情况下，我们不可能让客户端与6个不同的应用/系统都一一去通信来去完成数据的展示。而是6个应用/系统之间进行彼此通信来完成调用，最后客户端只需要调用一个接口来获取数据即可，而不是与每一个应用/系统进行通信。我们的架构可能是如下的样子：一个电商系统，比如淘宝，我们在首