failsafe

前言 本来计划周五+周末三天自驾游，谁知人算不如天算，周六恰逢台风来袭，湖州附近的景点全部关停，不得已只能周五玩完之后，于周六踩着台风的边缘逃回上海。周末过得如此艰难，这次就聊点务虚的话题，一是浅谈微服务的架构设计，二是聊聊微服务中广泛用于服务治理的Eureka与RPC框架Dubbo异同点。 一、微服务的架构设计 之所以想聊一下这个话题，主要有感于最近接触的两个新的微服务项目--两个项目的架构设计出自两个人之手，却不约而同的使用了相同的设计理念，项目结构非常类似。又想到就职于上家公司时接触到的项目的结构设计，于是迸发出了些微的想法。用微服务的架构设计来作为议题，很有喧哗取宠的偏向，所以需要声明一下，本文说的都是基于博主当前浅薄的软件开发经验与贫瘠的架构设计思想得出的浅见，仅是一家之言，而且其中必定包含了很多的确认型偏误，对此现在无法避免。本文的目的只是与大家分享一下自己的想法，仅此而已。 言归正传，当前流传的比较广且提的比较多的设计理念，当属2004年Eric Evans提出的Domain Drive Design，即领域驱动设计，简称DDD。该设计理念可以说与微服务具有相当大的共生依赖关系，也因此，直到最近几年微服务兴起，DDD设计理念才大行其道。该设计理念就是先确定领域，再在此基础上进行设计开发。而领域怎么理解？通俗的理解方式就是一个独立的业务模块，以业务的范围来确定领域的边界

1、KALI LINUX 介绍 l 基于Debian的Linux发 ⾏ 版本 l 前 ⾝ 是 BackTrack ，2013年3 ⽉ 发布 l ⽤ 于***测试和安全审计 l 包含600+安全 ⼯ 具（也可自己下载添加） l FHS 标准 目 录结构 l 定制内核 l ⽀ 持 ARM 和 ⼿ 机平台 l 开源免费 kali linux 这个工具不管是对我们还是技术大拿来说，都是一个很好的安全测试或者防护的工具，当然我肯定不会对kali linux里600+安全 ⼯ 具都介绍，我只会挑选一些相对好用简单的、能满足我们基础安全运维的工具来进行介绍。 2、 KALI LINUX下载及更新 kali linux 下载安装镜像： https://www.kali.org/downloads/ 大家可以在这个官方网站进行下载，里面有ISO、vmware等版本的镜像。我是直接下载kali-linux-2019.4-vmware-amd64.zip这个版本直接使用虚拟机打开。想使用启动光盘去安装可以下载kali-linux-2020-1-live-amd64-iso这个版本。如果你想使用U盘来启动安装，可以先去下载个U盘制作工具unetbootin，然后打开去制作一个U盘启动： 按上面的配置选项，开始进行制作 制作完成后，使用U盘启动安装后，会出现如下界面： 选项介绍： Live(amd64):

序 本文主要研究一下dubbo-go的failsafeCluster failsafeCluster dubbo-go-v1.4.2/cluster/cluster_impl/failsafe_cluster.go type failsafeCluster struct{} const failsafe = "failsafe" func init() { extension.SetCluster(failsafe, NewFailsafeCluster) } // NewFailsafeCluster ... func NewFailsafeCluster() cluster.Cluster { return &failsafeCluster{} } func (cluster *failsafeCluster) Join(directory cluster.Directory) protocol.Invoker { return newFailsafeClusterInvoker(directory) } failsafeCluster的join方法执行newFailsafeClusterInvoker newFailsafeClusterInvoker dubbo-go-v1.4.2/cluster/cluster_impl/failsafe_cluster_invoker

软件工程领域存在一个共识：维护代码所花费的时间要远多于写代码。而整个代码维护过程中，最惊心动魄与扣人心弦的部分，莫过于问题排查（Trouble-shooting）了。特别是那些需要 7x24 小时不间断维护在线业务的一线服务端程序员们，大大小小的问题排查线上救火早已成为家常便饭，一不小心可能就吃成了自助餐 —— 竖着进躺着出，吃不了也兜不住。 本文分享作者在服务端问题排查方面的一些经验，包括常见问题、排查流程、排查工具，结合实际项目中发生过的惨痛案例进行现身说法。 一 、问题排查 1、常见问题 Know Your Enemy：知己知彼，百战不殆。 日常遇到的大部分问题，大致可以归到如下几类： 逻辑缺陷：e.g. NPE、死循环、边界情况未覆盖。 性能瓶颈：e.g. 接口 RT 陡增、吞吐率上不去。 内存异常：e.g. GC 卡顿、频繁 FGC、内存泄露、OOM。 并发/分布式：e.g. 存在竞争条件、时钟不同步。 数据问题：e.g. 出现脏数据、序列化失败。 安全问题：e.g. DDoS 攻击、数据泄露。 环境故障：e.g. 宿主机宕机、网络不通、丢包。 操作失误：e.g. 配置推错、删库跑路（危险动作，请勿尝试..）。 上述分类可能不太完备和严谨，想传达的点是：你也可以积累一个这样的 checklist，当遇到问题百思不得其解时，耐心过一遍，也许很快就能对号入座。 2、排查流程

