<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[u010889990的专栏]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/u010889990</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; u010889990]]></copyright><item><title><![CDATA[面试官非得跟我抬杠，说MQ挂了怎么办？]]></title><link>https://blog.youkuaiyun.com/u010889990/article/details/120147411</link><guid>https://blog.youkuaiyun.com/u010889990/article/details/120147411</guid><author>u010889990</author><pubDate>Mon, 06 Sep 2021 23:25:03 +0800</pubDate><description><![CDATA[原创：猿天地（微信公众号ID：cxytiandi），欢迎分享，转载请保留出处。

一位读者跟我说，最近去某个公司面试，面试官非得问他MQ挂了如何处理？这位读者说当时也比较懵，因为在日常工作中也没去想过这样的问题，就回答：挂了就报错了呗**，**马上重启呗，还能咋处理。
其实这个问题也并不是说这位面试官是一种抬杠的行为，因为MQ确实有可能挂掉，是一种正常现象。只不过是说这个挂的概率非常小，毕竟都是集群模式。
如果是平时跟朋友，同事聊这个问题，怎么回答都没问题。如果是在面试过程中，还是得仔细想想如何去回答比较.]]></description><category></category></item><item><title><![CDATA[面试高频题：讲讲项目中的技术难点？]]></title><link>https://blog.youkuaiyun.com/u010889990/article/details/118856290</link><guid>https://blog.youkuaiyun.com/u010889990/article/details/118856290</guid><author>u010889990</author><pubDate>Sat, 17 Jul 2021 14:26:55 +0800</pubDate><description><![CDATA[原创：猿天地（微信公众号 ID：cxytiandi），欢迎分享，转载请保留出处。

相信很多人都有类似的经历，在面试快要结束的时候经常会被问到一个问题：讲讲项目中的技术难点？
这是一个比较开放的问题，首先它没有固定的答案，因为每个人做过的项目不同，使用的框架不同，对应的架构不同，自然遇到的技术难点也不同。
1. 一定要真实
在回答这个问题的时候，一定要仔细想想之前真实遇到的问题，不要随便编一个，这样很容易出问题，因为面试官会顺着细节一层层的问下去，如果你是编出来的，到最后就圆不回去了。
举个例子：
求职者.]]></description><category></category></item><item><title><![CDATA[宝，我今天CR了，C的什么R? 走过场的CR]]></title><link>https://blog.youkuaiyun.com/u010889990/article/details/118249439</link><guid>https://blog.youkuaiyun.com/u010889990/article/details/118249439</guid><author>u010889990</author><pubDate>Sat, 26 Jun 2021 14:54:58 +0800</pubDate><description><![CDATA[原创：猿天地（微信公众号ID：cxytiandi），欢迎分享，转载请保留出处。

CodeReview我相信目前很多公司都会有这么一个流程，关键是这个流程有没有用就很难讲。主要还是取决于你对CR的理解以及有没有真正的去落地CR，去重视CR带来的隐藏价值点。
正好最近也是有人在问我CR相关的问题，他们也要开始做CR了，想了解下有没有最佳实践之类的。所以今天跟大家聊聊CR这个话题，我说的也不一定都是对的，仅供参考哈。
其实说实话，我觉得CR不存在什么最佳实践。因为每个公司或者说每个团队所进行的方式都会不一样，.]]></description><category></category></item><item><title><![CDATA[被监控轰炸了，不得不使出绝招]]></title><link>https://blog.youkuaiyun.com/u010889990/article/details/118053485</link><guid>https://blog.youkuaiyun.com/u010889990/article/details/118053485</guid><author>u010889990</author><pubDate>Sat, 19 Jun 2021 14:31:34 +0800</pubDate><description><![CDATA[原创：猿天地（微信公众号ID：cxytiandi），欢迎分享，转载请保留出处。

