文档章节

Apache ShardingSphere数据脱敏全解决方案详解

tristaZero
 tristaZero
发布于 08/12 11:26
字数 5418
阅读 3188
收藏 115

Apache ShardingSphere数据脱敏全解决方案详解

作者简介

潘娟,京东数科高级DBA,主要负责京东数科数据库中间件开发、数据库运维自动化平台开发、生产数据库运维工作。多次参与京东6.18、11.11等大促活动的护航工作。曾负责京东数科数据库自动化平台设计与开发项目,现专注于Apache ShardingSphere分布式数据库中间件开发。乐于在数据库、自动化、分布式、中间件等相关领域进行学习和探索。

一、背景

安全控制一直是治理的重要环节,数据脱敏属于安全控制的范畴。对互联网公司、传统行业来说,数据安全一直是极为重视和敏感的话题。数据脱敏是指对某些敏感信息通过脱敏规则进行数据的变形,实现敏感隐私数据的可靠保护。涉及客户安全数据或者一些商业性敏感数据,如身份证号、手机号、卡号、客户号等个人信息按照相关部门规定,都需要进行数据脱敏。

在真实业务场景中,相关业务开发团队则往往需要针对公司安全部门需求,自行实行并维护一套加解密系统,而当脱敏场景发生改变时,自行维护的脱敏系统往往又面临着重构或修改风险。此外,对于已经上线的业务,如何在不修改业务逻辑、业务SQL的情况下,透明化、安全低风险地实现无缝进行脱敏改造呢?

Apache ShardingSphere根据业界对脱敏的需求及业务改造痛点,提供了一套完整、安全、透明化、低改造成本的数据脱敏整合解决方案。

二、前序

Apache ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈,它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar(规划中)这3款相互独立,却又能够混合部署配合使用的产品组成。它们均能够提供标准化的数据分片、分布式事务和分布式治理功能,可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。

数据脱敏模块属于ShardingSphere分布式治理这一核心功能下的子功能模块。它通过对用户输入的SQL进行解析,并依据用户提供的脱敏配置对SQL进行改写,从而实现对原文数据进行加密,并将原文数据(可选)及密文数据同时存储到底层数据库。在用户查询数据时,它又从数据库中取出密文数据,并对其解密,最终将解密后的原始数据返回给用户。Apache ShardingSphere分布式数据库中间件自动化&透明化了数据脱敏过程,让用户无需关注数据脱敏的实现细节,像使用普通数据那样使用脱敏数据。此外,无论是已在线业务进行脱敏改造,还是新上线业务使用脱敏功能,ShardingSphere都可以提供一套相对完善的解决方案。

三、需求场景分析

对于数据脱敏的需求,在现实的业务场景中一般分为两种情况:

  1. 新业务上线,安全部门规定需将涉及用户敏感信息,例如银行、手机号码等进行加密后存储到数据库,在使用的时候再进行解密处理。因为是全新系统,因而没有存量数据清洗问题,所以实现相对简单。

  2. 已上线业务,之前一直将明文存储在数据库中。相关部门突然需要对已上线业务进行脱敏整改。这种场景一般需要处理三个问题:

    a) 历史数据需要如何进行脱敏处理,即洗数。

    b) 如何能在不改动业务SQL和逻辑情况下,将新增数据进行脱敏处理,并存储到数据库;在使用时,再进行解密取出。

    c) 如何较为安全、无缝、透明化地实现业务系统在明文与密文数据间的迁移。

四、处理流程详解

整体架构

ShardingSphere提供的Encrypt-JDBC和业务代码部署在一起。业务方需面向Encrypt-JDBC进行JDBC编程。由于Encrypt-JDBC实现所有JDBC标准接口,业务代码无需做额外改造即可兼容使用。此时,业务代码所有与数据库的交互行为交由Encrypt-JDBC负责。业务只需提供脱敏规则即可。作为业务代码与底层数据库中间的桥梁,Encrypt-JDBC便可拦截用户行为,并在改造行为后与数据库交互。

1

Encrypt-JDBC将用户发起的SQL进行拦截,并通过SQL语法解析器进行解析、理解SQL行为,再依据用户传入的脱敏规则,找出需要脱敏的字段和所使用的加解密器对目标字段进行加解密处理后,再与底层数据库进行交互。

