<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[张维鹏的博客]]></title><description><![CDATA[芝兰生于幽谷，不以无人而不芳！]]></description><link>https://blog.youkuaiyun.com/a745233700</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; a745233700]]></copyright><item><title><![CDATA[《卓有成效的工程师》读书笔记]]></title><link>https://blog.youkuaiyun.com/a745233700/article/details/126964874</link><guid>https://blog.youkuaiyun.com/a745233700/article/details/126964874</guid><author>a745233700</author><pubDate>Wed, 21 Sep 2022 10:01:45 +0800</pubDate><description><![CDATA[本书通过“杠杆率“，用来推断、分析工作的有效性与影响力，研究并说明了如何成为一名卓有成效的软件工程师。更为重要的是，本书包含了一系列可落地且经过验证的策略作为框架的补充，读者可以应用这些策略来提高工作成效。本书的主题分为三个部分：从提高成效的思维模式入手，深入探讨持续提升执行力并取得工作进展的关键策略，在第三部分转换角度，阐述了研究创造长期价值的方法。通过阅读本书，读者能够获得高价值的思维启发和实践经验，在成为卓有成效的工程师同时，打造高效的软件工程团队]]></description><category></category></item><item><title><![CDATA[SonarQube代码质量检查平台]]></title><link>https://blog.youkuaiyun.com/a745233700/article/details/126326765</link><guid>https://blog.youkuaiyun.com/a745233700/article/details/126326765</guid><author>a745233700</author><pubDate>Tue, 16 Aug 2022 11:20:15 +0800</pubDate><description><![CDATA[SonarQube 是一个代码质量管理的开源平台，通过 SonarQube 提供的代码扫描、质量阈值卡点等质量红线，我们可以提升系统的可靠性，提前捕获和提示代码中的错误，从而避免未定义的行为影响到用户，保证业务质量，也能确保管理的代码库干净并且可维护，以便提高开发人员的开发效率。另外 SonarQube 也可以生成详细的代码分析质量报告，并通过强大的仪表盘展示出来，使我们能够根据角色的不同，查看不同维度的度量标准。...]]></description><category></category></item><item><title><![CDATA[代码质量管控的四个阶段]]></title><link>https://blog.youkuaiyun.com/a745233700/article/details/126327098</link><guid>https://blog.youkuaiyun.com/a745233700/article/details/126327098</guid><author>a745233700</author><pubDate>Mon, 15 Aug 2022 08:45:00 +0800</pubDate><description><![CDATA[质量、功能和进度，是一个软件项目的三根支柱，但在现实项目中，当质量和其它两项产生冲突时，往往是作为被牺牲的对象。团队对于质量的态度主要停留在口头重视上，似乎还没有上升到团队意识的高度，也缺乏必要的保障手段。但没有质量的功能，从它面世第一天就开始永无止境的修补，并最终走向被重写的命运；没有质量的进度，只能是一个虚伪的承诺，因为接踵而至的，是一轮又一轮的附加开销，有效进度被大大拖延。要想提升代码质量，首先需要确立质量意识。...]]></description><category></category></item><item><title><![CDATA[IDEA插件之代码质量检查利器 - Alibaba Java Coding Guidelines、CheckStyle、PMD、FindBugs、SonarLint]]></title><link>https://blog.youkuaiyun.com/a745233700/article/details/126202100</link><guid>https://blog.youkuaiyun.com/a745233700/article/details/126202100</guid><author>a745233700</author><pubDate>Mon, 15 Aug 2022 08:30:00 +0800</pubDate><description><![CDATA[随着业务的发展，系统会越来越庞大，原本简单稳定的功能，可能在不断迭代后复杂度上升，潜在的风险也随之暴露，导致最终服务不稳定，造成业务价值的损失。而为了减少这种情况，其中一种比较好的方式就是提高代码质量，从而降低错误风险。工欲善其事，必先利其器，这篇文章给大家介绍几种检查代码质量的利器：Alibaba Java Coding Guidelines、CheckStyle、PMD、FindBugs、SonarLint...]]></description><category></category></item><item><title><![CDATA[Skywalking全链路追踪使用说明]]></title><link>https://blog.youkuaiyun.com/a745233700/article/details/124456810</link><guid>https://blog.youkuaiyun.com/a745233700/article/details/124456810</guid><author>a745233700</author><pubDate>Sun, 01 May 2022 08:00:00 +0800</pubDate><description><![CDATA[随着系统的复杂度也越来越高，我们软件架构也进入了分布式阶段，一次请求可能横跨多个服务模块、项目，依赖的中间件也越来越多，其中任何一个节点出现异常，都可能导致业务出现波动或者异常。而传统的日志监控等方式无法很好满足调用链路跟踪，排查问题等需求，这就导致定位/诊断服务异常变得异常复杂。因此面对复杂的调用链路，我们需要一款具体如下功能全链路追踪工具，提高我们对业务的掌控度：
①请求链路追踪，快速定位故障；②可视化链路各阶段的耗时，进行性能分析；③ 梳理服务依赖关系；④ 系统指标监控，吞吐量、响应时间及错误记录等]]></description><category></category></item><item><title><![CDATA[Spring Cloud Gateway 整合 sentinel 实现流控熔断]]></title><link>https://blog.youkuaiyun.com/a745233700/article/details/122917160</link><guid>https://blog.youkuaiyun.com/a745233700/article/details/122917160</guid><author>a745233700</author><pubDate>Mon, 14 Feb 2022 08:30:00 +0800</pubDate><description><![CDATA[在微服务架构中，网关层可以屏蔽外部服务直接对内部服务进行调用，对内部服务起到隔离保护的作用，网关限流，顾名思义，就是通过网关层对服务进行限流，从而达到保护后端服务的作用。如果已经在网关层面做了限流，那么躲在身后的服务是否就安全了呢？答案是否定的，因此最常见的解决方案是：网关层集群限流+内部服务的单机限流兜底，这样才能保证不被流量冲垮]]></description><category></category></item><item><title><![CDATA[Spring Cloud Gateway 服务网关的部署与使用详细介绍]]></title><link>https://blog.youkuaiyun.com/a745233700/article/details/122917167</link><guid>https://blog.youkuaiyun.com/a745233700/article/details/122917167</guid><author>a745233700</author><pubDate>Mon, 14 Feb 2022 08:15:00 +0800</pubDate><description><![CDATA[网关作为系统的唯一流量入口，封装内部系统的架构，所有请求都先经过网关，由网关将请求路由到合适的微服务，所以，使用网关的好处在于：（1）简化客户端的工作。网关将微服务封装起来后，客户端只需同网关交互，而不必调用各个不同服务；（2）降低函数间的耦合度。 一旦服务接口修改，只需修改网关的路由策略，不必修改每个调用该函数的客户端，从而减少了程序间的耦合性（3）解放开发人员把精力专注于业务逻辑的实现。由网关统一实现服务路由(灰度与ABTest)、负载均衡、访问控制、流控熔断降级等非业务相关功能]]></description><category></category></item><item><title><![CDATA[SpringCloud Ribbon负载均衡 + OpenFeign远程HTTP调用用法与原理]]></title><link>https://blog.youkuaiyun.com/a745233700/article/details/122916856</link><guid>https://blog.youkuaiyun.com/a745233700/article/details/122916856</guid><author>a745233700</author><pubDate>Mon, 14 Feb 2022 08:00:00 +0800</pubDate><description><![CDATA[openFeign 作为微服务架构下服务间调用的解决方案，是一种声明式、模板化的 HTTP 的模板，使 HTTP 请求就像调用本地方法一样，通过 openFeign 可以替代基于 RestTemplate 的远程服务调用，并且默认集成了 Ribbon 进行负载均衡。目标是减少 HTTP API 的复杂性，希望能将 HTTP 远程服务调用做到像 RPC 一样易用。...]]></description><category></category></item><item><title><![CDATA[SpringCloud LoadBalancerClient 负载均衡原理]]></title><link>https://blog.youkuaiyun.com/a745233700/article/details/122916708</link><guid>https://blog.youkuaiyun.com/a745233700/article/details/122916708</guid><author>a745233700</author><pubDate>Mon, 14 Feb 2022 07:45:00 +0800</pubDate><description><![CDATA[LoadBalancerClient 在初始化时会通过 Eureka Client 向 Eureka 服务端获取所有服务实例的注册信息并缓存在本地，并且每10秒向 EurekaClient 发送 “ping”，来判断服务的可用性。如果服务的可用性发生了改变或者服务数量和之前的不一致，则更新或者重新拉取。最后，在得到服务注册列表信息后，ILoadBalancer 根据 IRule 的策略进行负载均衡（默认策略为轮询）。]]></description><category></category></item><item><title><![CDATA[Nacos配置中心用法详细介绍]]></title><link>https://blog.youkuaiyun.com/a745233700/article/details/122916208</link><guid>https://blog.youkuaiyun.com/a745233700/article/details/122916208</guid><author>a745233700</author><pubDate>Mon, 14 Feb 2022 07:45:00 +0800</pubDate><description><![CDATA[配置中心区别于传统的配置信息分散到系统各个角落的方式，对系统中的配置文件进行集中统一管理，而不需要逐一对单个的服务器进行管理。通过配置中心，可以使得配置标准化、格式统一化；当配置信息发生变动时，修改实时生效，无需要重新重启服务器，就能够自动感知相应的变化，并将新的变化统一发送到相应程序上，快速响应变化；通过审计功能还可以追溯问题]]></description><category></category></item><item><title><![CDATA[Nacos注册中心的部署与用法详细介绍]]></title><link>https://blog.youkuaiyun.com/a745233700/article/details/122915663</link><guid>https://blog.youkuaiyun.com/a745233700/article/details/122915663</guid><author>a745233700</author><pubDate>Mon, 14 Feb 2022 07:30:00 +0800</pubDate><description><![CDATA[注册中心是微服务架构中的纽带，类似于”通讯录“，它记录了服务和服务地址的映射关系。在分布式架构中，服务会注册到这里，当服务需要调用其它服务时，就到这里找到服务的地址并进行调用。注册中心本质上是为了解耦服务提供者和服务消费者，除此之外还能对服务进行动态管理，降低服务端负载均衡中间件的压力]]></description><category></category></item><item><title><![CDATA[Spring Cloud Gateway 整合 knife4j 聚合接口文档]]></title><link>https://blog.youkuaiyun.com/a745233700/article/details/122917137</link><guid>https://blog.youkuaiyun.com/a745233700/article/details/122917137</guid><author>a745233700</author><pubDate>Mon, 14 Feb 2022 01:28:56 +0800</pubDate><description><![CDATA[当系统中微服务数量越来越多时，如果任由这些服务散落在各处，那么最终管理每个项目的接口文档将是一件十分麻烦的事情，单是记住所有微服务的接口文档访问地址就是一件苦差事了。当如果能够将所有微服务项目的接口文档都统一汇总在同一个可视化页面，那么将大大减少我们的接口文档管理维护工作，为此，我们可以基于 Spring Cloud Gateway 网关 + nacos + knife4j 对所有微服务项目的接口文档进行聚合，从而实现我们想要的文档管理功能]]></description><category></category></item><item><title><![CDATA[ElasticSearch搜索引擎：数据的写入流程]]></title><link>https://blog.youkuaiyun.com/a745233700/article/details/118076845</link><guid>https://blog.youkuaiyun.com/a745233700/article/details/118076845</guid><author>a745233700</author><pubDate>Mon, 07 Feb 2022 08:00:00 +0800</pubDate><description><![CDATA[（1）ES 客户端选择一个节点 node 发送请求过去，这个节点就是协调节点 coordinating node
（2）协调节点对 document 进行路由，通过 hash 算法计算出数据应该落在哪个分片shard 上，然后根据节点上维护的 shard 信息，将请求转发到对应的实际处理节点node上
（3）实际的节点上的primary shard 主分片处理请求，然后将数据同步到副本节点
（4）coordinating node 等到primary node 和所有 replica node 都执]]></description><category></category></item><item><title><![CDATA[ElasticSearch搜索引擎： 内存分析与设置]]></title><link>https://blog.youkuaiyun.com/a745233700/article/details/117917338</link><guid>https://blog.youkuaiyun.com/a745233700/article/details/117917338</guid><author>a745233700</author><pubDate>Mon, 07 Feb 2022 08:00:00 +0800</pubDate><description><![CDATA[在Elasticsearch 的运行过程中，如何合理分配与设置内存是一件十分重要的事情，否则十分容易出现各种问题。



