前言

最近在给一个项目整合Flowable流程引擎，跑起来很顺利。为了便于维护，将业务用的数据库和Flowable用的数据库分离。根据文档，很容易就能实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

@Component
public class FlowableConfig implements EngineConfigurationConfigurer<SpringAppEngineConfiguration> {

    private final DataSource dataSource;

    public FlowableConfig(@Qualifier("flowableDataSource") DataSource dataSource) {
        this.dataSource = dataSource;
    }

    @Override
    public void configure(SpringAppEngineConfiguration engineConfiguration) {
        engineConfiguration.setDataSource(dataSource);
    }

}

前言

最近在学习SpringCloud，配置CORS策略的时候遇到了问题。当接口被鉴权框架SaToken拦截的时候，浏览器里拿不到返回的响应，同时控制台报错CORS响应头未配置。但是当鉴权通过时，CORS响应头则是正常的。

原因分析

前言

最近在项目中出现了更新数据库偶尔更新丢失的情况，表现为SQL执行成功，没有任何报错，在同一事务中查询保存后的记录，没有任何问题，然而查看数据库记录却没有更新。重点是这种情况并不是稳定发生的，有时能够更新成功，又是却会更新丢失。

原因

今天在项目中配置了动态数据源，但是在引入了MybatisPlus后启动项目，却发现所有Mapper和SqlSession等等Bean没有被自动注入到容器中，猜测是自动配置失效，查看源码后发现MybatisPlusAutoConfiguration自动配置类上有注解@ConditionalOnSingleCandidate(DataSource.class)，即在容器中只有一个DataSource候选Bean是才会启用自动配置，而我手动在容器中注入了一个主数据源和一个动态数据源，导致自动配置失效。并且由于将主数据源设为了动态数据源的默认数据源，所以最好的解决方案是在动态数据源上添加@Primary注解，让容器优先选择动态数据源

前言

刷机并恢复应用数据后发现所有恢复的应用的FCM推送都失效了，原因是应用注册的FCM信息是之前系统的，与当前系统不兼容，解决方案就是重新注册FCM

具体操作

Golang的Echo框架中，上下文echo.Context是一个接口，可以通过它重写默认的Context.JSON方法来自定义返回格式

首先定义一下接口的格式

1
2
3
4

type CommonResponse struct {
    Message string      `json:"message"`
    Data    interface{} `json:"data,omitempty"`
}

对于前后端分离的项目，采用统一的返回格式可以有效减少前后端开发人员的交流成本，对于Spring MVC可以利用切面无侵入地、优雅地实现这一点。

Spring MVC提供了AbstractMappingJacksonResponseBodyAdvice抽象类对返回的JSON做二次处理

首先定义返回结构

关于JWT是什么就不赘述了，可以看看阮一峰大佬的文章：https://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html

定义JWT Body

首先需要定义一个Bean用来存放JWT Body，字段可以根据具体业务决定。这一步当然可以跳过，你可以用Map传值，只不过可维护性会差点

前言

通常我们用Cloudflare WARP通过替换VPS的双栈或单栈网络来通过获得所谓“原生IP”，从而解锁Netflex等流媒体，而如果直接替换掉双栈网络会导致VPS失联，即使通过修改路由表正常使用也会影响到Docker等应用的NAT。实际上我们只需要让Xray的流量走WARP接口出去就行了，outbounds配置提供了sendThrough用来指定出口IP，streamSettings.sockopt.mark用来设置fwmark。我之前直接指定为WARP的IP发现并不行，收不到回包(实际上如果直接指定接口名就正常使用了，可惜不支持)。在翻Xray的文档时才发现还需要配置一下路由表才行。

使用sendThrough

通常我们会通过spring的异常处理器来自定义响应格式,即通过@RestControllerAdvice来实现，但是如果只是为了自定义一个返回格式的话有更好的选择，那就是自定义ErrorController，所有未被处理的异常都会被它处理，@RestControllerAdvice也被视为异常处理，即被@RestControllerAdvice处理的异常将不会到达这里，直接上代码，以Kotlin为例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

@RestController
@RequestMapping("/error")
class GlobalErrorController : ErrorController {

    @Autowired
    lateinit var errorAttributes: ErrorAttributes

    @RequestMapping
    fun error(request: HttpServletRequest): ResponseEntity<ErrorResponse> {
        val ex: Throwable? = errorAttributes.getError(ServletWebRequest(request))
        val status = getStatus(request)
        return ResponseEntity.status(status)
            .body(ErrorResponse(status = status.name, message = ex?.localizedMessage ?: ""))
    }

    private fun getStatus(request: HttpServletRequest): HttpStatus {
        val statusCode = request.getAttribute(RequestDispatcher.ERROR_STATUS_CODE)

        if (statusCode !is Int) {
            return HttpStatus.INTERNAL_SERVER_ERROR
        }

        return try {
            HttpStatus.valueOf(statusCode)
        } catch (e: Exception) {
            HttpStatus.INTERNAL_SERVER_ERROR
        }
    }
}

• 这里注入了一个ErrorAttributes类型的bean，它包含了请求上下文的错误信息，通过getError方法可以获取到异常类

• 匹配到路由/error的方法的返回值会作为响应发送到客户端，当然这个路由是可以自定义的