Hello，大家好，最近两周一直在加班，9106 的节奏的，真的是累成狗了。不过最近项目进入提测，就稍微闲了一点。 上周的时候，看了一场架构师之路沈剑老师的一场直播，最近又重温了一下，根据自己的认知总结了一下，分享给大家。 MQ 想必大家或多或少都用过，接入 MQ 之后的整体架构如下： 可以看到使用 MQ 之后，上下游通信就变成图上的这种方式。 这种跨进程的通信方式，我们还有一种常用的解决方案，使用 Dubbo 等这类 RPC 服务。 理论上使用 RPC 的跨进程通信的场景，使用 MQ 也能解决，当然反过来也能说通。 那为什么不都用 RPC，或者 MQ 来解决那？ 这其实都是业务场景决定的，抛开业务场景来谈架构都是耍流氓！没有全能的架构，只要适合的架构。 下面我们来看看那些场景适合 RPC，而那些场景适合 MQ。 RPC 场景 使用 RPC 的场景一般都是上有服务需要实时依赖下游服务的返回。 我们以一个登录服务为例，架构图如下： 用户发起的登录请求首先由对外的 WEB 服务接受，然后 WEB 服务服务调用用户服务查询用户信息，然后比对用户密码。 也就是说我们的 WEB 应用需要实时.... 有更新！ 我们真的需要使用 MQ 吗？MQ 使用场景分享 MQ
前言 公司有一个 Web 管理系统，使用 Tomcat 进行部署。由于是后台管理系统，所有的网页都需要登录授权之后才能进行相应的操作。 起初这个系统的用的人也不多，为了节省资源，这个系统仅仅只是单机部署。后来随着用的人越来越多，单机已经有点扛不住了，于是我决定再部署了一台机器。 这时后端系统有两台服务，于是我们使用 Nginx 作为反向代理，整体架构图如下： 这个架构图想必大家应该比较熟悉，现在主流的 Web 系统应该都是这么部署。 经过一些调试之后，在一个夜深人静的晚上，将这套系统部署到了生产。本以为没有什么事的，很稳的交给测试小姐姐开始测试。 这一测，出了大问题！测试小姐姐反馈，登录过后，没过一会又需要登录，操作好几次都是这样。 检查了一下，系统应用，配置什么也没问题，那到底哪里出了问题？ 这个时候组长刚准备下班，看到我们这里有问题，于是过来了看了一下。简单了解的一下基本情况，很快就找到了问题的原因，然后在 Nginx 端修改了下配置，重启解决了问题。 先点后赞，养成习惯~关注公号『程序通事』，快来呀！！ 分布式一致性 Session 解决完问题，组长坐下解释了问题原因：分布.... 一口气说出 4 种分布式一致性 Session 实现方式，面试杠杠的~ 分布式
每周趣图 产品经理设计体验/用户实际体验 本周就不写技术分析文章了，分享几个珍藏已久的 IDEA 的「骚技巧」，助你快速完成代码。 还等什么？赶紧上车吧...... 前进/后退 我们使用浏览器的过程，可以点击后退查看之前的浏览记录。在 IDEA 也有同样的功能，当我们编辑代码时，点击查看了调用类实现逻辑，然后可以使用后退快捷键，快速回到刚才待编辑的代码处。 有后退，当然也有前进啦~ 前进/后退快捷键如下： Windows:Ctrl + Alt + Left/Right（方向键） Mac: ⌘ + ⌥ + ← / →(方向键) 示意图如下： 查看历史记录 还是以浏览器为例，当我们已经点击很多网页，这时想查看之前看过一个网页，使用后退就会很费劲，需要一个个回退过去查找。这种情况下，直接从历史记录查看将会变得很高效。 同样的，IDEA 也提供类似的功能查看历史文件,并且在弹出窗口内可以使用关键键快速查找。 快捷键如下： Windows：ctrl + E Mac：⌘ +E 另外 IDEA 中还有可以查看最近修改代码的位置，直接点击快速跳转。 快捷键如下： Windows：ctr.... 6 个珍藏已久 IDEA 小技巧，这一波全部分享给你！ 每日一技
前言 这周收到外部合作同事推送的一篇文章，【漏洞通告】Apache Dubbo Provider默认反序列化远程代码执行漏洞（CVE-2020-1948）通告。 按照文章披露的漏洞影响范围，可以说是当前所有的 Dubbo 的版本都有这个问题。 无独有偶，这周在 Github 自己的仓库上推送几行改动，不一会就收到 Github 安全提示，警告当前项目存在安全漏洞CVE-2018-10237。 可以看到这两个漏洞都是利用反序列化进行执行恶意代码，可能很多同学跟我当初一样，看到这个一脸懵逼。好端端的反序列化，怎么就能被恶意利用，用来执行的恶意代码? 这篇文章我们就来聊聊反序列化漏洞，了解一下黑客是如何利用这个漏洞进行攻击。 反序列化漏洞 在了解反序列化漏洞之前，首先我们学习一下两个基础知识。 Java 运行外部命令 Java 中有一个类 Runtime，我们可以使用这个类执行执行一些外部命令。 下面例子中我们使用 Runtime 运行打开系统的计算器软件。 // 仅适用macos Runtime.getRuntime().exec("open -a.... Dubbo 高危漏洞！原来都是反序列化惹得祸 Dubbo
又到周末了，周更选手申请出站~ 这次分享一下上个月碰到的离奇的问题。一个简单的问题，硬是因为异常被悄咪咪吃掉，过关难度直线提升，导致小黑哥排查一个晚上。 这个美好的晚上，本想着开两把 LOL 无限火力，在召唤师峡谷来个五杀的~ 哎，就这样没了啊！我知道，你们一定能理解这种五杀被抢的感觉~ 下次，真的，谁再让我看到悄咪咪的吃掉异常，我真的要上去一 Jio 了！ 好了，本文可不是水文，看完本篇文章，你可以学到以下知识点： Arthas 排查技巧 啥是 NoClassDefFoundError Dubbo 异常内部处理方式 好了，同学们，打开小本子，准备记好知识点~ 起因 我们有个业务系统，应用之间调用链如下所示： A 应用是业务发生起始应用，在这个应用中将会根据一定规则选择最后的通讯渠道 C，然后将这个渠道标识传递给 B 应用。 B 应用的功能类似网关，这个应用将会根据 A 应用传递过来的渠道标识，将会请求路由下发到具体的 C 应用，起到服务路由的功能。 C 应用是与外部应用交互的应用，我们将其称为渠道通讯机。 假设一次业务中，A 应用根据规则选择 C2 的渠道标识，然后传递给.... 谁再悄咪咪的吃掉异常，我上去就是一 JIO Dubbo
晚上日常发布，无奈将应用发挂十几分钟，复盘一下，聊聊一下一些感悟。 晚上发布是一个渠道应用，主要作用为是去支付机构端进行银行卡扣款。 由于这个过程需要报文信息需啊哟在互联网中传输，所以需要进行相应的加签处理。 这里的银行卡等敏感信息需要采用 AES 加密，由于用于加密的私钥长度大于128位，JDK 自带的加密类将会抛出 java.security.InvalidKeyException: Illegal key size 从而导致加密失败。 加密工具类内部吃掉该异常，返回一个空字符串。然后我们上送给支付机构后，对方返回解密失败，从而导致此次交易失败。 解决办法很简单，更换如下目录的这两个 jar 包 local_policy.jar, US_export_policy.jar 。 ${java_home}/jre/lib/security 参考如下：https://blog.csdn.net/wangjunjun2008/article/details/50847426 解决办法 上面说过只要更换这两个 jar 包就可以就解决问题，但是生产环境技术人员是没有权限，只能通过邮件审批，.... 一不小心又把应用发挂了，复盘一下这十几分钟的黑暗时刻 小黑黑的碎碎念
小黑十一点半