面试题 dubbo 负载均衡策略和集群容错策略都有哪些？动态代理策略呢？ 面试官心理分析 继续深问吧，这些都是用 dubbo 必须知道的一些东西，你得知道基本原理，知道序列化是什么协议，还得知道具体用 dubbo 的时候，如何负载均衡，如何高可用，如何动态代理。 说白了，就是看你对 dubbo 熟悉不熟悉： dubbo 工作原理：服务注册、注册中心、消费者、代理通信、负载均衡； 网络通信、序列化：dubbo 协议、长连接、NIO、hessian 序列化协议； 负载均衡策略、集群容错策略、动态代理策略：dubbo 跑起来的时候一些功能是如何运转的？怎么做负载均衡？怎么做集群容错？怎么生成动态代理？ dubbo SPI 机制：你了解不了解 dubbo 的 SPI 机制？如何基于 SPI 机制对 dubbo 进行扩展？ 面试题剖析 dubbo 负载均衡策略 random loadbalance 默认情况下，dubbo 是 random load balance ，即 随机 调用实现负载均衡，可以对 provider 不同实例 设置不同的权重 ，会按照权重来负载均衡，权重越大分配流量越高，一般就用这个默认的就可以了。 roundrobin loadbalance 这个的话默认就是均匀地将流量打到各个机器上去，但是如果各个机器的性能不一样，容易导致性能差的机器负载过高。所以此时需要调整权重

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 阿里妹导读：软件工程领域存在一个共识：维护代码所花费的时间要远多于写代码。而整个代码维护过程中，最惊心动魄与扣人心弦的部分，莫过于问题排查（Trouble-shooting）了。特别是那些需要 7x24 小时不间断维护在线业务的一线服务端程序员们，大大小小的问题排查线上救火早已成为家常便饭，一不小心可能就吃成了自助餐 —— 竖着进躺着出，吃不了也兜不住。本文分享作者在服务端问题排查方面的一些经验，包括常见问题、排查流程、排查工具，结合实际项目中发生过的惨痛案例进行现身说法。 一 问题排查 1 常见问题 Know Your Enemy：知己知彼，百战不殆。 日常遇到的大部分问题，大致可以归到如下几类： 逻辑缺陷：e.g. NPE、死循环、边界情况未覆盖。 性能瓶颈：e.g. 接口 RT 陡增、吞吐率上不去。 内存异常：e.g. GC 卡顿、频繁 FGC、内存泄露、OOM 并发/分布式：e.g. 存在竞争条件、时钟不同步。 数据问题：e.g. 出现脏数据、序列化失败。 安全问题：e.g. DDoS 攻击、数据泄露。 环境故障：e.g. 宿主机宕机、网络不通、丢包。 操作失误：e.g. 配置推错、删库跑路（危险动作，请勿尝试..）。 上述分类可能不太完备和严谨，想传达的点是

目录 1、原理图制图规范 2、电路设计 2.1、通用要求 2.2、逻辑器件应用 2.3、时钟设计 2.4、保护器件应用 2.5、可编程逻辑器件 2.6、电源设计 2.7、其他应用经验 3、可靠性设计 4、信号完整性/电源完整性设计 5、系统相关设计 6、可生产性设计 7、可生产性设计 7.1、JTAG 7.2、测试点 7.3、电路可测试性 7.4、系统可测试性 本博客将简述 中兴通讯股份有限公司在原理图设计中需要注意的一些事项，其中包含了中兴设计开发部积累的大量硬件开发知识和经验，可以作为学习使用。硬件工程师可以学习并掌握检查条目的内容以及对条目的详细说明，学习部门经验。 1、原理图制图规范 原理图制图规范如下表所示： 详细说明如下所示： 1、原理图必须使用公司统一原理图库 在原理图设计中，必须采用公司统一原理图库，以保证设计的一致性和打包后封装、料单等结果的一致性。不使用公司统一原理图库造成的连接、封装错误个人承担责任。 注意使 cds.lib 中的路径指向库服务器 eda-svr1 的路径。库服务器每天会和公司统一库服务器同步 2 次确保最新。 在改版设计中尤其要注意这个问题，因为打包时会将部分库备份到本地，可能造成本地库和公司库不一致。 对于历史遗留的未采用统一图库的设计，可以豁免此项检查。但是如果经历改版，必须将原理图库切换至公司统一库，以保证料单的正确性和后续的可维护性。