ShardingSphere会将用户请求的明文进行加密后存储到底层数据库;并在用户查询时,将密文从数据库中取出进行解密后返回给终端用户。

ShardingSphere通过屏蔽对数据的脱敏处理,使用户无需感知解析SQL、数据加密、数据解密的处理过程,就像在使用普通数据一样使用脱敏数据。

脱敏规则

在详解整套流程之前,我们需要先了解下脱敏规则与配置,这是认识整套流程的基础。脱敏配置主要分为四部分:数据源配置,加密器配置,脱敏表配置以及查询属性配置,其详情如下图所示:

2

数据源配置:是指DataSource的配置。

加密器配置:是指使用什么加密策略进行加解密。目前ShardingSphere内置了两种加解密策略:AES/MD5。用户还可以通过实现ShardingSphere提供的接口,自行实现一套加解密算法。

脱敏表配置:用于告诉ShardingSphere数据表里哪个列用于存储密文数据(cipherColumn)、哪个列用于存储明文数据(plainColumn)以及用户想使用哪个列进行SQL编写(logicColumn)。

如何理解用户想使用哪个列进行SQL编写(logicColumn)

我们可以从Encrypt-JDBC存在的意义来理解。Encrypt-JDBC最终目的是希望屏蔽底层对数据的脱敏处理,也就是说我们不希望用户知道数据是如何被加解密的、如何将明文数据存储到plainColumn,将密文数据存储到cipherColumn。换句话说,我们不希望用户知道plainColumn和cipherColumn的存在和使用。所以,我们需要给用户提供一个概念意义上的列,这个列可以脱离底层数据库的真实列,它可以是数据库表里的一个真实列,也可以不是,从而使得用户可以随意改变底层数据库的plainColumn和cipherColumn的列名。或者删除plainColumn,选择永远不再存储明文,只存储密文。只要用户的SQL面向这个逻辑列进行编写,并在脱敏规则里给出logicColumn和plainColumn、cipherColumn之间正确的映射关系即可。

为什么要这么做呢?答案在文章后面,即为了让已上线的业务能无缝、透明、安全地进行数据脱敏迁移。

查询属性的配置:当底层数据库表里同时存储了明文数据、密文数据后,该属性开关用于决定是直接查询数据库表里的明文数据进行返回,还是查询密文数据通过Encrypt-JDBC解密后返回。

脱敏处理过程

举个栗子,假如数据库里有一张表叫做t_user,这张表里实际有两个字段pwd_plain,用于存放明文数据、pwd_cipher,用于存放密文数据,同时定义logicColumn为pwd。那么,用户在编写SQL时应该面向logicColumn进行编写,即INSERT INTO t_user SET pwd = '123'。ShardingSphere接收到该SQL,通过用户提供的脱敏配置,发现pwd是logicColumn,于是便对逻辑列及其对应的明文数据进行脱敏处理。可以看出ShardingSphere将面向用户的逻辑列与面向底层数据库的明文列和密文列进行了列名以及数据的脱敏映射转换。如下图所示:

3

这也正是Encrypt-JDBC核心意义所在,即依据用户提供的脱敏规则,将用户SQL与底层数据表结构割裂开来,使得用户的SQL编写不再依赖于真实的数据库表结构。而用户与底层数据库之间的衔接、映射、转换交由ShardingSphere进行处理。为什么我们要这么做?还是那句话:为了让已上线的业务能无缝、透明、安全地进行数据脱敏迁移。

为了让读者更清晰了解到Encrypt-JDBC的核心处理流程,下方图片展示了使用Encrypt-JDBC进行增删改查时,其中的处理流程和转换逻辑,如下图所示。

4

五、解决方案详解

在了解了ShardingSphere脱敏处理流程后,即可将脱敏配置、脱敏处理流程与实际场景进行结合。所有的设计开发都是为了解决业务场景遇到的痛点。那么面对之前提到的业务场景需求,又应该如何使用ShardingSphere这把利器来满足业务需求呢?

新上线业务

业务场景分析:新上线业务由于一切从零开始,不存在历史数据清洗问题,所以相对简单。

解决方案说明:选择合适的加密器,如AES后,只需配置逻辑列(面向用户编写SQL)和密文列(数据表存密文数据)即可,逻辑列和密文列可以相同也可以不同。建议配置如下(Yaml格式展示):