监控这个话题永远都不会过时，之前也有跟大家聊过监控的内容，以及如何快速实现监控满足日常需求。比如基于日志告警，基于全局异常处理器告警，基于Cat，Prometheus，Sentry等告警。
无论公司是什么规模，创业小公司，稳定大公司，你都需要做监控的呀。特别是大公司的监控做的更全，也更在意监控这件事情。小公司相对来说会好点，因为业务可能还不是很稳定，用户少，出故障就出呗，能修复就行。
监控的痛点
有监控总比没监控要强吧，但是.]]></description><category></category></item><item><title><![CDATA[解决甩锅的一大难题，就是留个凭证]]></title><link>https://blog.youkuaiyun.com/u010889990/article/details/117605131</link><guid>https://blog.youkuaiyun.com/u010889990/article/details/117605131</guid><author>u010889990</author><pubDate>Sat, 05 Jun 2021 20:28:52 +0800</pubDate><description><![CDATA[原创：猿天地（微信公众号ID：cxytiandi），欢迎分享，转载请保留出处。

在多个团队之间的一些业务关联上，内部可以Rpc的方式进行交互。某些业务其实不需要强关联，这个时候就会用消息队列进行解耦操作。比如下单后加积分，发短信通知的这类操作。
在用消息队列的时候，我们最需要关注的一个问题就是消息会不会丢失？
这里的丢失指的就是要么你程序有问题，没有发送出去。要么发送出去了，但是在某个节点上消息丢掉了，导致消费方没有收到你发送的消息，从而引发业务问题。
对于消息丢失，有很多的解决方案。本文不聊怎么在技术.]]></description><category></category></item><item><title><![CDATA[后期数据库主从架构的痛点，真的痛]]></title><link>https://blog.youkuaiyun.com/u010889990/article/details/117167521</link><guid>https://blog.youkuaiyun.com/u010889990/article/details/117167521</guid><author>u010889990</author><pubDate>Sat, 22 May 2021 17:42:28 +0800</pubDate><description><![CDATA[原创：猿天地（微信公众号ID：cxytiandi），欢迎分享，转载请保留出处。

读写分离是什么？读写分离的作用就不讲了，如果有不了解的同学可以自己去搜索资料进行了解。或者查看我之前的文章读写分离。
一开始的场景肯定都基于主库去做增删改查的操作，等后面压力慢慢上来后才会考虑加数据库的从节点，通过读写分离的方式来提高查询的性能。

首先读写分离默认查询都是走从节点的。

从我们的使用习惯或者业务的场景来说，查询的场景是大于增删改的。所以我们会在需要走主库进行数据操作的业务场景下，手动去控制这条Sql要去主库.]]></description><category></category></item><item><title><![CDATA[不看源码，怎么卷的过小年轻]]></title><link>https://blog.youkuaiyun.com/u010889990/article/details/116563568</link><guid>https://blog.youkuaiyun.com/u010889990/article/details/116563568</guid><author>u010889990</author><pubDate>Sun, 09 May 2021 13:08:20 +0800</pubDate><description><![CDATA[原创：猿天地（微信公众号ID：cxytiandi），欢迎分享，转载请保留出处。

在工作中，我相信很多人都有下面这样的感受：

这谁的代码呀，看不下去了
这破代码，一行注释也没有
这代码，还没我写的好
这代码，有bug吧
这代码，。。。。。。。

是不是很真实，我们往往在看别人代码的时候就会有上面这些想法。我认为主要的原因还是大部分看的都是业务代码，而且很多是多年积累下来的，也没有重构，然后一年年的堆逻辑，最后就变成shi山了。
当然也有不少的人代码写的确实很好，简洁易懂，我们在看别人代码的时候要抱着学习.]]></description><category></category></item><item><title><![CDATA[太强大了，Feign对接YAPI实现自动Mock]]></title><link>https://blog.youkuaiyun.com/u010889990/article/details/116563564</link><guid>https://blog.youkuaiyun.com/u010889990/article/details/116563564</guid><author>u010889990</author><pubDate>Sun, 09 May 2021 13:07:12 +0800</pubDate><description><![CDATA[原创：猿天地（微信公众号ID：cxytiandi），欢迎分享，转载请保留出处。