一、Elasticsearch为什么吃内存：

我们先看下 ES 服务器的总体内存消耗情况：




对于Query Cache、Request Cache、FieldData Cache 以及 Segment 的介绍，在前面的文章以及介绍过了，这里就不重复介绍了：

Elasticsearch搜索引擎之缓存：Request Cache、Query Cache、Fiel...]]></description><category></category></item><item><title><![CDATA[sentinel 限流熔断神器详细介绍]]></title><link>https://blog.youkuaiyun.com/a745233700/article/details/122733366</link><guid>https://blog.youkuaiyun.com/a745233700/article/details/122733366</guid><author>a745233700</author><pubDate>Fri, 28 Jan 2022 17:43:14 +0800</pubDate><description><![CDATA[Sentinel 是一款面向分布式服务架构的轻量级流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统自适应保护等多个维度来保障服务的稳定性，核心思想是：根据对应资源配置的规则来为资源执行相应的流控/降级/系统保护策略，]]></description><category></category></item><item><title><![CDATA[Sentinel 规则持久化到 apollo 配置中心]]></title><link>https://blog.youkuaiyun.com/a745233700/article/details/122725604</link><guid>https://blog.youkuaiyun.com/a745233700/article/details/122725604</guid><author>a745233700</author><pubDate>Fri, 28 Jan 2022 00:28:04 +0800</pubDate><description><![CDATA[Sentinel 规则默认是存储在内存中的，只要服务重启之后对应的规则也会消失，实际的生产中肯定是不允许这种操作，因此 Sentinel 官方推荐在生产架构中使用第三方数据源作为永久存储中心，比如 nacos、apollo、zookeeper。因为这几种数据源都是基于 push 模式，也就是由规则中心统一推送，Sentinel Client 只需通过注册监听器的方式时刻监听变化，并负责获取配置中心推送的配置并更新到本地，这种方式能更好的保证实时性和一致性，并且各个微服务的限流、降级规则都可以永久存储。]]></description><category></category></item><item><title><![CDATA[Java IO篇：什么是零拷贝？]]></title><link>https://blog.youkuaiyun.com/a745233700/article/details/122660332</link><guid>https://blog.youkuaiyun.com/a745233700/article/details/122660332</guid><author>a745233700</author><pubDate>Mon, 24 Jan 2022 08:15:00 +0800</pubDate><description><![CDATA[在传统的数据 IO 模式中，读取一个磁盘文件，并发送到远程端的服务，就共有四次用户空间与内核空间的上下文切换，四次数据复制，分别是两次 CPU 数据复制，两次 DMA 数据复制。零拷贝指在进行数据 IO 或传输时，数据在用户态下经历了零次拷贝，并非不拷贝数据。通过减少数据传输过程中 内核缓冲区和用户进程缓冲区间不必要的 CPU数据拷贝 与 用户态和内核态的上下文切换次数，降低 CPU 在这两方面的开销，释放 CPU 执行其他任务，更有效的利用系统资源，提高传输效率，同时还减少了内存的占用，提升应用程序的性能]]></description><category></category></item><item><title><![CDATA[RocketMQ事务消息原理]]></title><link>https://blog.youkuaiyun.com/a745233700/article/details/122656108</link><guid>https://blog.youkuaiyun.com/a745233700/article/details/122656108</guid><author>a745233700</author><pubDate>Mon, 24 Jan 2022 08:15:00 +0800</pubDate><description><![CDATA[基于MQ的分布式事务方案，本质上是对本地消息表的一个封装，整体流程与本地消息表一致，唯一不同的就是将本地消息表存在了MQ内部，而不是业务数据库，事务消息解决的是生产端的消息发送与本地事务执行的原子性问题，确保 MQ 生产端正确无误地将消息发送出来，没有多发，也不会漏发，至于发送后消费端有没有正常的消费消息，这种异常场景将由 MQ 消息消费失败重试机制来保证。]]></description><category></category></item><item><title><![CDATA[堆栈分析-服务器问题定位]]></title><link>https://blog.youkuaiyun.com/a745233700/article/details/122660058</link><guid>https://blog.youkuaiyun.com/a745233700/article/details/122660058</guid><author>a745233700</author><pubDate>Mon, 24 Jan 2022 08:00:00 +0800</pubDate><description><![CDATA[日常开发中，我们常见的服务器问题主要可以归类为一下几种：CPU过载问题、内存过高问题、磁盘IO问题、网络问题。当服务器出现问题时，我们一般可以按照以下思路进行定位：
① 如果最近有版本发布，则先从代码提交记录中分析最新版本代码是否存在问题；② 使用 ps、top等命令分析线程状态；③ 先将出现异常的服务器下线并保留服务器环境，接着使用 jstack 导出线程快照信息以及使用 jmap 导出堆栈内存日志进行分析，该命令会会线上服务器性能造成影响，所以执行前先下线服务器防止对用户造成影响...]]></description><category></category></item><item><title><![CDATA[JUC多线程：线程的中断停止]]></title><link>https://blog.youkuaiyun.com/a745233700/article/details/122641839</link><guid>https://blog.youkuaiyun.com/a745233700/article/details/122641839</guid><author>a745233700</author><pubDate>Mon, 24 Jan 2022 08:00:00 +0800</pubDate><description><![CDATA[对于线程的停止，通常情况下我们是不会去手动去停止的，而是等待线程自然运行至结束，但在实际开发中，很多情况中需要我们提前去手动来停止线程，比如程序中出现异常错误、使用者关闭程序等情况中。如果不能很好地停止线程那么可能会导致各种问题，所以正确的停止线程是非常的重要的，常见的中断线程的方式有以下几种：
① 方式一：使用 Thread 类的 stop() 方法来终止线程；
② 方式二：根据 volatile 修饰的标志位判断线程是否需要中断；
③ 方式三：通过 interrupt中断机制终止线程；]]></description><category></category></item></channel></rss>