encryptRule:
  encryptors:
    aes_encryptor:
      type: aes
      props:
        aes.key.value: 123456abc
  tables:
    t_user:
      columns:
        pwd:
          cipherColumn: pwd
          encryptor: aes_encryptor

使用这套配置,Encrypt-JDBC只需将logicColumn和cipherColumn进行转换,底层数据表不存储明文,只存储了密文,这也是安全审计部分的要求所在。如果用户希望将明文、密文一同存储到数据库,只需添加plainColumn配置即可。整体处理流程如下图所示:

5

已上线业务改造

业务场景分析:由于业务已经在线上运行,数据库里必然存有大量明文历史数据。现在的问题是如何让历史数据得以加密清洗、如何让增量数据得以加密处理、如何让业务在新旧两套数据系统之间进行无缝、透明化迁移。

解决方案说明:在提供解决方案之前,我们先来头脑风暴一下:首先,既然是旧业务需要进行脱敏改造,那一定存储了非常重要且敏感的信息。这些信息含金量高且业务相对基础重要。如果搞错了,整个团队KPI就再见了。所以不可能一上来就停业务,禁止新数据写入,再找个加密器把历史数据全部加密清洗,再把之前重构的代码部署上线,使其能把存量和增量数据进行在线加密解密。如此简单粗暴的方式,按照历史经验来谈,一定凉凉。

那么另一种相对安全的做法是:重新搭建一套和生产环境一模一样的预发环境,然后通过相关迁移洗数工具把生产环境的存量原文数据加密后存储到预发环境,而新增数据则通过例如MySQL主从复制及业务方自行开发的工具加密后存储到预发环境的数据库里,再把重构后可以进行加解密的代码部署到预发环境。这样生产环境是一套以明文为核心的查询修改的环境;预发环境是一套以密文为核心加解密查询修改的环境。在对比一段时间无误后,可以夜间操作将生产流量切到预发环境中。此方案相对安全可靠,只是时间、人力、资金、成本较高,主要包括:预发环境搭建、生产代码整改、相关辅助工具开发等。除非无路可走,否则业务开发人员一般是从入门到放弃。

