Taylor

1. Dubbo1.1. 是什么Dubbo 是一款高性能、轻量级的开源 RPC 框架。由 10 层模式构成，整个分层依赖由上至下。通过这张图我们也可以将 Dubbo 理解为三层模式： 第一层的 Business 业务逻辑层由我们自己来提供接口和实现还有一些配置信息。第二层的 RPC 调用的核心层负责封装和实现整个 RPC 的调用过程、负载均衡、集群容错、代理等核心功能。第三层的 Remoting 则是对网络传输协议和数据转换的封装。 1.2. 核心能力 (特性) 1.3. 架构 1.4. 协议1.4.1. Dubbo 协议Dubbo 缺省协议采用单一长连接和 NIO 异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。 反之，Dubbo 缺省协议不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。 缺省协议，使用基于 netty 3.2.5.Final 和 hessian2 3.2.1-fixed-2(Alibaba embed version) 的 tbremoting 交互。 连接个数：单连接 连接方式：长连接 传输协议：T ...

1. 雪崩问题1.1. 是什么微服务调用链路中的某个服务故障，引起整个链路中的所有微服务都不可用，这就是雪崩。 1.2. 产生原因微服务中，服务间调用关系错综复杂，一个微服务往往依赖于多个其它微服务。 如果服务提供者 I 发生了故障，当前的应用的部分业务因为依赖于服务 I，因此也会被阻塞。 但是，依赖服务 I 的业务请求被阻塞，用户不会得到响应，则 tomcat 的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞： 服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，那么当前服务也就不可用了。 1.3. 雪崩问题解决方案%%▶11.🏡⭐️◼️【🌈费曼无敌🌈⭐️♨️⭐️】◼️⭐️-point-20230315-1023%%❕ ^wihp2i 解决雪崩问题的常见方式有四种：超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待**舱壁模式 (线程隔离)**：限定每个业务能使用的线程数，避免耗尽整个 tomcat 的资源，因此也叫线程隔离熔断降级：由断路器统计业务执行的异常比例，如果超出阈值则会熔 ...

1. SpringBoot 的特性https://www.bilibili.com/video/BV1Et411Y7tQ?p=117&vd_source=c5b2d0d7bc377c0c35dbc251d95cf204 1.1. 依赖管理1.1.1. 父项目做依赖管理 1、无需关注版本号，自动版本仲裁 2、可以修改默认版本号 1.1.2. starter 场景启动器 1、见到很多 spring-boot-starter-xxx ： xxx 就某种场景2、只要引入 starter，这个场景的所有常规需要的依赖我们都自动引入3、SpringBoot 所有支持的场景https://docs.spring.io/spring-boot/docs/current/reference/html/using-spring-boot.html#using-boot-starter4、见到的 xxx-spring-boot-starter： 第三方为我们提供的简化开发的场景启动器。5、所有场景启动器最底层的依赖 1.2. 自动配置● 自动配好 Tomcat ○ 引 ...

1. Spring 基本概念 POJO: 基于 POJO 的轻量级和最小侵入性编程；DI: 通过依赖注入和面向接口实现松耦合；AOP: 基于切面和惯例进行声明式编程；Template: 通过切面和模板减少样板式代码。 比如我们要写 JDBC 这种牵扯到大量样板式的代码。我们其实只关注我们的 sql 语句（也就是它要实现什么功能），我们可不想看到他是如何连接的。等我们写好核心之后再去用切面进行连接，断开等。 1.1. POJO基本原理-0、Java相关名词 POJO 的全称是 Plain Old Java Object，简单又老的 Java 对象。这里的简单是相对来讲的。 EJB 2. x 的 Entity Beans 比较重量，需要实现 javax.ejb 的一些接口。而 POJO 就比较轻量，就是一个 Java 对象，不需要实现任何的接口。POJO 专指只有 private 属性以及 setter/getter/toString 的简单类，包括 DO/DTO/BO/VO 等。 所以 POJO 本质上也是可以方便沟通的术语。 有 ...