前面我们介绍了在微服务架构下如何解决单测时 Mock 的问题，通过 Mock 可以在单测时不依赖其他服务的实现。在文章最后我也给大家提供了一个思考题：是不是可以模拟前端对后端的处理方式，走 Yapi 的 Mock 功能？ 这样就不用自己手动的对每个接口去 Mock 了。
首先我们需要定义一个 Mock 的配置类，用于配置哪些远程调用需要进行 Mock。
@Data
@Configuration
@ConfigurationP.]]></description><category></category></item><item><title><![CDATA[微服务接口单测依赖问题一次性搞定]]></title><link>https://blog.youkuaiyun.com/u010889990/article/details/115841010</link><guid>https://blog.youkuaiyun.com/u010889990/article/details/115841010</guid><author>u010889990</author><pubDate>Sun, 18 Apr 2021 22:05:05 +0800</pubDate><description><![CDATA[在微服务架构中，服务之间的依赖是很常见的事情。在开发过程中都是并行开发的，前端会依赖后端的接口，后端也有可能会依赖其他后端服务的接口。
项目整体提测后是没有问题的，因为大家都开发完了，也会同时部署到测试环境中。但是在开发过程中需要进行单测，单测的时候会依赖其他的服务，这个时候就需要解决这个依赖问题。
前端依赖后端接口
前端依赖后端接口，一般会提前将接口定义好，然后拉上前端同学一起评审。如果没有问题就各自去开发，那么前端同学在自测的时候是需要数据的，这个时候可以采用 Mock 的方式提供数据。
关于 Mock]]></description><category></category></item><item><title><![CDATA[monkey-api-encrypt又增强了一个实用功能]]></title><link>https://blog.youkuaiyun.com/u010889990/article/details/115578467</link><guid>https://blog.youkuaiyun.com/u010889990/article/details/115578467</guid><author>u010889990</author><pubDate>Sat, 10 Apr 2021 15:49:12 +0800</pubDate><description><![CDATA[框架主页：https://github.com/yinjihuan/monkey-api-encrypt
背景
有阵子没更新 monkey-api-encrypt 这个框架了，然后看了下 Github 上一些用户提的问题，挑了一个比较实用的进行了修复。
说问题之前先简单的讲下 monkey-api-encrypt 的原理，目前 monkey-api-encrypt 中核心部分就是用了 javax.servlet.Filter 来对数据进行加解密的处理，实现也比较简单。
唯一要注意的就是在 Filter 中如]]></description><category></category></item><item><title><![CDATA[慌了，老大让我将线上的服务器升配，咋搞？]]></title><link>https://blog.youkuaiyun.com/u010889990/article/details/115371538</link><guid>https://blog.youkuaiyun.com/u010889990/article/details/115371538</guid><author>u010889990</author><pubDate>Thu, 01 Apr 2021 12:57:34 +0800</pubDate><description><![CDATA[在业务高速发展的时候，后端的压力慢慢变大，服务器扩容在所难免。今天就聊聊扩容相关的问题。
首先我们看数据库的扩容，到底是加实例还是直接升配？
在创业初期，基本上都是单库的形式。比如最开始是4C8G的配置，到了某天数据库扛不住了，但是数据量其实没那么大，只是请求量上来了而已，或者由于研发写了很多复杂的Sql导致数据库性能下降了。
数据库加实例
这个时候最快的解决方式就是扩容了，首先我们来看加实例的方式，比如我们可以加N个从节点来提高查询的性能，可以对库进行垂直拆分或者水平拆分。
以上这些都是提高性能的方式，但]]></description><category></category></item><item><title><![CDATA[面试官再问你 ThreadLocal，就这样狠狠 “怼” 回去！]]></title><link>https://blog.youkuaiyun.com/u010889990/article/details/115206051</link><guid>https://blog.youkuaiyun.com/u010889990/article/details/115206051</guid><author>u010889990</author><pubDate>Thu, 25 Mar 2021 12:52:23 +0800</pubDate><description><![CDATA[本文大纲

用过ThreadLocal吗？在什么场景下会使用ThreadLocal
讲讲ThreadLocal的原理吧！
使用ThreadLocal有什么需要注意的吗？
有什么方式能提高ThreadLocal的性能吗？
如何将ThreadLocal的数据传递到子线程中？
线程池中如何实现ThreadLocal的数据传递？