业务开发人员最希望的做法是:减少资金费用的承担、最好不要修改业务代码、能够安全平滑迁移系统。于是,ShardingSphere的脱敏功能模块便应用而生。可分为三步进行:

  1. 系统迁移前

    假设系统需要对t_user的pwd字段进行脱敏处理,业务方使用Encrypt-JDBC来代替标准化的JDBC接口,此举基本不需要额外改造(我们还提供了SpringBoot,SpringNameSpace,Yaml等接入方式,满足不同业务方需求)。另外,提供一套脱敏配置规则,如下所示:

    encryptRule:
      encryptors:
        aes_encryptor:
          type: aes
          props:
            aes.key.value: 123456abc
      tables:
        t_user:
          columns:
            pwd:
              plainColumn: pwd
              cipherColumn: pwd_cipher
              encryptor: aes_encryptor
    props:
        query.with.cipher.column: false
    

    依据上述脱敏规则可知,首先需要在数据库表t_user里新增一个字段叫做pwd_cipher,即cipherColumn,用于存放密文数据,同时我们把plainColumn设置为pwd,用于存放明文数据,而把logicColumn也设置为pwd。由于之前的代码SQL就是使用pwd进行编写,即面向逻辑列进行SQL编写,所以业务代码无需改动。通过Encrypt-JDBC,针对新增的数据,会把明文写到pwd列,并同时把明文进行加密存储到pwd_cipher列。此时,由于query.with.cipher.column设置为false,对业务应用来说,依旧使用pwd这一明文列进行查询存储,却在底层数据库表pwd_cipher上额外存储了新增数据的密文数据,其处理流程如下图所示:

    6

    新增数据在插入时,就通过Encrypt-JDBC加密为密文数据,并被存储到了cipherColumn。而现在就需要处理历史明文存量数据。由于Apache ShardingSphere目前并未提供相关迁移洗数工具,此时需要业务方自行将pwd中的明文数据进行加密处理存储到pwd_cipher。

  2. 系统迁移中

    新增的数据已被Encrypt-JDBC将密文存储到密文列,明文存储到明文列;历史数据被业务方自行加密清洗后,将密文也存储到密文列。也就是说现在的数据库里即存放着明文也存放着密文,只是由于配置项中的query.with.cipher.column=false,所以密文一直没有被使用过。现在我们为了让系统能切到密文数据进行查询,需要将脱敏配置中的query.with.cipher.column设置为true。在重启系统后,我们发现系统业务一切正常,但是Encrypt-JDBC已经开始从数据库里取出密文列的数据,解密后返回给用户;而对于用户的增删改需求,则依旧会把原文数据存储到明文列,加密后密文数据存储到密文列。

    虽然现在业务系统通过将密文列的数据取出,解密后返回;但是,在存储的时候仍旧会存一份原文数据到明文列,这是为什么呢?答案是:为了能够进行系统回滚。因为只要密文和明文永远同时存在,我们就可以通过开关项配置自由将业务查询切换到cipherColumn或plainColumn。也就是说,如果将系统切到密文列进行查询时,发现系统报错,需要回滚。那么只需将query.with.cipher.column=false,Encrypt-JDBC将会还原,即又重新开始使用plainColumn进行查询。处理流程如下图所示:

    7

  3. 系统迁移后

    由于安全审计部门要求,业务系统一般不可能让数据库的明文列和密文列永久同步保留,我们需要在系统稳定后将明文列数据删除。即我们需要在系统迁移后将plainColumn,即pwd进行删除。那问题来了,现在业务代码都是面向pwd进行编写SQL的,把底层数据表中的存放明文的pwd删除了,换用pwd_cipher进行解密得到原文数据,那岂不是意味着业务方需要整改所有SQL,从而不使用即将要被删除的pwd列?还记得我们Encrypt-JDBC的核心意义所在吗?

    这也正是Encrypt-JDBC核心意义所在,即依据用户提供的脱敏规则,将用户SQL与底层数据库表结构割裂开来,使得用户的SQL编写不再依赖于真实的数据库表结构。而用户与底层数据库之间的衔接、映射、转换交由ShardingSphere进行处理。

    是的,因为有logicColumn存在,用户的编写SQL都面向这个虚拟列,Encrypt-JDBC就可以把这个逻辑列和底层数据表中的密文列进行映射转换。于是迁移后的脱敏配置即为:

    encryptRule:
      encryptors:
        aes_encryptor:
          type: aes
          props:
            aes.key.value: 123456abc
      tables:
        t_user:
          columns:
            pwd: # pwd与pwd_cipher的转换映射
              cipherColumn: pwd_cipher
              encryptor: aes_encryptor
     props:
        query.with.cipher.column: true
    

    其处理流程如下:

    8

至此,已在线业务脱敏整改解决方案全部叙述完毕。我们提供了Java、Yaml、SpringBoot、SpringNameSpace多种方式供用户选择接入,力求满足业务不同的接入需求。该解决方案目前已在京东数科不断落地上线,提供对内基础服务支撑。

六、中间件脱敏服务优势

  1. 自动化&透明化数据脱敏过程,用户无需关注脱敏中间实现细节。
  2. 提供多种内置、第三方(AKS)的脱敏策略,用户仅需简单配置即可使用。
  3. 提供脱敏策略API接口,用户可实现接口,从而使用自定义脱敏策略进行数据脱敏。
  4. 支持切换不同的脱敏策略。
  5. 针对已上线业务,可实现明文数据与密文数据同步存储,并通过配置决定使用明文列还是密文列进行查询。可实现在不改变业务查询SQL前提下,已上线系统对加密前后数据进行安全、透明化迁移。

七、适用场景说明

  1. 用户项目使用Java语言进行编程。
  2. 后端数据库为MySQL、Oracle、PostgreSQL、SQLServer。
  3. 用户需要对数据库表中某个或多个列进行脱敏(数据加密&解密)。
  4. 兼容所有常用SQL;

八、限制条件

  1. 用户需要自行处理数据库中原始的存量数据、洗数。
  2. 使用脱敏功能+分库分表功能,部分特殊SQL不支持,请参考SQL使用规范
  3. 脱敏字段无法支持比较操作,如:大于小于、ORDER BY、BETWEEN、LIKE等
  4. 脱敏字段无法支持计算操作,如:AVG、SUM以及计算表达式

九、后续