1. Java 序列化https://cloud.tencent.com/developer/article/1752784 1.1. 是什么如今大部分的后端服务都是基于微服务架构实现的，服务按照业务划分被拆分，实现了服务的解耦，同时也带来了一些新的问题，比如不同业务之间的通信需要通过接口实现调用。两个服务之间要共享一个数据对象，就需要从对象转换成二进制流，通过网络传输，传送到对方服务，再转换成对象，供服务方法调用。这个编码和解码的过程我们称之为序列化和反序列化。 在高并发系统中，序列化的速度快慢，会影响请求的响应时间，序列化后的传输数据体积大，会导致网络吞吐量下降，所以，一个优秀的序列化框架可以提高系统的整体性能。 我们都知道 Java 提供了 RMI 框架可以实现服务与服务之间的接口暴露和调用，RMI 中对数据对象的序列化采用的是 Java 序列化。而目前主流的框架却很少使用到 Java 序列化，如 SpringCloud 使用的 Json 序列化，Dubbo 虽然兼容了 Java 序列化，但是默认还是使用的 Hessian 序列化。 Java 序列化 首先，来看看什么是 Jav ...

1. 性能评价指标1.1. 响应时间提交请求和返回该请求的响应之间使用的时间，一般比较关注平均响应时间。常用操作的响应时间列表: 1.2. 并发数同一时刻，对服务器有实际交互的请求数。和网站在线用户数的关联:1000 个同时在线用户数，可以估计并发数在 5% 到 15% 之间， 也就是同时并发数在 50~150 之间。 1.3. 吞吐量2. 优化策略2.1. 避免过早优化不应该把大量的时间耗费在小的性能改进上，过早考虑优化是所有噩梦的根源。 所以，我们应该编写清晰，直接，易读和易理解的代码，真正的优化应该留到以后，等到 性能分析表明优化措施有巨大的收益时再进行。 但是过早优化，不表示我们应该编写已经知道的对性能不好的的代码结构。 2.2. 进行系统性能测试所有的性能调优，都有应该建立在性能测试的基础上，直觉很重要，但是要用数据说话，可以推测，但是要通过测试求证 2.3. 寻找系统瓶颈，分而治之，逐步优化性能测试后，对整个请求经历的各个环节进行分析，排查出现性能瓶颈的地方，定位问题，分析影响性能的的主要因素是什么?内存、磁盘 IO、网络、CPU，还是代码问题?架构设计不足?或者确实是系 ...

瘦富客户端https://blog.csdn.net/ArvinSnow/article/details/87254362https://blog.51cto.com/evan2008/107090 富客户端端技术充分利用本地机器的处理能力来处理数据，而不需要把某些数据发送到服务器处理，充分利用了本地机器的资源。 DWZFLEX 瘦客户端然而随着应用向互联网上迁移，客户端数量剧增，维护和升级成为一件极其困难的事情。这个时候，人们想到了要给客户端“瘦身”，就是把业务层逻辑交给服务器端来完成，客户端仅仅完成人机交互界面和用于呈现运算结果。于是 B/S 模式诞生了，客户端被浏览器所代替。 Flexhttps://blog.csdn.net/ArvinSnow/article/details/87254362 实战经验参考与感谢https://www.slideshare.net/yiditushe/flex3

业务埋点模仿业界的神策等，自研探针组件 实战经验参考与感谢[[APM 数据采集的两种方式深入对比——探针埋点VS互联数据_应用]] https://www.woshipm.com/data-analysis/4377422.html 基本原理-3、字节码增强

1. 背景知识1.1. JavaScript 解析引擎 1.2. 后端开发方式 2. 什么是 nodejs 3. 模块化 4. 包管理工具4.1. 多人协作 5. Express 6. 跨域问题 7. Web 开发模式 8. 身份认证 9. 实战经验10. 参考与感谢10.1. 黑马10.1.1. 视频https://www.bilibili.com/video/BV1DS4y1Y7L4/?spm_id_from=..search-card.all.click&vd_source=c5b2d0d7bc377c0c35dbc251d95cf204 10.1.2. 资料网络笔记https://blog.csdn.net/m0_52316372/article/details/124759435?spm=1001.2014.3001.5502

1. 特性大规模容器编排系统 kubernetes 具有以下特性： 服务发现和负载均衡Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果进入容器的流量很大， Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。 存储编排Kubernetes 允许你自动挂载你选择的存储系统，例如本地存储、公共云提供商等。 自动部署和回滚你可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态 更改为期望状态。例如，你可以自动化 Kubernetes 来为你的部署创建新容器， 删除现有容器并将它们的所有资源用于新容器。 自动完成装箱计算Kubernetes 允许你指定每个容器所需 CPU 和内存（RAM）。 当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。 自我修复Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的 运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。 密钥与配置管理Kubernetes 允许你存储和管理敏感信息，例如密码、OAuth 令牌和 ssh ...