用过ThreadLocal吗？在什么场景下会使用ThreadLocal。
这个回答一定要足够自信：必须用过啊，无论是在平时的业务开发过程中会用到，其他很多三方框架中也都用到了Thread]]></description><category></category></item><item><title><![CDATA[Spring Cloud 2020: Hystrix不生效怪我咯]]></title><link>https://blog.youkuaiyun.com/u010889990/article/details/115005053</link><guid>https://blog.youkuaiyun.com/u010889990/article/details/115005053</guid><author>u010889990</author><pubDate>Fri, 19 Mar 2021 14:04:20 +0800</pubDate><description><![CDATA[好像没写相关的文章了，正好最近有朋友问我一些关于新版本中遇到的问题。
2020.0.1这个版本是目前最新的版本，也是变动最大的一个版本。最大的变动莫过于将Netflix OSS的组件进行了移除操作。今天的问题也是跟这个有关系，大家通过标题就可以知道。
虽然移除了Netflix的组件，但是对于初学者来说，市面上大部分书籍或者文章都是老的版本，也都是用的Netflix里面的组件。在学习的时候自然的选择了最新的版本，但是没有仔细的去看官方文档，也不知道最新版已经进行了移除，在用的时候还是按照老版本的方式去使用这些]]></description><category></category></item><item><title><![CDATA[主动做了业务监控，产品经理对我竖起大拇指]]></title><link>https://blog.youkuaiyun.com/u010889990/article/details/114369066</link><guid>https://blog.youkuaiyun.com/u010889990/article/details/114369066</guid><author>u010889990</author><pubDate>Thu, 04 Mar 2021 15:12:58 +0800</pubDate><description><![CDATA[监控，一直是个可以聊很久的话题。除了系统监控，还有一个往往容易被忽略，今天我们就来聊聊这个容易忽略的业务监控。
监控什么？
作为开发人员，不仅仅是把功能开发出来就行了，对于你负责的产品或者模块，你需要对它有足够的了解，时时刻刻需要关注着，要有初恋的那种感觉才行。
以电商最常见的下单功能来说，比如我想知道下单的成功率多少，下单的平均耗时，下单失败中有多少是因为库存不足下单失败的等等这类相关的信息。
有了这些业务指标信息，你就能知道你负责的产品现状是什么样的，以及你需要做哪些改进。
至于要监控哪些指标，得跟着你]]></description><category></category></item><item><title><![CDATA[用了很多年Dubbo，连Dubbo线程池监控都不知道，觉得自己很厉害？]]></title><link>https://blog.youkuaiyun.com/u010889990/article/details/113745874</link><guid>https://blog.youkuaiyun.com/u010889990/article/details/113745874</guid><author>u010889990</author><pubDate>Sun, 07 Feb 2021 19:01:27 +0800</pubDate><description><![CDATA[前言
micrometer中自带了很多其他框架的指标信息，可以很方便的通过prometheus进行采集和监控，常用的有JVM的信息，Http请求的信息，Tomcat线程的信息等。
对于一些比较活跃的框架，有些还是不支持的，比如Dubbo。如果想监控Dubbo的一些指标，比如线程池的状况，我们需要手动去扩展，输出对应的线程池指标才行。
在这种情况下，肯定是没什么思路的，因为你不知道怎么去扩展，下面给大家介绍去做一件事情之前的思考，方式方法很重要。

