spring cloud 学习(11) - 用fastson替换jackson及用gb2312码输出

前几天遇到一个需求,因为要兼容旧项目的编码格式,需要spring-cloud的rest接口,输出gb2312编码,本以为是一个很容易的事情,比如下面这样:

    @RequestMapping(method = RequestMethod.POST, value = "syncPaymentList",
            consumes = {"application/json; charset=gb2312"},
            produces = {"application/json; charset=gb2312"})
    public GatewayDataResult<DcbOrderListResponse> syncPaymentList(SyncPaymentListRequest request) {
        ...return ...;
    }

发现只是把输出的response里Content-Type变成了application/json;charset=gb2312,内容本身并没有变化(即:浏览器设置成简体中文,显示乱码)

有一个很简单粗暴的办法,到是可以(参考下面的),但是对原来代码改变太大:

    @RequestMapping(method = RequestMethod.GET, value = "/
时间: 2024-12-23 18:44:36

spring cloud 学习(11) - 用fastson替换jackson及用gb2312码输出的相关文章

spring cloud 学习(9) - turbine stream无法在eureka注册的解决办法

turbine是啥就不多解释了,初次接触的可以移步spring cloud 学习(4) -

spring cloud学习填坑笔记

最近在学习spring cloud,由于学习资料具有普遍性,部分应个人原因导致的小细节问题,往往很难找到解决的办法.这特别记录一下自己遇到的一些问题. 一.eureka-server加入security做基础访问控制报错Batch update failure with HTTP status code 401; discarding 1 replication tasks 详细错误如下: 场景交代: eureka-server程序加入security后,启动程序日志是OK的,在没有其他eure

spring cloud 学习(6) - zuul 微服务网关

微服务架构体系中,通常一个业务系统会有很多的微服务,比如:OrderService.ProductService.UserService...,为了让调用更简单,一般会在这些服务前端再封装一层,类似下面这样: 前面这一层俗称为"网关层",其存在意义在于,将"1对N"问题 转换成了"1对1"问题,同时在请求到达真正的微服务之前,可以做一些预处理,比如:来源合法性检测,权限校验,反爬虫之类... 传统方式下,最土的办法,网关层可以人肉封装,类似以下示

spring cloud 学习(3) - feign入门

feign 是一个让rest服务调用更简洁的开源项目,很多介绍文章或书也称它为声明式REST调用.传统的web service中,通过引用wsdl来自动生成一些client的代理类(或stub代码),feign跟这个有点类似,但是更灵活. 先回顾一下,上节中service-consumer对服务的调用代码: 1 @GetMapping("/order/{userId}/{orderNo}") 2 public String findOrder(@PathVariable Integer

spring cloud 学习(8) - sleuth &amp; zipkin 调用链跟踪

业务复杂的微服务架构中,往往服务之间的调用关系比较难梳理,一次http请求中,可能涉及到多个服务的调用(eg: service A -> service B -> service C...),如果想分析各服务间的调用关系,以及各服务的响应耗时,找出有性能瓶颈的服务,这时zipkin就派上用场,它是Twitter公司开源的一个tracing系统,官网地址为: http://zipkin.io/ , spring cloud可以跟它无疑集成. 使用步骤: 一.微服务方 1.1 添加依赖jar包 c

spring cloud 学习(1) - 基本的SOA示例

有过dubbo/dubbox使用经验的朋友,看到下面这张图,一定很熟悉,就是SOA架构的最基本套路. 与dubbo对比,上图的3大要素中,spring cloud是借助以下组件来实现的: 1.注册中心: spring cloud默认使用eureka server来做注册中心,而dubbo默认使用的是zookeeper.eureka的注册信息是保存在一个双层的Map对象中的,换句话说在内存中,不象zookeeper是长久保存在节点中. 2.服务提供方: spring-web(Spring MVC)

spring cloud 学习(5) - config server

 分布式环境下的统一配置框架,已经有不少了,比如百度的disconf,阿里的diamand.今天来看下spring cloud对应的解决方案: 如上图,从架构上就可以看出与disconf之类的有很大不同,主要区别在于: 配置的存储方式不同 disconf是把配置信息保存在mysql.zookeeper中,而spring cloud config是将配置保存在git/svn上 (即:配置当成源代码一样管理) 配置的管理方式不同 spring cloud config没有类似disconf的统一管理

spring cloud 学习(10) - 利用springfox集成swagger

对绝大多数程序员而言,写接口文档是一件痛苦的事情,相对文档,他们更愿意写代码.最理想的情况就是:代码即文档!服务开发完成后,部署上去文档就自动生成,没错,这就是springfox + swagger要解决的问题! swagger号称 THE WORLD'S MOST POPULAR API TOOLING.但swagger默认情况下,仍要单独部署,程序员还是要跑到一个单独的web页面上编辑,写一堆yaml文档,依然不爽. github上有一个springfox项目,可以在开发rest服务时,只要

spring cloud 学习(2) - eureka server注册中心高可用及安全认证

接上节继续,注册中心单点肯定是不牢靠的,可以参考下面的方案做成注册中心集群: 弄成3个节点,每个节点向其它节点注册,这样只要集群中有一个节点正常工作即可.为了方便在本机弄出这种效果,我们先修改下host文件 127.0.0.1  localhost server1 server2 server3 相当于给本机ip绑了3个hostname.然后在项目中,创建3个profile,参考下图: application.yml: spring: application: name: eureka-serv