阿里临时oss授权

建立写, 读角色

新建bucket -> 为bucket建立写角色, 读角色 -> 为角色建立写策略, 读策略 -> 将策略绑定到角色上

https://help.aliyun.com/document_detail/31935.html?spm=a2c4g.11186623.2.6.VpHE4b

建立扮演策略

扮演策略扮演读写角色

https://help.aliyun.com/document_detail/31935.html?spm=a2c4g.11186623.2.6.VpHE4b

为用户授权策略

授权扮演策略

使用扮演角色申请临时sts

https://help.aliyun.com/document_detail/28788.html?spm=a2c4g.11186623.6.726.9wn2kP

使用临时sts

https://help.aliyun.com/document_detail/32016.html?spm=a2c4g.11186623.6.685.nmvmH4

oss cdn 加速

先在oss绑定用户域名

再在cdn添加加速域名, 即将用户域名和oss域名绑定, 生成一个cdn加速域名

再在dns解析的地方为用户域名添加一个指向cdn加速域名的CNAME

java 错误码实践

错误码

尽量不要定义错误码， 在具体的接口/module根据业务返回值确认状态

只有全局的错误码, 才有必要定义. 而且尽量不要定义

什么时候用异常中断流程

业务上不合理， 需要中断

如果接口就是做业务check的, 那直接返回业务返回值就可以了. 这和根据业务返回值确认状态一致. 必要的返回对应的msg

如何消费消息, 消费消息是否需要存库

关于存储的表结构

首先, 所有的程序都必须保证准确性,所有的记录都是为了保证准确性

记录的类型:

业务: 用户, 订单

日志: 支付记录, 任务记录

业务是为了保证任务正常运转;

日志是为了记录系统的运行状况, 在出问题的时候排查问题. 原则上, 所有关键性的业务场景都要有日志表

应用是否应该有问题

应用不应该有问题, 应该对应用随时监控, 但应用出现问题的时候, 应该立马修复问题

关于消息消费是否需要记载日志呢

时候记载日志, 取决于业务动作时候重要, 时候容易出错. 如果两者皆有, 则肯定要记载。

所以清算肯定要记载

但是清算应该出问题吗, 不应该。 出问题了, 说明是bug，程序要立马修复, 而不是期待于业务日志的补救.

所以原则上, 应该保证应用绝对可用, 在容易出错的地方加上监控. 如果报错了, 说明是事故, 应该立马修复。 要坚持修复程序的Bug, 而不是想额外的措施去填补洞口. 这样看来, 清算日志就没有任何必要了.

因为首先, 我们肯定是可用的, 而不可用的时候, 我们能够立马感知, 修复保证可用, 可以补救吗, 可以的。 搜索出日志系统的文件日志来补救。 记载额外的清算日志只是更方便补救罢了.

但是, 如果说我们需要对任务的细节做监控, 那么我们需要日志, 这个时候日志就变成了任务细节的日志了.

总结: 原则上不用消费日志, 但是如果相对任务细节做记载, 想方便事故恢复, 是可以记载的.

数据同步时候需要记载呢?

1, 他重要吗, 重要
2, 他的消费有很复杂的业务细节吗 没有
3, 它会出错吗, 基本不会. mq的重试会保证可用

所以 严谨可用的代码 + 监控

到底什么时候要日志呢

关注消费细节, 事故恢复必须及时

比如 支付等需要, 数据同步等不需要

原则

用严谨保证可用, 用监控保证事故发现， 用细节日志用来做关键业务的日志排查

todo

看关于系统架构, 数据建模, mq消费方便的资料

spring依赖注入的坑

Resource注解默认是根据属性名,方法参数名来注入的; 其次才是根据类型去注入. name属性并不是依赖注入的依据

使用service无法注入的问题

替换成 component就可以

RankingFreshBizImpl