主页

前言 Dubbo3.0推出了一个新的协议Triple，我们今天简单看看它的用法。 Triple总览 官方说明：看这里 ，总结为以下几点： 打通 gRPC 生态。 网关友好。（dubbo协议 只能 HTTP 转 泛化Dubbo 调用后端服务，现在可以接入Ingress方案） 异步和流式支持。（dubbo协议 多用于响应式的场景，不适合传大规模的数据。3.0增加流式场景，支持大规模数据的传输） 快速搭建 环境准备 操作系统：Windowns JDK版本：1.8 编辑工具：IntelliJ IDEA Community Edition 2021.1.2 x64 Zookeeper：3.5.6（3.4或3.5以上的版本都行） 创建项目 项目有三个模...

前言 上个月，同事出于好奇在群里问AOP的环绕通知与事务注解混合用会不会导致出现异常不回滚的情况。这个问题我一下子回答不上来，因为平时没这样用过，在好奇心的驱使下，我调试了半天终于得到结果，今天我就展开讲讲。（源码解读在最后面，感兴趣的可以看看。） 结论 首先告诉大家的是，同时使用AOP环绕通知和事务注解之后，最终生成的拦截器链的相对顺序是事务的拦截器在前面，AOP环绕通知的拦截器在后面。 在事务的实现中将拦截器的执行过程包裹在了try-catch块中，发生异常后根据配置来决定是否回滚事务。（详见org.springframework.transaction.interceptor.TransactionInterceptor#invoke），因此事务后面的拦截器都会影响事务的执行结...

前言 gRPC的大致功能点相信大家一定已经有些了解。但是，在日常开发中我们很少会使用原生的gRPC，更多的是希望gRPC能集成到现有应用的开发环境中。这篇文章会围绕如何以简单的方式将gRPC集成到SpringBoot展开讲解。 快速搭建 环境准备 操作系统：Windowns JDK版本：1.8 编辑工具：IntelliJ IDEA Community Edition 2021.1.2 x64 框架选型 目前开源切比较热门的grpc和SpringBoot整合框架有两种可选方案。分别是LogNet 和 yidongnan 。（这两者稍微有些区别，在最后我会有个对比） 这里我使用后者作为demo演示。 创建项目 自己创建一个maven项目就好，没有别的要求（A...

前言 gRPC作为当前最热门的RPC框架之一，以其独特的跨语言、跨平台特性，赢得许多公司的青睐。 老实说，之前我只是道听途说并没有认真去研究，今天我会根据官网的demo展开介绍整个gRPC的功能， 后面一篇会介绍gRPC如何整合到SpringCloud。 我这里只提供了搭建demo工程的资料，建议自己动手来操作。没有截图项目也是因为官方的资料相当齐全，没必要重复造轮子。 gRPC总览 在直接使用gRPC之前，我们先了解下它的所有特性。官方描述 我就不展开讲了，gRPC有以下几点主要功能： 使用Protocol Buffer 定义服务。 语言和平台的中立性 双向流式通讯 基于HTTP2.0身份认证、SLB、tracing、health check 组件可扩...

前言 去年我加入阿里的一个创业项目。最开始，大家都信心满满，当时大家挂在嘴边的口号是“我要把这个业务做上市”。在经历第一次大促、疫情好转、换帅、集团战略调整等事件之后，最近这个项目发生大的人员调整，项目上所有集团内部技术岗位人员（P6~P8）都被裁了一个不剩。我以一个开发的视角来复盘整个过程，顺便也讲讲我的看法。 创业背景 2019年年关发生的疫情导致国外供应链体系遭受重创，中国在体制优势下疫情防控工作做的很好，最先恢复过来。彼时国外疫情的扩散势态仍然没有得到有效的抑制，大量工厂无法复工复产。同时，为了防止疫情扩散，很多出口国也关闭了商品的出口通道，进一步加剧了短缺现象。 （比如：2020年初的国内猪价大涨，正是因为猪肉无法进口而短期内又受到猪的生长周期的限制，导致猪肉大涨） 在疫情肆...

上市公司为什么需要创新 当一家公司主营业务增长速度放缓之后，为了保持营收的增长，有效的办法便是寻找其他能带来增长的业务。 （当然如果是商业模式本身出现问题也可能会进行私有化以便于调整，可以参考戴尔的私有化案例） “创新”是一种寻找能带来增长的业务的高效方式，大体上是围绕技术、产品组织形式、生产方式等方面展开。 上市公司创新的掣肘点 对上市公司来说，创新的掣肘点主要体现在资金的投入在短期内没法得到回报。创新是一件长周期、要烧很多钱、有很大概率失败的一件事。 而上市公司对短期的投资回报是比较敏感的，因为投资回报影响着季度财务报表，股民们会时刻关注每个季度的报表，营收出现下跌会打击股民的信心，容易造成公司股价下跌。 所以上市公司会受到股市的约束，使公司更倾向于追求短期有回报的投资。 创新的形...

前言 上个月开始和同事一起做一个为期一个月的项目。期间同事看了我的代码，给我投来了一个奇异的眼神，问道“你的代码没有错误码吗？我调你的方法，我怎么知道成功与否呢？”，今天我就这个话题来讨论一下为什么系统内部调用时不需要封装请求结果，出错直接抛出异常就好。 核心争论点 系统的内部调用是否需要封装错误码以及请求返回结果。换句话说，我同事认为一个成功的系统调用需要像下面这样返回数据对象（这里只是以json作为示例，并不代表我们调用的结果是json）。 { "code": 200, "success": true, "msg": "", "data": {} } 而一个失败的系统调用是否又需要像下面这样返回。 { "code": 500, "success": fal...

场景 在日常开发中各个系统之间的交互，除了系统调用之外消息也是一个比较常见的机制。比如：商品发布、商品上架、商品下架等，这种场景下为了与其他系统解耦所以选择使用消息中间件来进行消息的发布与订阅机制。除了这种场景之外，我们经常遇到另一个场景，比如有A和B两个系统，A系统负责商品的生命周期管理，比如发布、审核、上架、下架。B系统负责对商品的价格进行计算与价格审核相关的功能。我们知道商品在上架前肯定得有价格，而价格肯定是需要商家先提报然后需要审核之后B系统再对商家提报的价格进行一定的溢价计算才能生成最终在平台上的销售价格。那么商品提报之后不能说要等商家把价格信息完善好之后再继续往下进行商品运营工作，所以商品提报之后流程继续走，等到商家提报价格以及B系统生成价格之后，通过消息监听的机制来感知价...