Dubbo有没有现成的实现?
参考micrometer中指标]]></description><category></category></item><item><title><![CDATA[Prometheus为你的SpringBoot应用保驾护航]]></title><link>https://blog.youkuaiyun.com/u010889990/article/details/113513822</link><guid>https://blog.youkuaiyun.com/u010889990/article/details/113513822</guid><author>u010889990</author><pubDate>Mon, 01 Feb 2021 14:00:53 +0800</pubDate><description><![CDATA[前面我们介绍了Prometheus的作用和整体的架构，相信大家对Prometheus有了一定的了解。
具体可以查看这篇文章：https://mp.weixin.qq.com/s/QoAs0-AYy8krWTa3HbmJZA
今天着重介绍下如何在项目中将Prometheus用起来，结合漂亮的图表做数据展示，真的非常帅气。
使用之前先介绍一个Micrometer，Micrometer 是一款监控指标的度量类库，提供了对各种指标的监控。比如JVM, 线程池，数据库连接池等。
官方网站：https://microm]]></description><category></category></item><item><title><![CDATA[在冷风中我凌乱了半小时，只因健康码刷不出来]]></title><link>https://blog.youkuaiyun.com/u010889990/article/details/113193297</link><guid>https://blog.youkuaiyun.com/u010889990/article/details/113193297</guid><author>u010889990</author><pubDate>Tue, 26 Jan 2021 20:40:05 +0800</pubDate><description><![CDATA[聊聊小背景
前几天的早晨我早写字楼门口干等了半小时，背后的原因竟然是健康码的二维码刷不出来，保安小哥还一直跟我讲，支付宝出不来你用微信啊，用微信啊。。
他们用的相同的接口，我用微信有卵用啊，冷风中我甩了甩仅有的几根秀发，扬长而去。。。
作为程序员的我就开始了内心的吐槽大会：这咋做的啊，不行呀，这就打不开了，肯定没做优化，肯定没用缓存，肯定没做压力测试。。。。。
下面作为技术的视角来分析下这个场景的实现，以及可以怎么去优化。这只是我YY哈，真实场景别人是怎么实现的我也不清楚哈。
需求剖析
每个人都有一个对应的]]></description><category></category></item><item><title><![CDATA[ElasticSearch索引升级的小妙招]]></title><link>https://blog.youkuaiyun.com/u010889990/article/details/112982063</link><guid>https://blog.youkuaiyun.com/u010889990/article/details/112982063</guid><author>u010889990</author><pubDate>Fri, 22 Jan 2021 12:45:55 +0800</pubDate><description><![CDATA[ElasticSearch在使用的时候最麻烦的一点就是重建索引了，比如你改了数据类型那么就得重建索引。为了不影响当前正在使用的场景，需要有一个方案能够平滑升级。
大部分的资料都讲的是用ElasticSearch alias的方式来实现，今天我们讲下结合配置中心来实现。
划重点:
配置中心需要有2个配置：
orderIndexNameQuery：order
orderIndexNameJob: order

比如刚开始索引是order, 我们可以为这个索引进行升级，就跟API一样，增加版本的概念。比如在索引名]]></description><category></category></item><item><title><![CDATA[有了链路日志增强，排查Bug小意思啦！]]></title><link>https://blog.youkuaiyun.com/u010889990/article/details/112773914</link><guid>https://blog.youkuaiyun.com/u010889990/article/details/112773914</guid><author>u010889990</author><pubDate>Mon, 18 Jan 2021 12:55:34 +0800</pubDate><description><![CDATA[在工作中，相信大家最怕的一件事就是听到有人在工作群艾特你：某某功能报错啦。。。
然后你就得屁颠屁颠的去服务器看日志，日志量少还好点，多的话找起来太麻烦了。不太容易直接定位到关键地方。
东找找西找找，好不容易找到了报错的信息，却不知道当时的参数信息是什么，也不太好复现，太难了。。
改完还得写故障报告，美好的一天又没了。
要解决这类的痛点需要做下面几件事情：

日志收集
异常告警
日志增加链路
API响应增加traceId
异常时打印当前报错方法的参数
支持调试模式

日志收集
要解决的第一个问题就是日志的集中]]></description><category></category></item><item><title><![CDATA[写了一个慢接口，年终妥妥的325]]></title><link>https://blog.youkuaiyun.com/u010889990/article/details/112306959</link><guid>https://blog.youkuaiyun.com/u010889990/article/details/112306959</guid><author>u010889990</author><pubDate>Thu, 07 Jan 2021 12:36:22 +0800</pubDate><description><![CDATA[一个项目要想抗住越大的压力，那么每个API都得在最短的时间内响应，这样吞吐量才高。
在很多时候，开发压根没有去做过优化，等到某天压力上来时，系统就扛不住了。
举一个最常见的例子：
大家上班都会做地铁（土豪可以开车哈）吧，地铁都有固定的几个入口，每个入口有几个固定的闸机可以扫码进入。
如果每个人扫码进站的时间都控制在2秒内，那么一个闸机一分钟可以过30个人。如果有一个人他在那磨蹭半天，花了20秒，也就是这个闸机这一分钟只能过21个人，吞吐量立马就下降了。
这种生活中的案例在程序的世界中也是同样适用的，而且是一]]></description><category></category></item></channel></rss>