本篇文章介绍了如何使用ShardingSphere产品之一的Encrypt-JDBC进行接入,接入形式还可以选择使用SpringBoot、SpringNameSpace等,这种形态的接入端主要面向JAVA同构,并与业务代码共同部署在生产环境中。面向异构语言,ShardingSphere还提供Encrypt-Proxy客户端。Encrypt-Proxy是一款实现MySQL、PostgreSQL的二进制协议的服务器端产品,用户可独立部署Encrypt-Proxy服务,并且像使用普通MySQL、PostgreSQL数据库一样,使用例如Navicat第三方数据库管理工具、JAVA连接池、命令行的方式访问这台具有脱敏功能的虚拟数据库服务器

脱敏功能属于Apache ShardingSphere分布式治理的功能范畴。事实上,Apache ShardingSphere这个生态还拥有其他更强大的能力,例如数据分片、读写分离、分布式事务、监控治理等。您甚至可以选择任意多种功能模块进行叠加使用,例如同时使用数据脱敏+数据分片,或是数据分片+读写分离,再或者是监控治理+数据分片等。除了在功能层面的叠加选择,ShardingSphere还提供了各种接入端形式,例如Sharding-JDBC或Sharding-Proxy等以满足大家不同场景需求

十、写在最后

ShardingSphere从最初的仅支持分库分表功能,到现在已形成包括数据分片、分布式治理、分布式事务等核心功能为主的生态圈。这也标识着它不仅仅是一款分布式数据库中间件,不仅仅拥有分库分表的能力,更是形成以数据分片、分布式治理、分布式事务为核心的全方位解决方案生态体系,欢迎大家在官网了解更多内容,在gitHub关注我们☺!

© 著作权归作者所有

tristaZero
粉丝 15
博文 1
码字总数 5418
作品 0
东城
私信 提问
加载中

评论(21)

跟帖队副队长
跟帖队副队长
你好,4.0.0-RC2-SNAPSHOT什么发布,时间确定了吗?谢谢
tristaZero
tristaZero 博主
可以关注我们apache邮件,已经在apache发起发版投票了,就这1,2周了
跟帖队副队长
跟帖队副队长
好的,坐等发布
哈库纳
哈库纳
这个东西在数据输出到前端时候,仅仅把敏感列转换成 *** 用用还可以的,能形成框架也是一件不错的事。


真正做到脱敏这种方式还是挡不住的。
这里转一篇几种常用的方法,分分钟绕过打星号这种方式。https://blog.csdn.net/xff1994/article/details/83149116

业界虽然有 n 多篇论文专门介绍如何记性安全的脱敏,但是也都只能局限到先定业务场景。 哪怕是 google 和 apple 这样把用户数据安全放到第一位的公司。
最是不醉
最是不醉
请问下,像手机号这种,既要加密又要做查询的,怎么处理😛
官方公众号
我觉得看可能得限制查询条件,只能输入完整号码查询,不能模糊查了。 或者加密时保留尾号4位供查询
tristaZero
tristaZero 博主
对用户来说直接在查询条件写你明文手机号码即可,即select * from tb where phone='13909878903'。楼上说的对,不支持模糊查询了,因为加密后的数据和真实数据已经不一样了,无法进行比较查询了,或者准备说,SQL能正常执行,但数据无法正确匹配
凪殇
凪殇
1、ShardingSphere产品之一的Encrypt-JDBC 官网并未提到Encrypt-JDBC ,和Sharding-JDBC是同一个东西吗?
2、关于配置,官网和源码并没找到文章中的配置啊,Sharding-JDBC配置的是qualified-columns,如何配置明文和密文呢?
凪殇
凪殇
该文章适用4.0.0-RC2-SNAPSHOT版本。
tristaZero
tristaZero 博主
对的,请期待我们最近即将发布的4.0.0-RC2-SNAPSHOT版本。官档届时一同发布😉
凪殇
凪殇
感谢,如何实现统一字段,映射一个AES和MD5这种2个加密字段呢?
爪哇小贩
爪哇小贩
美女支持jpa吗
tristaZero
tristaZero 博主
肯定了
青菜番茄h
青菜番茄h
怎么用的 有什么效果 可以深入讲一下啊
tristaZero
tristaZero 博主
https://shardingsphere.apache.org/ 官方文档,多种配置使用方式
伊人枫
伊人枫
👍
伊人枫
伊人枫
你好,有个问题想请教一下,insert into t_user('pwd') values('123'),被解析成insert into t_user('pwd_plain', 'pwd_cpher') values ('123', 'xxx')执行,这么来看,必须有两个字段,一个用于存储明文,一个用于存储密文,这么做的意义是什么?我相信安全部门的要求是针对这些信息在数据库存储密文,并非明文和密文各存一份。
叶秋
叶秋
原文:“从而实现对原文数据进行加密,并将原文数据(可选👈)及密文数据同时存储到底层数据库。”
tristaZero
tristaZero 博主
👍~
tristaZero
tristaZero 博主
主要为了旧业务改造,因为旧业务之前都存的是明文。所以一段时间让明文和密文共存,如果密文加密有问题,还有明文列,故不会影响业务正常运行。如果密文验证都没问题,就把原文列删除了。要有后路可退😃,当然新业务,如其他朋友回复的,可选的。可以一上线就不存明文。
老谭12345
看到最后啊。。。最后那不删了嘛
Apache 官宣!Sharding-Sphere 首个 Apache 版本发布

