ibatis

阿里巴巴服务化架构演进 单一应用架构 All In One 整个网站几个应用 前台 web + 后台 ops + tasks 业务 web + service/dao 各自开发 一起集成发布 技术战：Webx、Spring Ibatis、Jboss、Oracle 存在的问题：合并时经常代码冲突、发布相互制约效率低下、应用代码庞大臃肿维护困难。 垂直应用架构 按应用拆分 Service / DAO / Impl 都以二方库 jar 包的形式提供出去 代码拆分，独立部署，流程隔离，技术栈没有太大变化 应用相互之间直接依赖二方库 问题： 升级困难，要全网推动 数据库连接池压力大 分布式服务架构 API 与实现分离 使用 RPC 进行通信，服务端升级方便 各种服务中心出现，会员中心，商品中心，交易中心等 技术栈： Ali-tomcat Pandora Dubbo HSF 存在的问题： 依赖冲突 中间件升级困难 应用配置服务 应用开发效率低下 微服务架构 拥抱微服务，提升开发体验和效率 应用更轻量、开发更简单 配置 编码 开发 调试 部署 技术栈： Pandora Boot Spring Boot 容器隔离Pandora 为什么需要隔离？ Pandora的容器架构如下： Pandora 结构与部署形式： 与应用 tgz 包部署在一起 应用可单独升级 pandora.sar 应用容器识别

这是why技术的第14篇原创文章 在实际开发过程中我踩到了mybatis的一个坑，我觉得值得记录、分享一下。 先说说这个坑是什么吧。如果你踩过这个坑，并且知道具体的原因，那这篇文章可以加深你的印象。如果你没有踩过，那你可得好好看看，因为你总会遇到的。 具体如下：在mybatis中的OgnlOps.equal(0,"")返回的是true。 首先这里返回为true就违背了我们的常识，其次返回为true，会带来什么问题呢？ 看完本文你就清楚了。 本文会按照遇到问题 --> 分析问题 --> 解决问题的行文思路，用追踪源码的方法，对这个问题进行剖析。 同时分享一下我是怎么用逆向排查的方法，通过Debug模式找到最关键的那一行源码，然后明白前因后果，最后解决这个问题的。 本文源码：mybatis 3.5.3版本。 背景介绍，需求分析 先铺垫一下背景，模拟一个需求。 有一个订单表，表结构如下： 为了简化问题，我们假设表里面只有两条数据: > 订单号为1234的订单状态为0【关闭】 > > 订单号为4321的订单状态为1【开启】 已经开发好的功能是模糊查询订单名称，接口如下： 其对应的mapper.xml是这样写的，功能正常: 现在需要在已有功能上添加一个根据状态过滤订单的功能： 假设某个页面有这样的一个下拉框，可以根据订单状态过滤订单数据。 当用户选择【已支付】时，后台接收到的是数字1