前言 涵盖各大公司会问到的面试点，同时随着版本的升级，可能也会有一些面试题更新，也会同步保持更新，因为篇幅原因（其实是我懒，哈哈）所以列了一部分答案，所有的答案见下文，总共485页合计20个技术点，文末自取pdf. 1、为什么要用 Dubbo？ 随着服务化的进一步发展，服务越来越多，服务之间的调用和依赖关系也越来越复杂，诞生了面向服务的架构体系(SOA)，也因此衍生出了一系列相应的技术， 如对服务提供、服务调用、连接处理、通信协议、序列化方式、服务发现、服务路由、日志输出等行为进行封装的服务框架。就这样为分布式系统的服务治理框架就出现了，Dubbo 也就这样产生了。 2、Dubbo 的整体架构设计有哪些分层? 接口服务层（Service）：该层与业务逻辑相关，根据 provider 和 consumer 的业务设计对应的接口和实现 配置层（Config）：对外配置接口，以 ServiceConfig 和 ReferenceConfig 为中心 服务代理层（Proxy）：服务接口透明代理，生成服务的客户端 Stub 和 服务端的 Skeleton，以 ServiceProxy 为中心，扩展接口为 ProxyFactory 服务注册层（Registry）：封装服务地址的注册和发现，以服务 URL 为中心，扩展接口为 RegistryFactory、Registry

　　前两篇中，我们看到了dubbo在负载均衡和服务路由方面的实现，它为集群功能提供了必要的功能。 　　今天我们再来看另一个集群组件的实现：集群容错。 1. dubbo 集群容错简介 　　为了避免单点故障，现在的应用通常至少会部署在两台服务器上。对于一些负载比较高的服务，会部署更多的服务器。对于服务消费者来说，同一环境下出现了多个服务提供者。这时会出现一个问题，服务消费者需要决定选择哪个服务提供者进行调用。另外服务调用失败时的处理措施也是需要考虑的，是重试呢，还是抛出异常，亦或是只打印异常等。为了处理这些问题，Dubbo 定义了集群接口 Cluster 以及 Cluster Invoker。集群 Cluster 用途是将多个服务提供者合并为一个 Cluster Invoker，并将这个 Invoker 暴露给服务消费者。这样一来，服务消费者只需通过这个 Invoker 进行远程调用即可，至于具体调用哪个服务提供者，以及调用失败后如何处理等问题，现在都交给集群模块去处理。集群模块是服务提供者和服务消费者的中间层，为服务消费者屏蔽了服务提供者的情况，这样服务消费者就可以专心处理远程调用相关事宜。 　　dubbo的集群容错功能由多个组件共同完成：包括 Cluster、Cluster Invoker、Directory、Router 和 LoadBalance 等。它们之间的依赖关系如下：

欢迎来我的 Star Followers 后期后继续更新Dubbo别的文章 Dubbo 源码分析系列之一环境搭建 博客园 Dubbo 入门之二 ——- 项目结构解析 博客园 Dubbo 源码分析系列之三 —— 架构原理 博客园 Dubbo 源码解析四 —— 负载均衡LoadBalance 博客园 下面是个人博客地址，页面比博客园美观一些其他都是一样的 Dubbo 源码分析系列之一环境搭建" Dubbo 源码分析系列之一环境搭建 个人博客地址" Dubbo 入门之二 ——- 项目结构解析"Dubbo 项目结构解析 个人博客地址" Dubbo 源码分析系列之三 —— 架构原理" Dubbo 源码分析系列之三---架构原理 个人博客地址" Dubbo 源码解析四 —— 负载均衡LoadBalance" dubbo源码解析四 --- 负载均衡LoadBalance 个人博客地址" Dubbo 源码解析五 —— 集群容错" dubbo源码解析五 --- 集群容错架构设计与原理分析 个人博客地址" 目录 面试中集群容错的经常的问题 Dubbo 官方文档关于集群容错的介绍 Dubbo集群容错的架构分析 Dubbo集群容错源码解析 面试中集群容错的经常的问题 什么是集群容错 Dubbo的集群容错知道吗 Dubbo 集群容错是如何配置的 集群容错如何实现的 Dubbo 集群容错介绍下 介绍下