竹外桃花三两枝,春江水暖鸭先知。四月春回大地之时,Apache ShardingSphere 4.0.0-RC1终于在今天与大家见面了! 距离ShardingSphere 3.x的时代已有半年之久。在这半年的时间里,ShardingSph...

局长
04/22
6.8K
20
分布式数据库中间件Apache ShardingSphere京东落地实战

本文根据dbaplus社群第183期线上分享整理而成。 面对互联网大数据如火如荼发展、云服务需求的急剧增加,对企业极其重要的数据要如何面对这些新的变革? 作为Apache基金会的分布式数据库中间件...

潘娟
04/01
0
0
ShardingSphere x Seata,一致性更强的分布式数据库中间件

日前,分布式数据库中间件 ShardingSphere 将 Seata 分布式事务能力进行整合,旨在打造一致性更强的分布式数据库中间件。 背景 数据库领域,分布式事务的实现主要包含:两阶段的 XA 和 BASE...

SOFAStack
07/04
166
0
ShardingSphere即将支持PostgreSQL代理

作者简介 张永伦,京东数科高级软件工程师,Apache ShardingSphere(Incubating) PPMC。长期从事分布式系统的高可用、高并发相关工作。热衷于网络IO、性能优化方面的技术挑战。目前专注于Sha...

PostgreSQL中文社区
04/16
0
0
案例丨互联网金融企业数据安全建设启示

当今互联网已经延伸出一系列新兴的金融服务模式,云计算、大数据、人工智能等新技术的应用在深刻改变金融服务的同时,也会带来系统风险等安全问题。数据安全逐渐成为互联网金融行业的重要议题...

安华金和
2018/08/20
0
0

没有更多内容

加载失败,请刷新页面

加载更多

OSChina 周日乱弹 —— 我,小小编辑,食人族酋长

Osc乱弹歌单(2019)请戳(这里) 【今日歌曲】 @宇辰OSC :分享娃娃的单曲《飘洋过海来看你》: #今日歌曲推荐# 《飘洋过海来看你》- 娃娃 手机党少年们想听歌,请使劲儿戳(这里) @宇辰OSC...

小小编辑
今天
623
10
MongoDB系列-- SpringBoot 中对 MongoDB 的 基本操作

SpringBoot 中对 MongoDB 的 基本操作 Database 库的创建 首先 在MongoDB 操作客户端 Robo 3T 中 创建数据库: 增加用户User: 创建 Collections 集合(类似mysql 中的 表): 后面我们大部分都...

TcWong
今天
32
0
spring cloud

一、从面试题入手 1.1、什么事微服务 1.2、微服务之间如何独立通讯的 1.3、springCloud和Dubbo有哪些区别 1.通信机制:DUbbo基于RPC远程过程调用;微服务cloud基于http restFUL API 1.4、spr...

榴莲黑芝麻糊
今天
19
0
Executor线程池原理与源码解读

线程池为线程生命周期的开销和资源不足问题提供了解决方 案。通过对多个任务重用线程,线程创建的开销被分摊到了多个任务上。 线程实现方式 Thread、Runnable、Callable //实现Runnable接口的...

小强的进阶之路
昨天
56
0
maven 环境隔离

解决问题 即 在 resource 文件夹下面 ,新增对应的资源配置文件夹,对应 开发,测试,生产的不同的配置内容 <resources> <resource> <directory>src/main/resources.${deplo......

之渊
昨天
60
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部