• 关于

    读写系统出问题什么情况

    的搜索结果

回答

拿下代码,放入eclipse,{@fix:由于个人jdk配置,仅在jre1.6下运行},什么输出都没有。下面来说说原因:1、对于非volatile修饰的变量,尽管jvm的优化,会导致变量的可见性问题,但这种可见性的问题也只是在短时间内高并发的情况下发生,CPU执行时会很快刷新Cache,一般的情况下很难出现,而且出现这种问题是不可预测的,与jvm, 机器配置环境等都有关。所以在未修改flag1之前,i会一直自增。一旦flag1修改后,sleep了1s,在flag2为修改之前,while循环就退出了,所以基本不会看到输出。2、说说volatile的语义。volatile能保证可见性。其保证每次对volatile变量的读取会重新从主存中获取,以使得最新修改的值对其可见。(其大概的实现方式:每次写volatile变量时,会锁定系统总线,这样会导致其他CPU的Cache失效,这样下次读取时,CPU检测到Cache失效,会重新从主存中加载)。在jdk1.5之前,volatile只能保证可见性,但会re-order的问题,这也是著名的double-check-lock的问题(对此,可google出一大堆的文章)。在jdk1.5中,对volatile语义进行了增强,其保证jvm内存模型不会对volatile修饰的变量进行重排序(写volatile变量操作不会与其之前的读写操作重排,读volatile操作不会与其后的读写操作重排)[1], 之后double-check-lock才算实际的可用。3、volatile提供的可见性和禁止指令重排的语义可以满足一定程度的同步性需求。对于volatile变量的使用,文献[2]中给出最佳实践:1.写入变量时并不依赖变量的当前值,或者可以确保只有单一线程修改该变量值;2.变量不需要和其他成员变量一起参与类的状态不变性约束;3.访问变量时,没有其他额外的原因需要加锁。
蛮大人123 2019-12-02 01:58:18 0 浏览量 回答数 0

问题

quickdb 另辟捷径高效解决NOSQL数据库 数据持久性问题:报错

目前的NOSQL主要分为两种,一种是基于内存型的如redis、memcached,一种是基于磁盘型的如Tokyo Tyrant、Tokyo Cabinet、Berkeley DB。 redis、memcache...
kun坤 2020-06-07 16:39:10 0 浏览量 回答数 1

问题

如何设计一个高并发系统?【Java问答学堂】45期

面试题 如何设计一个高并发系统? 面试官心理分析 说实话,如果面试官问你这个题目,那么你必须要使出全身吃奶劲了。为啥?因为你没看到现在很多公司招聘的 JD 里都是说啥࿰...
剑曼红尘 2020-06-28 20:53:14 10 浏览量 回答数 1

问题

运维人员处理云服务器故障方法七七云转载

我们团队为Ucloud云计算服务提供专家技术支持,每天都要碰到无数的用户故障,毕竟IAAS涉及比较底层的东西,不管设计的是大客户也好还是小客户,有了问题就必须要解决,也要要是再赶上修复时间紧、奇葩的技术平台、缺少信息和文档,基...
杨经理 2019-12-01 22:03:10 9677 浏览量 回答数 2

问题

如何快速定位云主机的故障

作为一名从事Linux运维行业多年的运维人员,分享一下曾经在运维过程中遇到过的荆手的故障分析,供大家分享,如果你在使用云计算中有什么问题,可以根据以下方式来查找 遇到服务器故障,问题出现的原因很少可以一下就想到。我基本上都会从...
firstsko 2019-12-01 21:43:10 10637 浏览量 回答数 1

问题

如果让你写一个消息队列,该如何进行架构设计?【Java问答学堂】25期

面试题 如果让你写一个消息队列,该如何进行架构设计?说一下你的思路。 面试官心理分析 其实聊到这个问题,一般面试官要考察两块: 你有没有对某一个消息队列做过较为深入的原理的了解...
剑曼红尘 2020-05-25 22:52:15 19 浏览量 回答数 1

回答

详细解答可以参考官方帮助文档 RAM和STS是阿里云提供的权限管理系统。 RAM主要的作用是控制账号系统的权限。通过使用RAM可以将在主账号的权限范围内创建子用户,给不同的子用户分配不同的权限从而达到授权管理的目的。 STS是一个安全凭证(Token)的管理系统,用来授予临时的访问权限,这样就可以通过STS来完成对于临时用户的访问授权。 为什么要使用RAM和STS RAM和STS需要解决的一个核心问题是如何在不暴露主账号的AccessKey的情况下安全的授权别人访问。因为一旦主账号的AccessKey暴露出去的话会带来极大的安全风险,别人可以随意操作该账号下所有的资源,盗取重要信息等。 RAM提供的实际上是一种长期有效的权限控制机制,通过分出不同权限的子账号,将不同的权限分给不同的用户,这样一旦子账号泄露也不会造成全局的信息泄露。但是,由于子账号在一般情况下是长期有效的。 说明 因此,子账号的AccessKey也是不能泄露的。 相对于RAM提供的长效控制机制,STS提供的是一种临时访问授权,通过STS可以返回临时的AccessKey和Token,这些信息是可以直接发给临时用户用来访问OSS。一般来说从STS获取的权限会受到更加严格的限制,并且拥有时间限制,因此这些信息泄露之后对于系统的影响也很小。 这些功能在下文中会以实际的例子来说明。 基本概念 以下是一些基本概念的简单解释: 子账号(RAM account):从阿里云的主账号中创建出来的子账号,在创建的时候可以分配独立的密码和权限,每个子账号拥有自己AccessKey,可以和阿里云主账号一样正常的完成有权限的操作。一般来说,这里的子账号可以理解为具有某种权限的用户,可以被认为是一个具有某些权限的操作发起者。 角色(Role):表示某种操作权限的虚拟概念,但是没有独立的登录密码和AccessKey。 说明 子账号可以扮演角色,扮演角色的时候的权限是该角色自身的权限。 授权策略(Policy):用来定义权限的规则,比如允许用户读取、或者写入某些资源。 资源(Resource):代表用户可访问的云资源,比如OSS所有的Bucket、或者OSS的某个Bucket、或者OSS的某个Bucket下面的某个Object等。 子账号和角色可以类比为某个个人和其身份的关系,某人在公司的角色是员工,在家里的角色是父亲,在不同的场景扮演不同的角色,但是还是同一个人。在扮演不同的角色的时候也就拥有对应角色的权限。单独的员工或者父亲概念并不能作为一个操作的实体,只有有人扮演了之后才是一个完整的概念。这里还可以体现一个重要的概念,那就是角色可以被多个不同的个人同时扮演。 说明 完成角色扮演之后,该个人就自动拥有该角色的所有权限。 这里再用一个例子解释一下。 某个阿里云用户,名为Alice,其在OSS下有两个私有的Bucket,alice_a和alice_b。alice对这两个Bucket都拥有完全的权限。 为了避免阿里云账号的AccessKey泄露导致安全风险,Alice使用RAM创建了两个子账号bob和carol,bob对alice_a拥有读写权限,carol对alice_b拥有读写权限。bob和carol都拥有独立的AccessKey,这样万一泄露了也只会影响其中一个Bucket,而且Alice可以很方便的在控制台取消泄露用户的权限。 现在因为某些原因,需要授权给别人读取alice_a中的Object,这种情况下不应该直接把bob的AccessKey透露出去,那么,这个时候可以新建一个角色,比如AliceAReader,给这个角色赋予读取alice_a的权限。但是请注意,这个时候AliceAReader还是没法直接用的,因为并不存在对应AliceAReader的AccessKey,AliceAReader现在仅仅表示一个拥有访问alice_a权限的一个虚拟实体。 为了能获取临时授权,这个时候可以调用STS的AssumeRole接口,告诉STS,bob将要扮演AliceAReader这个角色,如果成功,STS会返回一个临时的AccessKeyId、AccessKeySecret还有SecurityToken作为访问凭证。将这个凭证发给需要访问的临时用户就可以获得访问alice_a的临时权限了。凭证过期的时间在调用AssumeRole的时候指定。 为什么RAM和STS这么复杂 乍一看RAM和STS的概念是很复杂的,但这是为了权限控制的灵活性而牺牲了部分的易用性。 将子账号和角色分开,主要是为了将执行操作的实体和代表权限集合的虚拟实体分开。如果用户本身需要的权限很多,比如读写权限,但是实际上每次操作只需要其中的一部分权限,那么我们就可以创建两个角色,分别具有读写权限,然后创建一个没有任何权限但是可以拥有扮演这两个角色权限的用户。当用户需要读的时候就可以临时扮演其中拥有读权限的角色,写的时候同理,将每次操作中权限泄露的风险降低。而且通过扮演角色可以将权限授予其他的阿里云用户,更加方便了协同使用。 当然,提供了灵活性并不代表一定要使用全部的功能,应该根据需求来使用其中的一个子集即可。比如不需要带过期时间的临时访问凭证的话,完全可以只使用RAM的子账号功能而无需使用STS。 下面会用范例提供一些RAM和STS的使用指南,以及使用上的建议。示例在操作上会尽量使用控制台和命令行等操作方式,减少实际代码使用。如果需要使用代码来实现建议参看RAM和STS的API手册。 测试工具 在测试中使用到了osscmd,这是OSS的pythonSDK中的一个工具,可以直接在命令行操作OSS。获取的地址为PythonSDK。 osscmd的典型使用方法如下: 下载文件 ./osscmd get oss://BUCKET/OBJECT LOCALFILE --host=Endpoint -i AccessKeyId -k AccessKeySecret 这里的BUCKET和OBJECT替换成自己的,Endpoint的格式类似oss-cn-hangzhou.aliyuncs.com。AccessKeyId和AccessKeySecret使用自己账号对应的 上传文件 ./osscmd put LOCALFILE oss://BUCKET/OBJECT --host=Endpoint -i AccessKeyId -k AccessKeySecret 各个字段含义和下载一致
2019-12-01 23:13:32 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 RAM和STS是阿里云提供的权限管理系统。 RAM主要的作用是控制账号系统的权限。通过使用RAM可以将在主账号的权限范围内创建子用户,给不同的子用户分配不同的权限从而达到授权管理的目的。 STS是一个安全凭证(Token)的管理系统,用来授予临时的访问权限,这样就可以通过STS来完成对于临时用户的访问授权。 为什么要使用RAM和STS RAM和STS需要解决的一个核心问题是如何在不暴露主账号的AccessKey的情况下安全的授权别人访问。因为一旦主账号的AccessKey暴露出去的话会带来极大的安全风险,别人可以随意操作该账号下所有的资源,盗取重要信息等。 RAM提供的实际上是一种长期有效的权限控制机制,通过分出不同权限的子账号,将不同的权限分给不同的用户,这样一旦子账号泄露也不会造成全局的信息泄露。但是,由于子账号在一般情况下是长期有效的。 说明 因此,子账号的AccessKey也是不能泄露的。 相对于RAM提供的长效控制机制,STS提供的是一种临时访问授权,通过STS可以返回临时的AccessKey和Token,这些信息是可以直接发给临时用户用来访问OSS。一般来说从STS获取的权限会受到更加严格的限制,并且拥有时间限制,因此这些信息泄露之后对于系统的影响也很小。 这些功能在下文中会以实际的例子来说明。 基本概念 以下是一些基本概念的简单解释: 子账号(RAM account):从阿里云的主账号中创建出来的子账号,在创建的时候可以分配独立的密码和权限,每个子账号拥有自己AccessKey,可以和阿里云主账号一样正常的完成有权限的操作。一般来说,这里的子账号可以理解为具有某种权限的用户,可以被认为是一个具有某些权限的操作发起者。 角色(Role):表示某种操作权限的虚拟概念,但是没有独立的登录密码和AccessKey。 说明 子账号可以扮演角色,扮演角色的时候的权限是该角色自身的权限。 授权策略(Policy):用来定义权限的规则,比如允许用户读取、或者写入某些资源。 资源(Resource):代表用户可访问的云资源,比如OSS所有的Bucket、或者OSS的某个Bucket、或者OSS的某个Bucket下面的某个Object等。 子账号和角色可以类比为某个个人和其身份的关系,某人在公司的角色是员工,在家里的角色是父亲,在不同的场景扮演不同的角色,但是还是同一个人。在扮演不同的角色的时候也就拥有对应角色的权限。单独的员工或者父亲概念并不能作为一个操作的实体,只有有人扮演了之后才是一个完整的概念。这里还可以体现一个重要的概念,那就是角色可以被多个不同的个人同时扮演。 说明 完成角色扮演之后,该个人就自动拥有该角色的所有权限。 这里再用一个例子解释一下。 某个阿里云用户,名为Alice,其在OSS下有两个私有的Bucket,alice_a和alice_b。alice对这两个Bucket都拥有完全的权限。 为了避免阿里云账号的AccessKey泄露导致安全风险,Alice使用RAM创建了两个子账号bob和carol,bob对alice_a拥有读写权限,carol对alice_b拥有读写权限。bob和carol都拥有独立的AccessKey,这样万一泄露了也只会影响其中一个Bucket,而且Alice可以很方便的在控制台取消泄露用户的权限。 现在因为某些原因,需要授权给别人读取alice_a中的Object,这种情况下不应该直接把bob的AccessKey透露出去,那么,这个时候可以新建一个角色,比如AliceAReader,给这个角色赋予读取alice_a的权限。但是请注意,这个时候AliceAReader还是没法直接用的,因为并不存在对应AliceAReader的AccessKey,AliceAReader现在仅仅表示一个拥有访问alice_a权限的一个虚拟实体。 为了能获取临时授权,这个时候可以调用STS的AssumeRole接口,告诉STS,bob将要扮演AliceAReader这个角色,如果成功,STS会返回一个临时的AccessKeyId、AccessKeySecret还有SecurityToken作为访问凭证。将这个凭证发给需要访问的临时用户就可以获得访问alice_a的临时权限了。凭证过期的时间在调用AssumeRole的时候指定。 为什么RAM和STS这么复杂 乍一看RAM和STS的概念是很复杂的,但这是为了权限控制的灵活性而牺牲了部分的易用性。 将子账号和角色分开,主要是为了将执行操作的实体和代表权限集合的虚拟实体分开。如果用户本身需要的权限很多,比如读写权限,但是实际上每次操作只需要其中的一部分权限,那么我们就可以创建两个角色,分别具有读写权限,然后创建一个没有任何权限但是可以拥有扮演这两个角色权限的用户。当用户需要读的时候就可以临时扮演其中拥有读权限的角色,写的时候同理,将每次操作中权限泄露的风险降低。而且通过扮演角色可以将权限授予其他的阿里云用户,更加方便了协同使用。 当然,提供了灵活性并不代表一定要使用全部的功能,应该根据需求来使用其中的一个子集即可。比如不需要带过期时间的临时访问凭证的话,完全可以只使用RAM的子账号功能而无需使用STS。 下面会用范例提供一些RAM和STS的使用指南,以及使用上的建议。示例在操作上会尽量使用控制台和命令行等操作方式,减少实际代码使用。如果需要使用代码来实现建议参看RAM和STS的API手册。 测试工具 在测试中使用到了osscmd,这是OSS的pythonSDK中的一个工具,可以直接在命令行操作OSS。获取的地址为PythonSDK。 osscmd的典型使用方法如下: 下载文件 ./osscmd get oss://BUCKET/OBJECT LOCALFILE --host=Endpoint -i AccessKeyId -k AccessKeySecret 这里的BUCKET和OBJECT替换成自己的,Endpoint的格式类似oss-cn-hangzhou.aliyuncs.com。AccessKeyId和AccessKeySecret使用自己账号对应的 上传文件 ./osscmd put LOCALFILE oss://BUCKET/OBJECT --host=Endpoint -i AccessKeyId -k AccessKeySecret 各个字段含义和下载一致
2019-12-01 23:13:32 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 RAM和STS是阿里云提供的权限管理系统。 RAM主要的作用是控制账号系统的权限。通过使用RAM可以将在主账号的权限范围内创建子用户,给不同的子用户分配不同的权限从而达到授权管理的目的。 STS是一个安全凭证(Token)的管理系统,用来授予临时的访问权限,这样就可以通过STS来完成对于临时用户的访问授权。 为什么要使用RAM和STS RAM和STS需要解决的一个核心问题是如何在不暴露主账号的AccessKey的情况下安全的授权别人访问。因为一旦主账号的AccessKey暴露出去的话会带来极大的安全风险,别人可以随意操作该账号下所有的资源,盗取重要信息等。 RAM提供的实际上是一种长期有效的权限控制机制,通过分出不同权限的子账号,将不同的权限分给不同的用户,这样一旦子账号泄露也不会造成全局的信息泄露。但是,由于子账号在一般情况下是长期有效的。 说明 因此,子账号的AccessKey也是不能泄露的。 相对于RAM提供的长效控制机制,STS提供的是一种临时访问授权,通过STS可以返回临时的AccessKey和Token,这些信息是可以直接发给临时用户用来访问OSS。一般来说从STS获取的权限会受到更加严格的限制,并且拥有时间限制,因此这些信息泄露之后对于系统的影响也很小。 这些功能在下文中会以实际的例子来说明。 基本概念 以下是一些基本概念的简单解释: 子账号(RAM account):从阿里云的主账号中创建出来的子账号,在创建的时候可以分配独立的密码和权限,每个子账号拥有自己AccessKey,可以和阿里云主账号一样正常的完成有权限的操作。一般来说,这里的子账号可以理解为具有某种权限的用户,可以被认为是一个具有某些权限的操作发起者。 角色(Role):表示某种操作权限的虚拟概念,但是没有独立的登录密码和AccessKey。 说明 子账号可以扮演角色,扮演角色的时候的权限是该角色自身的权限。 授权策略(Policy):用来定义权限的规则,比如允许用户读取、或者写入某些资源。 资源(Resource):代表用户可访问的云资源,比如OSS所有的Bucket、或者OSS的某个Bucket、或者OSS的某个Bucket下面的某个Object等。 子账号和角色可以类比为某个个人和其身份的关系,某人在公司的角色是员工,在家里的角色是父亲,在不同的场景扮演不同的角色,但是还是同一个人。在扮演不同的角色的时候也就拥有对应角色的权限。单独的员工或者父亲概念并不能作为一个操作的实体,只有有人扮演了之后才是一个完整的概念。这里还可以体现一个重要的概念,那就是角色可以被多个不同的个人同时扮演。 说明 完成角色扮演之后,该个人就自动拥有该角色的所有权限。 这里再用一个例子解释一下。 某个阿里云用户,名为Alice,其在OSS下有两个私有的Bucket,alice_a和alice_b。alice对这两个Bucket都拥有完全的权限。 为了避免阿里云账号的AccessKey泄露导致安全风险,Alice使用RAM创建了两个子账号bob和carol,bob对alice_a拥有读写权限,carol对alice_b拥有读写权限。bob和carol都拥有独立的AccessKey,这样万一泄露了也只会影响其中一个Bucket,而且Alice可以很方便的在控制台取消泄露用户的权限。 现在因为某些原因,需要授权给别人读取alice_a中的Object,这种情况下不应该直接把bob的AccessKey透露出去,那么,这个时候可以新建一个角色,比如AliceAReader,给这个角色赋予读取alice_a的权限。但是请注意,这个时候AliceAReader还是没法直接用的,因为并不存在对应AliceAReader的AccessKey,AliceAReader现在仅仅表示一个拥有访问alice_a权限的一个虚拟实体。 为了能获取临时授权,这个时候可以调用STS的AssumeRole接口,告诉STS,bob将要扮演AliceAReader这个角色,如果成功,STS会返回一个临时的AccessKeyId、AccessKeySecret还有SecurityToken作为访问凭证。将这个凭证发给需要访问的临时用户就可以获得访问alice_a的临时权限了。凭证过期的时间在调用AssumeRole的时候指定。 为什么RAM和STS这么复杂 乍一看RAM和STS的概念是很复杂的,但这是为了权限控制的灵活性而牺牲了部分的易用性。 将子账号和角色分开,主要是为了将执行操作的实体和代表权限集合的虚拟实体分开。如果用户本身需要的权限很多,比如读写权限,但是实际上每次操作只需要其中的一部分权限,那么我们就可以创建两个角色,分别具有读写权限,然后创建一个没有任何权限但是可以拥有扮演这两个角色权限的用户。当用户需要读的时候就可以临时扮演其中拥有读权限的角色,写的时候同理,将每次操作中权限泄露的风险降低。而且通过扮演角色可以将权限授予其他的阿里云用户,更加方便了协同使用。 当然,提供了灵活性并不代表一定要使用全部的功能,应该根据需求来使用其中的一个子集即可。比如不需要带过期时间的临时访问凭证的话,完全可以只使用RAM的子账号功能而无需使用STS。 下面会用范例提供一些RAM和STS的使用指南,以及使用上的建议。示例在操作上会尽量使用控制台和命令行等操作方式,减少实际代码使用。如果需要使用代码来实现建议参看RAM和STS的API手册。 测试工具 在测试中使用到了osscmd,这是OSS的pythonSDK中的一个工具,可以直接在命令行操作OSS。获取的地址为PythonSDK。 osscmd的典型使用方法如下: 下载文件 ./osscmd get oss://BUCKET/OBJECT LOCALFILE --host=Endpoint -i AccessKeyId -k AccessKeySecret 这里的BUCKET和OBJECT替换成自己的,Endpoint的格式类似oss-cn-hangzhou.aliyuncs.com。AccessKeyId和AccessKeySecret使用自己账号对应的 上传文件 ./osscmd put LOCALFILE oss://BUCKET/OBJECT --host=Endpoint -i AccessKeyId -k AccessKeySecret 各个字段含义和下载一致
2019-12-01 23:13:31 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 RAM和STS是阿里云提供的权限管理系统。 RAM主要的作用是控制账号系统的权限。通过使用RAM可以将在主账号的权限范围内创建子用户,给不同的子用户分配不同的权限从而达到授权管理的目的。 STS是一个安全凭证(Token)的管理系统,用来授予临时的访问权限,这样就可以通过STS来完成对于临时用户的访问授权。 为什么要使用RAM和STS RAM和STS需要解决的一个核心问题是如何在不暴露主账号的AccessKey的情况下安全的授权别人访问。因为一旦主账号的AccessKey暴露出去的话会带来极大的安全风险,别人可以随意操作该账号下所有的资源,盗取重要信息等。 RAM提供的实际上是一种长期有效的权限控制机制,通过分出不同权限的子账号,将不同的权限分给不同的用户,这样一旦子账号泄露也不会造成全局的信息泄露。但是,由于子账号在一般情况下是长期有效的。 说明 因此,子账号的AccessKey也是不能泄露的。 相对于RAM提供的长效控制机制,STS提供的是一种临时访问授权,通过STS可以返回临时的AccessKey和Token,这些信息是可以直接发给临时用户用来访问OSS。一般来说从STS获取的权限会受到更加严格的限制,并且拥有时间限制,因此这些信息泄露之后对于系统的影响也很小。 这些功能在下文中会以实际的例子来说明。 基本概念 以下是一些基本概念的简单解释: 子账号(RAM account):从阿里云的主账号中创建出来的子账号,在创建的时候可以分配独立的密码和权限,每个子账号拥有自己AccessKey,可以和阿里云主账号一样正常的完成有权限的操作。一般来说,这里的子账号可以理解为具有某种权限的用户,可以被认为是一个具有某些权限的操作发起者。 角色(Role):表示某种操作权限的虚拟概念,但是没有独立的登录密码和AccessKey。 说明 子账号可以扮演角色,扮演角色的时候的权限是该角色自身的权限。 授权策略(Policy):用来定义权限的规则,比如允许用户读取、或者写入某些资源。 资源(Resource):代表用户可访问的云资源,比如OSS所有的Bucket、或者OSS的某个Bucket、或者OSS的某个Bucket下面的某个Object等。 子账号和角色可以类比为某个个人和其身份的关系,某人在公司的角色是员工,在家里的角色是父亲,在不同的场景扮演不同的角色,但是还是同一个人。在扮演不同的角色的时候也就拥有对应角色的权限。单独的员工或者父亲概念并不能作为一个操作的实体,只有有人扮演了之后才是一个完整的概念。这里还可以体现一个重要的概念,那就是角色可以被多个不同的个人同时扮演。 说明 完成角色扮演之后,该个人就自动拥有该角色的所有权限。 这里再用一个例子解释一下。 某个阿里云用户,名为Alice,其在OSS下有两个私有的Bucket,alice_a和alice_b。alice对这两个Bucket都拥有完全的权限。 为了避免阿里云账号的AccessKey泄露导致安全风险,Alice使用RAM创建了两个子账号bob和carol,bob对alice_a拥有读写权限,carol对alice_b拥有读写权限。bob和carol都拥有独立的AccessKey,这样万一泄露了也只会影响其中一个Bucket,而且Alice可以很方便的在控制台取消泄露用户的权限。 现在因为某些原因,需要授权给别人读取alice_a中的Object,这种情况下不应该直接把bob的AccessKey透露出去,那么,这个时候可以新建一个角色,比如AliceAReader,给这个角色赋予读取alice_a的权限。但是请注意,这个时候AliceAReader还是没法直接用的,因为并不存在对应AliceAReader的AccessKey,AliceAReader现在仅仅表示一个拥有访问alice_a权限的一个虚拟实体。 为了能获取临时授权,这个时候可以调用STS的AssumeRole接口,告诉STS,bob将要扮演AliceAReader这个角色,如果成功,STS会返回一个临时的AccessKeyId、AccessKeySecret还有SecurityToken作为访问凭证。将这个凭证发给需要访问的临时用户就可以获得访问alice_a的临时权限了。凭证过期的时间在调用AssumeRole的时候指定。 为什么RAM和STS这么复杂 乍一看RAM和STS的概念是很复杂的,但这是为了权限控制的灵活性而牺牲了部分的易用性。 将子账号和角色分开,主要是为了将执行操作的实体和代表权限集合的虚拟实体分开。如果用户本身需要的权限很多,比如读写权限,但是实际上每次操作只需要其中的一部分权限,那么我们就可以创建两个角色,分别具有读写权限,然后创建一个没有任何权限但是可以拥有扮演这两个角色权限的用户。当用户需要读的时候就可以临时扮演其中拥有读权限的角色,写的时候同理,将每次操作中权限泄露的风险降低。而且通过扮演角色可以将权限授予其他的阿里云用户,更加方便了协同使用。 当然,提供了灵活性并不代表一定要使用全部的功能,应该根据需求来使用其中的一个子集即可。比如不需要带过期时间的临时访问凭证的话,完全可以只使用RAM的子账号功能而无需使用STS。 下面会用范例提供一些RAM和STS的使用指南,以及使用上的建议。示例在操作上会尽量使用控制台和命令行等操作方式,减少实际代码使用。如果需要使用代码来实现建议参看RAM和STS的API手册。 测试工具 在测试中使用到了osscmd,这是OSS的pythonSDK中的一个工具,可以直接在命令行操作OSS。获取的地址为PythonSDK。 osscmd的典型使用方法如下: 下载文件 ./osscmd get oss://BUCKET/OBJECT LOCALFILE --host=Endpoint -i AccessKeyId -k AccessKeySecret 这里的BUCKET和OBJECT替换成自己的,Endpoint的格式类似oss-cn-hangzhou.aliyuncs.com。AccessKeyId和AccessKeySecret使用自己账号对应的 上传文件 ./osscmd put LOCALFILE oss://BUCKET/OBJECT --host=Endpoint -i AccessKeyId -k AccessKeySecret 各个字段含义和下载一致
2019-12-01 23:13:32 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 RAM和STS是阿里云提供的权限管理系统。 RAM主要的作用是控制账号系统的权限。通过使用RAM可以将在主账号的权限范围内创建子用户,给不同的子用户分配不同的权限从而达到授权管理的目的。 STS是一个安全凭证(Token)的管理系统,用来授予临时的访问权限,这样就可以通过STS来完成对于临时用户的访问授权。 为什么要使用RAM和STS RAM和STS需要解决的一个核心问题是如何在不暴露主账号的AccessKey的情况下安全的授权别人访问。因为一旦主账号的AccessKey暴露出去的话会带来极大的安全风险,别人可以随意操作该账号下所有的资源,盗取重要信息等。 RAM提供的实际上是一种长期有效的权限控制机制,通过分出不同权限的子账号,将不同的权限分给不同的用户,这样一旦子账号泄露也不会造成全局的信息泄露。但是,由于子账号在一般情况下是长期有效的。 说明 因此,子账号的AccessKey也是不能泄露的。 相对于RAM提供的长效控制机制,STS提供的是一种临时访问授权,通过STS可以返回临时的AccessKey和Token,这些信息是可以直接发给临时用户用来访问OSS。一般来说从STS获取的权限会受到更加严格的限制,并且拥有时间限制,因此这些信息泄露之后对于系统的影响也很小。 这些功能在下文中会以实际的例子来说明。 基本概念 以下是一些基本概念的简单解释: 子账号(RAM account):从阿里云的主账号中创建出来的子账号,在创建的时候可以分配独立的密码和权限,每个子账号拥有自己AccessKey,可以和阿里云主账号一样正常的完成有权限的操作。一般来说,这里的子账号可以理解为具有某种权限的用户,可以被认为是一个具有某些权限的操作发起者。 角色(Role):表示某种操作权限的虚拟概念,但是没有独立的登录密码和AccessKey。 说明 子账号可以扮演角色,扮演角色的时候的权限是该角色自身的权限。 授权策略(Policy):用来定义权限的规则,比如允许用户读取、或者写入某些资源。 资源(Resource):代表用户可访问的云资源,比如OSS所有的Bucket、或者OSS的某个Bucket、或者OSS的某个Bucket下面的某个Object等。 子账号和角色可以类比为某个个人和其身份的关系,某人在公司的角色是员工,在家里的角色是父亲,在不同的场景扮演不同的角色,但是还是同一个人。在扮演不同的角色的时候也就拥有对应角色的权限。单独的员工或者父亲概念并不能作为一个操作的实体,只有有人扮演了之后才是一个完整的概念。这里还可以体现一个重要的概念,那就是角色可以被多个不同的个人同时扮演。 说明 完成角色扮演之后,该个人就自动拥有该角色的所有权限。 这里再用一个例子解释一下。 某个阿里云用户,名为Alice,其在OSS下有两个私有的Bucket,alice_a和alice_b。alice对这两个Bucket都拥有完全的权限。 为了避免阿里云账号的AccessKey泄露导致安全风险,Alice使用RAM创建了两个子账号bob和carol,bob对alice_a拥有读写权限,carol对alice_b拥有读写权限。bob和carol都拥有独立的AccessKey,这样万一泄露了也只会影响其中一个Bucket,而且Alice可以很方便的在控制台取消泄露用户的权限。 现在因为某些原因,需要授权给别人读取alice_a中的Object,这种情况下不应该直接把bob的AccessKey透露出去,那么,这个时候可以新建一个角色,比如AliceAReader,给这个角色赋予读取alice_a的权限。但是请注意,这个时候AliceAReader还是没法直接用的,因为并不存在对应AliceAReader的AccessKey,AliceAReader现在仅仅表示一个拥有访问alice_a权限的一个虚拟实体。 为了能获取临时授权,这个时候可以调用STS的AssumeRole接口,告诉STS,bob将要扮演AliceAReader这个角色,如果成功,STS会返回一个临时的AccessKeyId、AccessKeySecret还有SecurityToken作为访问凭证。将这个凭证发给需要访问的临时用户就可以获得访问alice_a的临时权限了。凭证过期的时间在调用AssumeRole的时候指定。 为什么RAM和STS这么复杂 乍一看RAM和STS的概念是很复杂的,但这是为了权限控制的灵活性而牺牲了部分的易用性。 将子账号和角色分开,主要是为了将执行操作的实体和代表权限集合的虚拟实体分开。如果用户本身需要的权限很多,比如读写权限,但是实际上每次操作只需要其中的一部分权限,那么我们就可以创建两个角色,分别具有读写权限,然后创建一个没有任何权限但是可以拥有扮演这两个角色权限的用户。当用户需要读的时候就可以临时扮演其中拥有读权限的角色,写的时候同理,将每次操作中权限泄露的风险降低。而且通过扮演角色可以将权限授予其他的阿里云用户,更加方便了协同使用。 当然,提供了灵活性并不代表一定要使用全部的功能,应该根据需求来使用其中的一个子集即可。比如不需要带过期时间的临时访问凭证的话,完全可以只使用RAM的子账号功能而无需使用STS。 下面会用范例提供一些RAM和STS的使用指南,以及使用上的建议。示例在操作上会尽量使用控制台和命令行等操作方式,减少实际代码使用。如果需要使用代码来实现建议参看RAM和STS的API手册。 测试工具 在测试中使用到了osscmd,这是OSS的pythonSDK中的一个工具,可以直接在命令行操作OSS。获取的地址为PythonSDK。 osscmd的典型使用方法如下: 下载文件 ./osscmd get oss://BUCKET/OBJECT LOCALFILE --host=Endpoint -i AccessKeyId -k AccessKeySecret 这里的BUCKET和OBJECT替换成自己的,Endpoint的格式类似oss-cn-hangzhou.aliyuncs.com。AccessKeyId和AccessKeySecret使用自己账号对应的 上传文件 ./osscmd put LOCALFILE oss://BUCKET/OBJECT --host=Endpoint -i AccessKeyId -k AccessKeySecret 各个字段含义和下载一致
2019-12-01 23:13:32 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 RAM和STS是阿里云提供的权限管理系统。 RAM主要的作用是控制账号系统的权限。通过使用RAM可以将在主账号的权限范围内创建子用户,给不同的子用户分配不同的权限从而达到授权管理的目的。 STS是一个安全凭证(Token)的管理系统,用来授予临时的访问权限,这样就可以通过STS来完成对于临时用户的访问授权。 为什么要使用RAM和STS RAM和STS需要解决的一个核心问题是如何在不暴露主账号的AccessKey的情况下安全的授权别人访问。因为一旦主账号的AccessKey暴露出去的话会带来极大的安全风险,别人可以随意操作该账号下所有的资源,盗取重要信息等。 RAM提供的实际上是一种长期有效的权限控制机制,通过分出不同权限的子账号,将不同的权限分给不同的用户,这样一旦子账号泄露也不会造成全局的信息泄露。但是,由于子账号在一般情况下是长期有效的。 说明 因此,子账号的AccessKey也是不能泄露的。 相对于RAM提供的长效控制机制,STS提供的是一种临时访问授权,通过STS可以返回临时的AccessKey和Token,这些信息是可以直接发给临时用户用来访问OSS。一般来说从STS获取的权限会受到更加严格的限制,并且拥有时间限制,因此这些信息泄露之后对于系统的影响也很小。 这些功能在下文中会以实际的例子来说明。 基本概念 以下是一些基本概念的简单解释: 子账号(RAM account):从阿里云的主账号中创建出来的子账号,在创建的时候可以分配独立的密码和权限,每个子账号拥有自己AccessKey,可以和阿里云主账号一样正常的完成有权限的操作。一般来说,这里的子账号可以理解为具有某种权限的用户,可以被认为是一个具有某些权限的操作发起者。 角色(Role):表示某种操作权限的虚拟概念,但是没有独立的登录密码和AccessKey。 说明 子账号可以扮演角色,扮演角色的时候的权限是该角色自身的权限。 授权策略(Policy):用来定义权限的规则,比如允许用户读取、或者写入某些资源。 资源(Resource):代表用户可访问的云资源,比如OSS所有的Bucket、或者OSS的某个Bucket、或者OSS的某个Bucket下面的某个Object等。 子账号和角色可以类比为某个个人和其身份的关系,某人在公司的角色是员工,在家里的角色是父亲,在不同的场景扮演不同的角色,但是还是同一个人。在扮演不同的角色的时候也就拥有对应角色的权限。单独的员工或者父亲概念并不能作为一个操作的实体,只有有人扮演了之后才是一个完整的概念。这里还可以体现一个重要的概念,那就是角色可以被多个不同的个人同时扮演。 说明 完成角色扮演之后,该个人就自动拥有该角色的所有权限。 这里再用一个例子解释一下。 某个阿里云用户,名为Alice,其在OSS下有两个私有的Bucket,alice_a和alice_b。alice对这两个Bucket都拥有完全的权限。 为了避免阿里云账号的AccessKey泄露导致安全风险,Alice使用RAM创建了两个子账号bob和carol,bob对alice_a拥有读写权限,carol对alice_b拥有读写权限。bob和carol都拥有独立的AccessKey,这样万一泄露了也只会影响其中一个Bucket,而且Alice可以很方便的在控制台取消泄露用户的权限。 现在因为某些原因,需要授权给别人读取alice_a中的Object,这种情况下不应该直接把bob的AccessKey透露出去,那么,这个时候可以新建一个角色,比如AliceAReader,给这个角色赋予读取alice_a的权限。但是请注意,这个时候AliceAReader还是没法直接用的,因为并不存在对应AliceAReader的AccessKey,AliceAReader现在仅仅表示一个拥有访问alice_a权限的一个虚拟实体。 为了能获取临时授权,这个时候可以调用STS的AssumeRole接口,告诉STS,bob将要扮演AliceAReader这个角色,如果成功,STS会返回一个临时的AccessKeyId、AccessKeySecret还有SecurityToken作为访问凭证。将这个凭证发给需要访问的临时用户就可以获得访问alice_a的临时权限了。凭证过期的时间在调用AssumeRole的时候指定。 为什么RAM和STS这么复杂 乍一看RAM和STS的概念是很复杂的,但这是为了权限控制的灵活性而牺牲了部分的易用性。 将子账号和角色分开,主要是为了将执行操作的实体和代表权限集合的虚拟实体分开。如果用户本身需要的权限很多,比如读写权限,但是实际上每次操作只需要其中的一部分权限,那么我们就可以创建两个角色,分别具有读写权限,然后创建一个没有任何权限但是可以拥有扮演这两个角色权限的用户。当用户需要读的时候就可以临时扮演其中拥有读权限的角色,写的时候同理,将每次操作中权限泄露的风险降低。而且通过扮演角色可以将权限授予其他的阿里云用户,更加方便了协同使用。 当然,提供了灵活性并不代表一定要使用全部的功能,应该根据需求来使用其中的一个子集即可。比如不需要带过期时间的临时访问凭证的话,完全可以只使用RAM的子账号功能而无需使用STS。 下面会用范例提供一些RAM和STS的使用指南,以及使用上的建议。示例在操作上会尽量使用控制台和命令行等操作方式,减少实际代码使用。如果需要使用代码来实现建议参看RAM和STS的API手册。 测试工具 在测试中使用到了osscmd,这是OSS的pythonSDK中的一个工具,可以直接在命令行操作OSS。获取的地址为PythonSDK。 osscmd的典型使用方法如下: 下载文件 ./osscmd get oss://BUCKET/OBJECT LOCALFILE --host=Endpoint -i AccessKeyId -k AccessKeySecret 这里的BUCKET和OBJECT替换成自己的,Endpoint的格式类似oss-cn-hangzhou.aliyuncs.com。AccessKeyId和AccessKeySecret使用自己账号对应的 上传文件 ./osscmd put LOCALFILE oss://BUCKET/OBJECT --host=Endpoint -i AccessKeyId -k AccessKeySecret 各个字段含义和下载一致
2019-12-01 23:13:31 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 RAM和STS是阿里云提供的权限管理系统。 RAM主要的作用是控制账号系统的权限。通过使用RAM可以将在主账号的权限范围内创建子用户,给不同的子用户分配不同的权限从而达到授权管理的目的。 STS是一个安全凭证(Token)的管理系统,用来授予临时的访问权限,这样就可以通过STS来完成对于临时用户的访问授权。 为什么要使用RAM和STS RAM和STS需要解决的一个核心问题是如何在不暴露主账号的AccessKey的情况下安全的授权别人访问。因为一旦主账号的AccessKey暴露出去的话会带来极大的安全风险,别人可以随意操作该账号下所有的资源,盗取重要信息等。 RAM提供的实际上是一种长期有效的权限控制机制,通过分出不同权限的子账号,将不同的权限分给不同的用户,这样一旦子账号泄露也不会造成全局的信息泄露。但是,由于子账号在一般情况下是长期有效的。 说明 因此,子账号的AccessKey也是不能泄露的。 相对于RAM提供的长效控制机制,STS提供的是一种临时访问授权,通过STS可以返回临时的AccessKey和Token,这些信息是可以直接发给临时用户用来访问OSS。一般来说从STS获取的权限会受到更加严格的限制,并且拥有时间限制,因此这些信息泄露之后对于系统的影响也很小。 这些功能在下文中会以实际的例子来说明。 基本概念 以下是一些基本概念的简单解释: 子账号(RAM account):从阿里云的主账号中创建出来的子账号,在创建的时候可以分配独立的密码和权限,每个子账号拥有自己AccessKey,可以和阿里云主账号一样正常的完成有权限的操作。一般来说,这里的子账号可以理解为具有某种权限的用户,可以被认为是一个具有某些权限的操作发起者。 角色(Role):表示某种操作权限的虚拟概念,但是没有独立的登录密码和AccessKey。 说明 子账号可以扮演角色,扮演角色的时候的权限是该角色自身的权限。 授权策略(Policy):用来定义权限的规则,比如允许用户读取、或者写入某些资源。 资源(Resource):代表用户可访问的云资源,比如OSS所有的Bucket、或者OSS的某个Bucket、或者OSS的某个Bucket下面的某个Object等。 子账号和角色可以类比为某个个人和其身份的关系,某人在公司的角色是员工,在家里的角色是父亲,在不同的场景扮演不同的角色,但是还是同一个人。在扮演不同的角色的时候也就拥有对应角色的权限。单独的员工或者父亲概念并不能作为一个操作的实体,只有有人扮演了之后才是一个完整的概念。这里还可以体现一个重要的概念,那就是角色可以被多个不同的个人同时扮演。 说明 完成角色扮演之后,该个人就自动拥有该角色的所有权限。 这里再用一个例子解释一下。 某个阿里云用户,名为Alice,其在OSS下有两个私有的Bucket,alice_a和alice_b。alice对这两个Bucket都拥有完全的权限。 为了避免阿里云账号的AccessKey泄露导致安全风险,Alice使用RAM创建了两个子账号bob和carol,bob对alice_a拥有读写权限,carol对alice_b拥有读写权限。bob和carol都拥有独立的AccessKey,这样万一泄露了也只会影响其中一个Bucket,而且Alice可以很方便的在控制台取消泄露用户的权限。 现在因为某些原因,需要授权给别人读取alice_a中的Object,这种情况下不应该直接把bob的AccessKey透露出去,那么,这个时候可以新建一个角色,比如AliceAReader,给这个角色赋予读取alice_a的权限。但是请注意,这个时候AliceAReader还是没法直接用的,因为并不存在对应AliceAReader的AccessKey,AliceAReader现在仅仅表示一个拥有访问alice_a权限的一个虚拟实体。 为了能获取临时授权,这个时候可以调用STS的AssumeRole接口,告诉STS,bob将要扮演AliceAReader这个角色,如果成功,STS会返回一个临时的AccessKeyId、AccessKeySecret还有SecurityToken作为访问凭证。将这个凭证发给需要访问的临时用户就可以获得访问alice_a的临时权限了。凭证过期的时间在调用AssumeRole的时候指定。 为什么RAM和STS这么复杂 乍一看RAM和STS的概念是很复杂的,但这是为了权限控制的灵活性而牺牲了部分的易用性。 将子账号和角色分开,主要是为了将执行操作的实体和代表权限集合的虚拟实体分开。如果用户本身需要的权限很多,比如读写权限,但是实际上每次操作只需要其中的一部分权限,那么我们就可以创建两个角色,分别具有读写权限,然后创建一个没有任何权限但是可以拥有扮演这两个角色权限的用户。当用户需要读的时候就可以临时扮演其中拥有读权限的角色,写的时候同理,将每次操作中权限泄露的风险降低。而且通过扮演角色可以将权限授予其他的阿里云用户,更加方便了协同使用。 当然,提供了灵活性并不代表一定要使用全部的功能,应该根据需求来使用其中的一个子集即可。比如不需要带过期时间的临时访问凭证的话,完全可以只使用RAM的子账号功能而无需使用STS。 下面会用范例提供一些RAM和STS的使用指南,以及使用上的建议。示例在操作上会尽量使用控制台和命令行等操作方式,减少实际代码使用。如果需要使用代码来实现建议参看RAM和STS的API手册。 测试工具 在测试中使用到了osscmd,这是OSS的pythonSDK中的一个工具,可以直接在命令行操作OSS。获取的地址为PythonSDK。 osscmd的典型使用方法如下: 下载文件 ./osscmd get oss://BUCKET/OBJECT LOCALFILE --host=Endpoint -i AccessKeyId -k AccessKeySecret 这里的BUCKET和OBJECT替换成自己的,Endpoint的格式类似oss-cn-hangzhou.aliyuncs.com。AccessKeyId和AccessKeySecret使用自己账号对应的 上传文件 ./osscmd put LOCALFILE oss://BUCKET/OBJECT --host=Endpoint -i AccessKeyId -k AccessKeySecret 各个字段含义和下载一致
2019-12-01 23:13:32 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 RAM和STS是阿里云提供的权限管理系统。 RAM主要的作用是控制账号系统的权限。通过使用RAM可以将在主账号的权限范围内创建子用户,给不同的子用户分配不同的权限从而达到授权管理的目的。 STS是一个安全凭证(Token)的管理系统,用来授予临时的访问权限,这样就可以通过STS来完成对于临时用户的访问授权。 为什么要使用RAM和STS RAM和STS需要解决的一个核心问题是如何在不暴露主账号的AccessKey的情况下安全的授权别人访问。因为一旦主账号的AccessKey暴露出去的话会带来极大的安全风险,别人可以随意操作该账号下所有的资源,盗取重要信息等。 RAM提供的实际上是一种长期有效的权限控制机制,通过分出不同权限的子账号,将不同的权限分给不同的用户,这样一旦子账号泄露也不会造成全局的信息泄露。但是,由于子账号在一般情况下是长期有效的。 说明 因此,子账号的AccessKey也是不能泄露的。 相对于RAM提供的长效控制机制,STS提供的是一种临时访问授权,通过STS可以返回临时的AccessKey和Token,这些信息是可以直接发给临时用户用来访问OSS。一般来说从STS获取的权限会受到更加严格的限制,并且拥有时间限制,因此这些信息泄露之后对于系统的影响也很小。 这些功能在下文中会以实际的例子来说明。 基本概念 以下是一些基本概念的简单解释: 子账号(RAM account):从阿里云的主账号中创建出来的子账号,在创建的时候可以分配独立的密码和权限,每个子账号拥有自己AccessKey,可以和阿里云主账号一样正常的完成有权限的操作。一般来说,这里的子账号可以理解为具有某种权限的用户,可以被认为是一个具有某些权限的操作发起者。 角色(Role):表示某种操作权限的虚拟概念,但是没有独立的登录密码和AccessKey。 说明 子账号可以扮演角色,扮演角色的时候的权限是该角色自身的权限。 授权策略(Policy):用来定义权限的规则,比如允许用户读取、或者写入某些资源。 资源(Resource):代表用户可访问的云资源,比如OSS所有的Bucket、或者OSS的某个Bucket、或者OSS的某个Bucket下面的某个Object等。 子账号和角色可以类比为某个个人和其身份的关系,某人在公司的角色是员工,在家里的角色是父亲,在不同的场景扮演不同的角色,但是还是同一个人。在扮演不同的角色的时候也就拥有对应角色的权限。单独的员工或者父亲概念并不能作为一个操作的实体,只有有人扮演了之后才是一个完整的概念。这里还可以体现一个重要的概念,那就是角色可以被多个不同的个人同时扮演。 说明 完成角色扮演之后,该个人就自动拥有该角色的所有权限。 这里再用一个例子解释一下。 某个阿里云用户,名为Alice,其在OSS下有两个私有的Bucket,alice_a和alice_b。alice对这两个Bucket都拥有完全的权限。 为了避免阿里云账号的AccessKey泄露导致安全风险,Alice使用RAM创建了两个子账号bob和carol,bob对alice_a拥有读写权限,carol对alice_b拥有读写权限。bob和carol都拥有独立的AccessKey,这样万一泄露了也只会影响其中一个Bucket,而且Alice可以很方便的在控制台取消泄露用户的权限。 现在因为某些原因,需要授权给别人读取alice_a中的Object,这种情况下不应该直接把bob的AccessKey透露出去,那么,这个时候可以新建一个角色,比如AliceAReader,给这个角色赋予读取alice_a的权限。但是请注意,这个时候AliceAReader还是没法直接用的,因为并不存在对应AliceAReader的AccessKey,AliceAReader现在仅仅表示一个拥有访问alice_a权限的一个虚拟实体。 为了能获取临时授权,这个时候可以调用STS的AssumeRole接口,告诉STS,bob将要扮演AliceAReader这个角色,如果成功,STS会返回一个临时的AccessKeyId、AccessKeySecret还有SecurityToken作为访问凭证。将这个凭证发给需要访问的临时用户就可以获得访问alice_a的临时权限了。凭证过期的时间在调用AssumeRole的时候指定。 为什么RAM和STS这么复杂 乍一看RAM和STS的概念是很复杂的,但这是为了权限控制的灵活性而牺牲了部分的易用性。 将子账号和角色分开,主要是为了将执行操作的实体和代表权限集合的虚拟实体分开。如果用户本身需要的权限很多,比如读写权限,但是实际上每次操作只需要其中的一部分权限,那么我们就可以创建两个角色,分别具有读写权限,然后创建一个没有任何权限但是可以拥有扮演这两个角色权限的用户。当用户需要读的时候就可以临时扮演其中拥有读权限的角色,写的时候同理,将每次操作中权限泄露的风险降低。而且通过扮演角色可以将权限授予其他的阿里云用户,更加方便了协同使用。 当然,提供了灵活性并不代表一定要使用全部的功能,应该根据需求来使用其中的一个子集即可。比如不需要带过期时间的临时访问凭证的话,完全可以只使用RAM的子账号功能而无需使用STS。 下面会用范例提供一些RAM和STS的使用指南,以及使用上的建议。示例在操作上会尽量使用控制台和命令行等操作方式,减少实际代码使用。如果需要使用代码来实现建议参看RAM和STS的API手册。 测试工具 在测试中使用到了osscmd,这是OSS的pythonSDK中的一个工具,可以直接在命令行操作OSS。获取的地址为PythonSDK。 osscmd的典型使用方法如下: 下载文件 ./osscmd get oss://BUCKET/OBJECT LOCALFILE --host=Endpoint -i AccessKeyId -k AccessKeySecret 这里的BUCKET和OBJECT替换成自己的,Endpoint的格式类似oss-cn-hangzhou.aliyuncs.com。AccessKeyId和AccessKeySecret使用自己账号对应的 上传文件 ./osscmd put LOCALFILE oss://BUCKET/OBJECT --host=Endpoint -i AccessKeyId -k AccessKeySecret 各个字段含义和下载一致
2019-12-01 23:13:32 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 RAM和STS是阿里云提供的权限管理系统。 RAM主要的作用是控制账号系统的权限。通过使用RAM可以将在主账号的权限范围内创建子用户,给不同的子用户分配不同的权限从而达到授权管理的目的。 STS是一个安全凭证(Token)的管理系统,用来授予临时的访问权限,这样就可以通过STS来完成对于临时用户的访问授权。 为什么要使用RAM和STS RAM和STS需要解决的一个核心问题是如何在不暴露主账号的AccessKey的情况下安全的授权别人访问。因为一旦主账号的AccessKey暴露出去的话会带来极大的安全风险,别人可以随意操作该账号下所有的资源,盗取重要信息等。 RAM提供的实际上是一种长期有效的权限控制机制,通过分出不同权限的子账号,将不同的权限分给不同的用户,这样一旦子账号泄露也不会造成全局的信息泄露。但是,由于子账号在一般情况下是长期有效的。 说明 因此,子账号的AccessKey也是不能泄露的。 相对于RAM提供的长效控制机制,STS提供的是一种临时访问授权,通过STS可以返回临时的AccessKey和Token,这些信息是可以直接发给临时用户用来访问OSS。一般来说从STS获取的权限会受到更加严格的限制,并且拥有时间限制,因此这些信息泄露之后对于系统的影响也很小。 这些功能在下文中会以实际的例子来说明。 基本概念 以下是一些基本概念的简单解释: 子账号(RAM account):从阿里云的主账号中创建出来的子账号,在创建的时候可以分配独立的密码和权限,每个子账号拥有自己AccessKey,可以和阿里云主账号一样正常的完成有权限的操作。一般来说,这里的子账号可以理解为具有某种权限的用户,可以被认为是一个具有某些权限的操作发起者。 角色(Role):表示某种操作权限的虚拟概念,但是没有独立的登录密码和AccessKey。 说明 子账号可以扮演角色,扮演角色的时候的权限是该角色自身的权限。 授权策略(Policy):用来定义权限的规则,比如允许用户读取、或者写入某些资源。 资源(Resource):代表用户可访问的云资源,比如OSS所有的Bucket、或者OSS的某个Bucket、或者OSS的某个Bucket下面的某个Object等。 子账号和角色可以类比为某个个人和其身份的关系,某人在公司的角色是员工,在家里的角色是父亲,在不同的场景扮演不同的角色,但是还是同一个人。在扮演不同的角色的时候也就拥有对应角色的权限。单独的员工或者父亲概念并不能作为一个操作的实体,只有有人扮演了之后才是一个完整的概念。这里还可以体现一个重要的概念,那就是角色可以被多个不同的个人同时扮演。 说明 完成角色扮演之后,该个人就自动拥有该角色的所有权限。 这里再用一个例子解释一下。 某个阿里云用户,名为Alice,其在OSS下有两个私有的Bucket,alice_a和alice_b。alice对这两个Bucket都拥有完全的权限。 为了避免阿里云账号的AccessKey泄露导致安全风险,Alice使用RAM创建了两个子账号bob和carol,bob对alice_a拥有读写权限,carol对alice_b拥有读写权限。bob和carol都拥有独立的AccessKey,这样万一泄露了也只会影响其中一个Bucket,而且Alice可以很方便的在控制台取消泄露用户的权限。 现在因为某些原因,需要授权给别人读取alice_a中的Object,这种情况下不应该直接把bob的AccessKey透露出去,那么,这个时候可以新建一个角色,比如AliceAReader,给这个角色赋予读取alice_a的权限。但是请注意,这个时候AliceAReader还是没法直接用的,因为并不存在对应AliceAReader的AccessKey,AliceAReader现在仅仅表示一个拥有访问alice_a权限的一个虚拟实体。 为了能获取临时授权,这个时候可以调用STS的AssumeRole接口,告诉STS,bob将要扮演AliceAReader这个角色,如果成功,STS会返回一个临时的AccessKeyId、AccessKeySecret还有SecurityToken作为访问凭证。将这个凭证发给需要访问的临时用户就可以获得访问alice_a的临时权限了。凭证过期的时间在调用AssumeRole的时候指定。 为什么RAM和STS这么复杂 乍一看RAM和STS的概念是很复杂的,但这是为了权限控制的灵活性而牺牲了部分的易用性。 将子账号和角色分开,主要是为了将执行操作的实体和代表权限集合的虚拟实体分开。如果用户本身需要的权限很多,比如读写权限,但是实际上每次操作只需要其中的一部分权限,那么我们就可以创建两个角色,分别具有读写权限,然后创建一个没有任何权限但是可以拥有扮演这两个角色权限的用户。当用户需要读的时候就可以临时扮演其中拥有读权限的角色,写的时候同理,将每次操作中权限泄露的风险降低。而且通过扮演角色可以将权限授予其他的阿里云用户,更加方便了协同使用。 当然,提供了灵活性并不代表一定要使用全部的功能,应该根据需求来使用其中的一个子集即可。比如不需要带过期时间的临时访问凭证的话,完全可以只使用RAM的子账号功能而无需使用STS。 下面会用范例提供一些RAM和STS的使用指南,以及使用上的建议。示例在操作上会尽量使用控制台和命令行等操作方式,减少实际代码使用。如果需要使用代码来实现建议参看RAM和STS的API手册。 测试工具 在测试中使用到了osscmd,这是OSS的pythonSDK中的一个工具,可以直接在命令行操作OSS。获取的地址为PythonSDK。 osscmd的典型使用方法如下: 下载文件 ./osscmd get oss://BUCKET/OBJECT LOCALFILE --host=Endpoint -i AccessKeyId -k AccessKeySecret 这里的BUCKET和OBJECT替换成自己的,Endpoint的格式类似oss-cn-hangzhou.aliyuncs.com。AccessKeyId和AccessKeySecret使用自己账号对应的 上传文件 ./osscmd put LOCALFILE oss://BUCKET/OBJECT --host=Endpoint -i AccessKeyId -k AccessKeySecret 各个字段含义和下载一致
2019-12-01 23:13:31 0 浏览量 回答数 0

回答

《操作系统》课程设计报告课程设计题目:操作系统课程设计 设计时间:2016/1/10一、 课程设计目的与要求需要完成的内容:(1) 安装虚拟机:Vmware、Vmware palyer (free)(推荐)、Virtualbox(推荐)、VMLite、Xen、Virtuozzo、KVM(2) 安装和使用Linux(推荐SUSE)(注意包含内核源码和内核开发工具等)(3) Linux内核源代码配置和重编(4) 找到VFS和一个具体文件系统的源代码(ext3或ext4)(5) 读懂VFS和具体文件系统如何关联(如何体现virtual file switch)(6) 找到具体文件系统的read或write函数,使用printk(使用方法和printf一样)向后台打印文件读写信息。(read或write函数选一个即可)(7) 使用dmesg –c查看后台的输出。可以附加的功能(8) 复制ext3或ext4的源代码(注意与当前使用的文件系统有区别),修改Makefile文件,使用模块编译方式(9) 修改ext3或ext4的源代码,实现新的文件系统。(至少需要修改文件系统的名称,最好能对文件写操作向系统后台打印出信息。)(10) 动态加载和卸载新的文件系统。二、 课程设计内容(1) 安装虚拟机(2) 安装和使用Linux(3) Linux内核源代码配置和重编(4) 提取并动态加载和卸载新的文件系统三、 课程设计设备与环境设备信息:PC 虚拟机:VM11 四、 设计正文(包括分析与设计思路、各模块流程图、带注释的主要算法源码、内核编译过程以及动态模块加载过程等,如有改进或者拓展,请重点用一小节进行说明)(1) 安装虚拟机(2) 安装和使用Linux(推荐SUSE)(注意包含内核源码和内核开发工具等)安装OpenSUSE,并下载相近版本的内核源码 初始内核版本 下载的源代码包 (3) Linux内核源代码配置和重编利用vmtools(虚拟机提供的可以在宿主机和虚拟机之间自由复制文件的工具)将内核源码包复制进虚拟机,解压到/home/a123/linux-3.12.51 *因为分配的磁盘空间比较小,所以没有按照惯例把内核源码放在/usr/src目录下(如果放在这里,会出现空间不足的情况)附:磁盘分配情况/swap(交换分区) 2.4G/(根目录) 11G/home(用户目录) 13G 解压好的内核源码文件在编译前需要稍作修改(6),并且缺乏一个config文件告诉编译器编译哪些功能。Config文件可以用make menuconfig命令生成,但是需要自己选择相应的功能,太过复杂,这里有一个简便的方法因为下载的内核源码是相近的版本,所以可以使用现有版本的config文件,该文件在/boot目录下使用cp /boot/config-3.11.6-4-desktop .config命令将此文件复制过来 注意:应当在内核所在的文件目录下使用此命令复制成功 执行 make menuconfig命令,进入选择界面,直接保存退出即可虽然新版本的Linux可以直接执行make一步完成所有的编译工作,但此次课程设计仍然采用以前的编译的方式 执行 make bzImage命令——编译压缩的内核编译完成 执行 make modules命令——编译模块 执行 make modules_install命令——安装模块 注: 在make menuconfig时我在General setup中把版本号改过 执行 make install命令——安装新内核 Reboot重启 说明内核修改安装完毕,成功(4) 找到VFS和一个具体文件系统的源代码(ext3或ext4)VFS:虚拟文件系统,顾名思义。它为应用程序员提供一层抽象,屏蔽底层各种文件系统的差异。Linux的文件系统采用面向对象的方式设计,这使得Linux的文件系统非常容易扩展,我们可以非常容易将一个新的文件系统添加到Linux中。在此主要对象之一super_block位于中 代码量巨大,此为部分代码Ext4在fs文件夹下的ext4文件夹内 此处打开file.c用vim打开file.c部分代码如下 (5) 读懂VFS和具体文件系统如何关联(如何体现virtual file switch)在(4)中已经提到,VFS是C语言写的一个面向对象的设计,比如我们要调用alloc_inode方法:sb->s_op->alloc_inode(sb)。这里与面向对象语言的差别是,面向对象语言里实例方法可以访问到this,这样就可以访问到自身的所有成员,但是在C里却做不到,所以需要将自身作为参数传入到函数中、图一表示了对文件写操作的调用过程 (6) 找到具体文件系统的read或write函数,使用printk(使用方法和printf一样)向后台打印文件读写信息。(read或write函数选一个即可)因为Linux系统对文件的操作是通过函数调用来实现的,所以在此我修改的是vfs这一层,找到fs,目录下的read_write.c并打开找到do_sync_read函数,在其返回前加入printk语句 (7) 使用dmesg –c查看后台的输出。 (8) 复制ext3或ext4的源代码(注意与当前使用的文件系统有区别),修改Makefile文件,使用模块编译方式 (9) 修改ext3或ext4的源代码,实现新的文件系统。(至少需要修改文件系统的名称,最好能对文件写操作向系统后台打印出信息。) 使其在加载和卸载的时候能够printk到buffer缓冲中(10) 动态加载和卸载新的文件系统。使用insmod语句加载使用lsmod语句加载 加载成功接下来使用dmesg 查看缓冲区内容 成功接下来使用rmmod语句卸载模块 成功五、 课程设计结果及分析课程设计结果:成功分析:Linux文件系统使用了面向对象的设计方法,保证了其对用户的透明,VFS层实现了系统与文件系统的无关性,增加了系统对不同文件系统的兼容性。六、 总结与进一步改进设想总结:1.编译内核的时候,可以使用make XXX –j8这样可以开启多线程编译(我的虚拟机分配的是8核心),加快编译速度2.printk语句我写的是printk(”””DoingRead”);本意是利用printk的优先级,将其输出到用户态的控制台,结果语法错误,并没有输出到控制台改进设想:修改的文件前加上语句,实现对控制台的输出 define KERN_EMERG 0(因为缺少这个宏,导致系统并没有理解我的0是什么意思) 七、 答辩(或汇报)记录(包括问题和答案,每个人不少于3个) 显示内核版本 使用dmesg –c命令 加载新模块 八、 参考文献 鸟哥的Linux私房菜 百度百科:printk概述http://baike.baidu.com/link?url=Kv5e2xb9thGENkIvSQmjpkYb8kbKoNvEhmt2oICTmDAn0wj2YADVf8dsrzBtz2fRt0uwa_3joQ-o40wKwwL68a Linux虚拟文件系统(VFS)http://www.cnblogs.com/yuyijq/archive/2013/02/24/2923855.html LinuxEXT4文件系统分析http://wenku.baidu.com/link?url=Wi-vyrROUIJqRk4eSsuwOwRe0Sf-ydXamWNR0H2HCrN9CPHJg80lXpu0Gi_ZGT-X5yKnknl86ooHdckHhJxybmyBR2szWsPDOV0IPJ6fJXO
杨冬芳 2019-12-02 03:10:35 0 浏览量 回答数 0

问题

如何保证缓存与数据库的双写一致性?【Java问答】38期

面试题 如何保证缓存与数据库的双写一致性? 面试官心理分析 你只要用缓存,就可能会涉及到缓存与数据库双存储双写,你只要是双写,就一定会有数据一致性的问题,那么你如何解...
剑曼红尘 2020-06-16 12:58:57 36 浏览量 回答数 1

回答

任何虚拟化都有一定的性能损失,和物理主机媲美纯属扯淡。系统都可以虚拟,针对数据测试做个优化还不简单。hd tune的测试与硬件有关系,如果系统做了虚拟化转换,测试的结果并不准确,这点在盛大的论坛已经有多个截图论证。那些数字很高的数据,几乎清一色来自hd tune,为什么不测试linux下的系统命令,以及win下的实际拷贝速度呢?有很多不需要删除硬盘就能测试速度的软件为什么不用? 还有,硬盘写入速度假设为10Mb/s,这个数据很低了吧,要匹配这个瓶颈,需要极其苛刻的条件:80M的带宽,满负载运作,并且全部请求都是写入请求,请问到了这个级别,还有人用虚拟系统? 硬盘只是众多指标中的一个,CPU、内存、硬盘、带宽需要均衡配置,一个386机器配一个gtx680d显卡又如何? ------------------------- 回 2楼(cmsns) 的帖子 这个只是假设,大部分的请求是不需要写入的,对硬盘读的要求更高,大部分云主机、VPS都是读的速度大大高于写速度,所以我单独列出了写速度,将之作为瓶颈。 你说的打开很多个数据表,这些只是对读速度有很高的要求,而写入的速度,比如你注册一个账号,比如提交一个评论,上传一个头像,这些本来相对于打开网页的概率就小很多,一般而言,一个网站的访问,有10%的写入请求,就算是很高了,而且写入请求也很少涉及多个表同时写入的情况。还有,你一个写入或者读取的请求打开几个表,已经是很多了,如果打开几十个,你的软件架构是不是有问题? 另外我们计算的都是极端情况,没有考虑内存缓存,没有考虑队列。比如你同时有30000个写入请求,超出写入带宽,那么可能有15000个写入请求会停顿延迟一秒,这并不是什么不可接受的情况,而且这种情形现实应用中不会发生。 还有自动备份,一般而言,备份如果是在一个硬盘上,你设置的频率不会很高,因为这种备份没有意义,如果这个盘挂了,你的原数据和备份都会挂掉。自动备份在两个以上数据盘才有意义,那么两个数据盘,读写带宽就都是独立的,不存在你说的备份会影响带宽。 注意,我讨论的假设前提是现在大部分云主机、vps读速度大大高于写入速度的现状,而且对写入带宽取了较低的值,对应用场景也都采取了极端负面假设,甚至使用了很多在大型网站上才会发生的情况做假设,这些极端同时发生的情况是不会存在的。 ------------------------- 在我的论坛里也有一些关于linkcloud的讨论,有人说好,说人说不好,而且都很极端。要说服务,我想阿里的服务应该是我目前用过最好的,晚上十点多提交工单,十几分钟回复,主要的是解决了问题。我这样还算是linux老手,用了多年的,也会犯些低级错误。在盛大我感觉也挺不错,就是官方马甲多,让人厌烦,好在最近消停了不少,盛大的品质也在上升中,当然,原来盛大的品质就还不错。以前我比较讨厌西部数码,尤其是转域名的事,后来发现国内转域名都那样,错怪别人了。现在论坛 放在西部数码上,感觉很不错。最近考虑把服务器转移到阿里云,就是百度收录不稳定,而且备案麻烦,耽误了。
tftaxis 2019-12-02 03:14:06 0 浏览量 回答数 0

回答

首先,我们先来聊聊各类数据模型。下列相关信息参考自Emil Eifrem的博文及NoSQL数据库说明。文档类数据库传承:受Lotus Notes启发而来。数据模型:文档汇总,包括键-值汇总。实例: CouchDB, MongoDB优势: 数据建模自然、程序员易于上手、开发流程短、兼容网页模式、便于达成CRUD(即添加、查询、更新及删除的简称)。图形类数据库传承:来自 Euler 及图形理论。数据模型:节点及关系,二者结合能够保持键-值间的成对状态实例: AllegroGraph, InfoGrid, Neo4j优势:轻松玩转复杂的图形问题、处理速度快关系类数据库传承:源自 E. F. Codd在大型共享数据库中所提出的数据关系模型理论数据模型:以关系组为基础实例: VoltDB, Clustrix, MySQL优势:性能强大、联机事务处理系统扩展性好、支持SQL访问、视图直观、擅长处理交易关系、与程序员间的交互效果优异面向对象类数据库传承:源自图形数据库方面的研究成果数据模型: 对象实例: Objectivity, Gemstone优势:擅长处理复杂的对象模型、快速的键-值访问及键-功能访问并且兼具图形数据库的各类功能键-值存储传承: Amazon Dynamo中的paper概念及分布式hash表数据模型:对成对键-值的全局化汇总实例: Membase, Riak优势:尺寸掌控得当、擅长处理持续的小规模读写需求、速度快、程序员易于上手BigTable Clones传承自:谷歌BigTable中的paper概念数据模型:纵列群,即在某个表格模型中,每行在理论上至少可以有一套单独的纵列配置实例: HBase, Hypertable, Cassandra优势:尺寸掌控得当、擅长应对大规模写入负载、可用性高、支持多数据中心、支持映射简化数据结构类服务传承: 不明实例: Redis数据模型: 执行过程基于索引、列表、集合及字符串值优势:为数据库应用引入前所未有的新鲜血液网格类数据库传承:源自数据网格及元组空间研究数据模型:基于空间的构架实例: GigaSpaces, Coherence优势:优良的性能表现及上佳的交易处理扩展性我们该为自己的应用程序选择哪套方案?选择的关键在于重新思考我们的应用程序如何依据不同数据模型及不同产品进行有针对性的协同工作。即用正确的数据模型处理对应的现实任务、用正确的产品解决对应的现实问题。要探究哪类数据模型能够切实为我们的应用程序提供帮助,可以参考“到底NoSQL能在我们的工作中发挥什么作用?”一文。在这篇文章中,我试着将各种不同特性、不同功能的常用创建系统中的那些非常规的应用实例综合起来。将应用实例中的客观需求与我们的选择联系起来。这样大家就能够逆向分析出我们的基础架构中适合引入哪些产品。至于具体结论是NoSQL还是SQL,这已经不重要了。关注数据模型、产品特性以及自身需要。产品总是将各种不同的功能集中起来,因此我们很难单纯从某一类数据模型构成方式的角度直接找到最合用的那款。对功能及特性的需求存在优先级,只要对这种优先级具备较为清晰的了解,我们就能够做出最佳选择。如果我们的应用程序需要…复杂的交易:因为没人愿意承受数据丢失,或者大家更倾向于一套简单易用的交易编程模式,那么请考虑使用关系类或网格类数据库。例如:一套库存系统可能需要完整的ACID(即数据库事务执行四要素:原子性、一致性、隔离性及持久性)。顾客选中了一件产品却被告知没有库存了,这类情况显然容易引起麻烦。因为大多数时候,我们想要的并不是额外补偿、而只是选中的那件货品。若是以扩展性为优先,那么NoSQL或SQL都能应对自如。这种情况下我们需要关注那些支持向外扩展、分类处理、实时添加及移除设备、负载平衡、自动分类及整理并且容错率较高的系统。要求持续保有数据库写入功能,则需要较高的可用性。在这种情况下不妨关注BigTable类产品,其在一致性方面表现出众。如有大量的小规模持续读写要求,也就是说工作负载处于波动状态,可以关注文档类、键-值类或是那些提供快速内存访问功能的数据库。引入固态硬盘作为存储媒介也是不错的选择。以社交网络为实施重点的话,我们首先想到的就是图形类数据库;其次则是Riak这种关系类数据库。具备简单SQL功能的常驻内存式关系数据库基本上就可以满足小型数据集合的需求。Redis的集合及列表操作也能发挥作用。如果我们的应用程序需要…在访问模式及数据类型多种多样的情况下,文档类数据库比较值得考虑。这类数据库不仅灵活性好,性能表现也可圈可点。需要完备的脱机报告与大型数据集的话,首选产品是Hadoop,其次则是支持映射简化的其它产品。不过仅仅支持映射简化还不足以提供如Hadoop一样上佳的处理能力。如果业务跨越数个数据中心,Bigtable Clone及其它提供分布式选项的产品能够应对由地域距离引起的延迟现象,并具备较好的分区兼容性。要建立CRUD应用程序,首选文档类数据库。这类产品简化了从外部访问复杂数据的过程。需要内置搜索功能的话,推荐Riak。要对数据结构中的诸如列表、集合、队列及发布/订阅信息进行操作,Redis是不二之选。其具备的分布式锁定、覆盖式日志及其它各种功能都会在这类应用状态下大放异彩。将数据以便于处理的形式反馈给程序员(例如以JSON、HTTP、REST、Javascript这类形式),文档类数据库能够满足这类诉求,键-值类数据库效果次之。如果我们的应用程序需要…以直观视图的形式进行同步交易,并且具备实时数据反馈功能,VoltDB算得上一把好手。其数据汇总以及时间窗口化的表现都非常抢眼。若是需要企业级的支持及服务水平协议,我们需要着眼于特殊市场。Membase就是这样一个例子。要记录持续的数据流,却找不到必要的一致性保障?BigTable Clone交出了令人满意的答卷,因为其工作基于分布式文件系统,所以可以应对大量的写入操作。要让操作过程变得尽可能简单,答案一定在托管或平台即服务类方案之中。它们存在的目的正是处理这类要求。要向企业级客户做出推荐?不妨考虑关系类数据库,因为它们的长项就是具备解决繁杂关系问题的技术。如果需要利用动态方式建立对象之间的关系以使其具有动态特性,图形类数据库能帮上大忙。这类产品往往不需要特定的模式及模型,因此可以通过编程逐步建立。S3这类存储服务则是为支持大型媒体信息而生。相比之下NoSQL系统则往往无法处理大型二进制数据块,尽管MongoDB本身具备文件服务功能。如果我们的应用程序需要…有高效批量上传大量数据的需求?我们还是得找点有对应功能的产品。大多数产品都无法胜任,因为它们不支持批量操作。文档类数据库或是键-值类数据库能够利用流畅的模式化系统提供便捷的上传途径,因为这两类产品不仅支持可选区域、添加区域及删除区域,而且无需建立完整的模式迁移框架。要实现完整性限制,就得选择一款支持SQL DLL的产品,并在存储过程或是应用程序代码中加以运行。对于协同工作极为依赖的时候就要选择图形类数据库,因为这类产品支持在不同实体间的迅速切换。数据的移动距离较短且不必经过网络时,可以在预存程序中做出选择。预存程序在关系类、网格类、文档类甚至是键-值类数据库中都能找到。如果我们的应用程序需要…键-值存储体系擅长处理BLOB类数据的缓存及存储问题。缓存可以用于应对网页或复杂对象的存储,这种方案能够降低延迟、并且比起使用关系类数据库来说成本也较低。对于数据安全及工作状态要求较高的话可以尝试使用定制产品,并且在普遍的工作范畴(例如向上扩展、调整、分布式缓存、分区及反规范化等等)之外一定要为扩展性(或其它方面)准备解决方案。多样化的数据类型意味着我们的数据不能简单用表格来管理或是用纵列来划分,其复杂的结构及用户组成(也可能还有其它各种因素)只有文档类、键-值类以及Bigtable Clone这些数据库才能应付。上述各类数据库都具备极为灵活的数据类型处理能力。有时其它业务部门会需要进行快速关系查询,引入这种查询方式可以使我们不必为了偶尔的查看而重建一切信息。任何支持SQL的数据库都能实现这类查询。至于在云平台上运行并自动充分利用云平台的功能——这种美好的愿望目前还只能是愿望。如果我们的应用程序需要…支持辅助索引,以便通过不同的关键词查找数据,这要由关系类数据库及Cassandra推出的新辅助索引系统共同支持才能实现。创建一套处于不断增长中的数据集合(真正天文数量级的数据)然而访问量却并不大,那么Bigtable Clone是最佳选择,因为它会将数据妥善安排在分布式文件系统当中。需要整合其它类型的服务并确保数据库提供延后写入同步功能?那最好的实现方式是捕捉数据库的各种变化并将其反馈到其它系统中以保障运作的一致性。通过容错性检查了解系统对供电中断、隔离及其它故障情况的适应程度。若是当前的某项技术尚无人问津、自己却感觉大有潜力可挖,不妨在这条路上坚持走下去。这种情况有时会带来意料之外的美好前景。尝试在移动平台上工作并关注CouchDB及移动版couchbase。哪种方案更好?25%的状态改善尚不足以让我们下决心选择NoSQL。选择标准是否恰当取决于实际情况。这类标准对你的方案有指导意义吗?如果你的公司尚处于起步阶段,并且需要尽快推出自己的产品,这时不要再犹豫不决了。无论是SQL还是NoSQL都可以作为参考。
a123456678 2019-12-02 03:00:14 0 浏览量 回答数 0

问题

HBase最佳实践-读性能优化策略

转载自:http://www.hbase.group/article/32 任何系统都会有各种各样的问题,有些是系统本身设计问题,有些却是使用姿势问题。HBase也一样,在真实生产线...
pandacats 2019-12-20 21:02:08 0 浏览量 回答数 0

回答

面试题 redis 都有哪些数据类型?分别在哪些场景下使用比较合适? 面试官心理分析 除非是面试官感觉看你简历,是工作 3 年以内的比较初级的同学,可能对技术没有很深入的研究,面试官才会问这类问题。否则,在宝贵的面试时间里,面试官实在不想多问。 其实问这个问题,主要有两个原因: 看看你到底有没有全面的了解 redis 有哪些功能,一般怎么来用,啥场景用什么,就怕你别就会最简单的 KV 操作; 看看你在实际项目里都怎么玩儿过 redis。 要是你回答的不好,没说出几种数据类型,也没说什么场景,你完了,面试官对你印象肯定不好,觉得你平时就是做个简单的 set 和 get。 面试题剖析 redis 主要有以下几种数据类型: stringhashlistsetsorted set string 这是最简单的类型,就是普通的 set 和 get,做简单的 KV 缓存。 set college szu hash 这个是类似 map 的一种结构,这个一般就是可以将结构化的数据,比如一个对象(前提是这个对象没嵌套其他的对象)给缓存在 redis 里,然后每次读写缓存的时候,可以就操作 hash 里的某个字段。 hset person name bingo hset person age 20 hset person id 1 hget person name person = { "name": "bingo", "age": 20, "id": 1 } list list 是有序列表,这个可以玩儿出很多花样。 比如可以通过 list 存储一些列表型的数据结构,类似粉丝列表、文章的评论列表之类的东西。 比如可以通过 lrange 命令,读取某个闭区间内的元素,可以基于 list 实现分页查询,这个是很棒的一个功能,基于 redis 实现简单的高性能分页,可以做类似微博那种下拉不断分页的东西,性能高,就一页一页走。 0开始位置,-1结束位置,结束位置为-1时,表示列表的最后一个位置,即查看所有。 lrange mylist 0 -1 比如可以搞个简单的消息队列,从 list 头怼进去,从 list 尾巴那里弄出来。 lpush mylist 1 lpush mylist 2 lpush mylist 3 4 5 #1 rpop mylist set set 是无序集合,自动去重。 直接基于 set 将系统里需要去重的数据扔进去,自动就给去重了,如果你需要对一些数据进行快速的全局去重,你当然也可以基于 jvm 内存里的 HashSet 进行去重,但是如果你的某个系统部署在多台机器上呢?得基于 redis 进行全局的 set 去重。 可以基于 set 玩儿交集、并集、差集的操作,比如交集吧,可以把两个人的粉丝列表整一个交集,看看俩人的共同好友是谁?对吧。 把两个大 V 的粉丝都放在两个 set 中,对两个 set 做交集。 往期回顾: 【Java问答学堂】1期 为什么使用消息队列?消息队列有什么优点和缺点?Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别,以及适合哪些场景? 【Java问答学堂】2期 如何保证消息队列的高可用? 【Java问答学堂】3期 如何保证消息不被重复消费?或者说,如何保证消息消费的幂等性? 【Java问答学堂】4期 如何保证消息的可靠性传输?(如何处理消息丢失的问题?) 【Java问答学堂】5期 如何保证消息的顺序性? 【Java问答学堂】6期 如何解决消息队列的延时以及过期失效问题? 【Java问答学堂】7期 如果让你写一个消息队列,该如何进行架构设计? 【Java问答学堂】8期 es 的分布式架构原理能说一下么(es 是如何实现分布式的啊)? 【Java问答学堂】9期 es 写入数据的工作原理是什么啊?es 查询数据的工作原理是什么啊? 【Java问答学堂】10期 es 在数据量很大的情况下(数十亿级别)如何提高查询效率啊? 【Java问答学堂】11期 es 生产集群的部署架构是什么?每个索引的数据量大概有多少? 【Java问答学堂】12期 项目中缓存是如何使用的?为什么要用缓存?缓存使用不当会造成什么后果? 【Java问答学堂】13期 redis 和 memcached 有什么区别?
剑曼红尘 2020-05-07 15:00:02 0 浏览量 回答数 0

问题

【Java问答学堂】14期 redis 都有哪些数据类型?分别在哪些场景下使用比较合适?

面试题 redis 都有哪些数据类型?分别在哪些场景下使用比较合适? 面试官心理分析 除非是面试官感觉看你简历,是工作 3 年以内的比较初级的同学,可能对技术没有很深入的研究&#...
剑曼红尘 2020-05-07 14:59:45 0 浏览量 回答数 1

问题

【算法】五分钟算法小知识:Linux的进程、线程、文件描述符是什么?

说到进程,恐怕面试中最常见的问题就是线程和进程的关系了,那么先说一下答案:在 Linux 系统中,进程和线程几乎没有区别。 Linux 中的进程其实就是一个数据结构,顺...
游客ih62co2qqq5ww 2020-05-09 11:28:57 0 浏览量 回答数 0

回答

转自:阿飞的博客 一、数据库技术选型的思考维度 我们做选型的时候首先要问: 谁选型?是负责采购的同学、 DBA 还是业务研发? 如果选型的是采购的同学,他们更注重成本,包括存储方式、网络需求等。 如果选型的是 DBA 同学,他们关心的: ① 运维成本 首先是运维成本,包括监控告警是否完善、是否有备份恢复机制、升级和迁移的成本是否高、社区是否稳定、是否方便调优、排障是否简易等; ② 稳定性 其次,DBA会关注稳定性,包括是否支持数据多副本、服务高可用、多写多活等; ③ 性能 第三是性能,包括延迟、QPS 以及是否支持更高级的分级存储功能等; ④ 拓展性 第四是扩展性,如果业务的需求不确定,是否容易横向扩展和纵向扩容; ⑤ 安全 最后是安全,需要符合审计要求,不容易出现 SQL 注入或拖库情况。 ⑥ 其他 除了采购和 DBA之外,后台应用研发的同学同样会关注稳定性、性能、扩展性等问题,同时也非常关注数据库接口是否便于开发,是否便于修改数据库 schema 等问题。 接下来我们来看一下爱奇艺使用的数据库类型: MySQL,互联网业务必备系统; TiDB,爱奇艺的 TiDB 实践会有另外的具体介绍; Redis,KV 数据库,互联网公司标配; Couchbase,这个在爱奇艺用得比较多,但国内互联网公司用得比较少,接下来的部分会详细说明; 其他,比如 MongoDB、图数据库、自研 KV 数据库 HiKV 等; 大数据分析相关系统,比如 Hive、Impala 等等。 可以看到爱奇艺的数据库种类还是很多的,这会造成业务开发的同学可能不太清楚在他的业务场景下应该选用哪种数据库系统。 那么,我们先对这些数据库按照接口(SQL、NoSQL)和面向的业务场景(OLTP、OLAP)这两位维度进行一个简单非严谨的分类。 下图中,左上角是面向 OLTP、支持 SQL 的这样一类系统,例如 MySQL,一般支持事务不同的隔离级别, QPS 要求比较高,延时比较低,主要用于交易信息和关键数据的存储,比如订单、VIP 信息等。 左下角是 NoSQL 数据库,是一类针对特殊场景做优化的系统,schema 一般比较简单,吞吐量较高、延迟较低,一般用作缓存或者 KV 数据库。 整个右侧都是 OLAP 的大数据分析系统,包括 Clickhouse、Impala等,一般支持SQL、不支持事务,扩展性比较好,可以通过加机器增加数据的存储量,响应延迟较长。 还有一类数据库是比较中立的,在数据量比较小的时候性能比较好,在数据量较大或复杂查询的时候性能也不差,一般通过不同的存储引擎和查询引擎来满足不同的业务需求,我们把它叫做 HTAP,TiDB 就是这样一种数据库。 二、iQIYI对数据库的优化与完善 前面我们提到了很多种的数据库,那么接下来就和大家介绍一下在爱奇艺我们是怎么使用这些数据库的。 1、MySQL在爱奇艺的使用 ① MySQL 首先是 MySQL。MySQL 基本使用方式是 master-slave + 半同步,支持每周全备+每日增量备份。我们做了一些基本功能的增强,首先是增强了数据恢复工具 Xtrabackup 的性能。 之前遇到一个情况,我们有一个全量库是 300G 数据,增量库每天 70G 数据,总数据量 700G 左右。我们当时只需要恢复一个表的数据,但该工具不支持单表恢复,且整库恢复需要 5 个小时。 针对这个情况我们具体排查了原因,发现在数据恢复的过程中需要进行多次写盘的 IO 操作并且有很多串行操作,所以我们做了一些优化。例如删减过程中的一些写盘操作,减少落盘并将数据处理并行化,优化后整库恢复耗时减少到 100 分钟,而且可以直接恢复单表数据。 然后是适配 DDL 和 DML 工具到内部系统,gh-ostt 和 oak-online-alter-table 在数据量大的时候会造成 master-slave 延时,所以我们在使用工具的时候也增加了延时上的考虑,实时探测Master-Slave 库之间延时的情况,如果延时较大会暂停工具的使用,恢复到正常水平再继续。 ② MySQL高可用 第二是 MySQL 高可用。Master-slave 加上半同步这种高可用方式不太完善,所以我们参照了 MHA 并进行了改动,采用 master + agent 的方式。Agent 在每一个物理机上部署,可以监控这个物理机上的所有实例的状态,周期性地向 master 发送心跳,Master 会实时监测各个Agent的状态。 如果 MySQL故障,会启动 Binlog 补偿机制,并切换访问域名完成 failover。考虑到数据库跨机房跨地区部署的情况,MHA 的 master 我们也做了高可用设计,众多 master 会通过 raft 组成一个 raft group,类似 TiDB 的 PD 模块。目前 MySQL failover 策略支持三种方式:同机房、同地域跨机房以及跨地域。 ③ MySQL拓展能力 第三是提高MySQL扩展能力,以提供更大容量的数据存储。扩展方式有 SDK,例如开源的 ShardingSphere,在爱奇艺的使用也比较广泛。另外就是 Proxy,开源的就更多了。但是 SDK 和 Proxy 使用的问题是支持的 SQL 语句简单,扩容难度大,依赖较多且运维复杂,所以部分业务已经迁移至 TiDB。 ④ 审计 第四是审计。我们在 MySQL 上做了一个插件获取全量 SQL 操作,后端打到 Kafka,下游再接入包括 Clickhouse 等目标端进行 SQL 统计分析。除此之外还有安全策略,包括主动探索是否有 SQL 注入及是否存在拖库情况等,并触发对应的告警。 MySQL 审计插件最大的问题是如何降低对 MySQL 性能的影响,对此我们进行了一些测试,发现使用 General Log 对性能损耗较大,有 10%~20% 的降低。 于是我们通过接口来获取 MySQL 插件里的监控项,再把监控项放到 buffer 里边,用两级的 RingBuffer 来保证数据的写入不会有锁资源竞争。在这个插件里再启动一个线程,从 RingBuffer 里读取数据并把数据打包写到 FIFO 管道里。 我们在每台 MySQL 的物理机里再启动一个 Agent,从管道里阻塞地读取数据发至 Kafka。优化后我们再次进行压测,在每台机器上有 15 万的更新、删除或插入操作下不会丢失数据,性能损耗一般情况下小于 2%。 目前已经在公司内部的集群上线了一年时间,运行比较稳定,上线和下线对业务没有影响。 ⑤ 分级存储 第五是分级存储。MySQL 里会存一些过程性的数据,即只需要读写最近一段时间存入的数据,过段时间这些数据就不需要了,需要进行定时清理。 分级存储就是在 MySQL 之上又用了其他存储方式,例如 TiDB 或其他 TokuDB,两者之间可以进行数据自动搬迁和自动归档,同时前端通过 SDK + Proxy 来做统一的访问入口。这样一来,业务的开发同学只需要将数据存入 MySQL 里,读取时可能从后端接入的任意数据库读出。这种方式目前只是过渡使用,之后会根据 TiDB 的特性进行逐步迁移。 Redis在爱奇艺的使用 接下来是 Redis。Redis 也是使用 master - slave 这种方式,由于网络的复杂性我们对 Sentinel 的部署进行了一些特殊配置,在多机房的情况下每个机房配置一定数量 Sentinel 来避免脑裂。 备份恢复方面介绍一个我们的特殊场景,虽然 Redis 是一个缓存,但我们发现不少的业务同学会把它当做一个 KVDB 来使用,在某些情况下会造成数据的丢失。 所以我们做了一个 Redis 实时备份功能,启动一个进程伪装成 Redis 的 Slave 实时获取数据,再放到后端的 KV 存储里,例如 ScyllaDB,如果要恢复就可以从 ScyllaDB 里把数据拉出来。 我们在用 Redis 时最大的痛点就是它对网络的延迟或抖动非常敏感。如有抖动造成 Redis Master 超时,会由 Sentinel 重新选出一个新的节点成为 Master,再把该节点上的数据同步到所有 Slave 上,此过程中数据会放在 Master 节点的 Buffer 里,如果写入的 QPS 很高会造成 Buffer 满溢。如果 Buffer 满后 RDB 文件还没有拷贝过去,重建过程就会失败。 基于这种情况,我们对 Redis 告警做了自动化优化,如有大量 master - slave 重建失败,我们会动态调整一些参数,例如把 Buffer 临时调大等, 此外我们还做了 Redis 集群的自动扩缩容功能。 我们在做 Redis 开发时如果是 Java 语言都会用到 Jedis。用 Jedis 访问客户端分片的 Redis 集群,如果某个分片发生了故障或者 failover,Jedis 就会对所有后端的分片重建连接。如果某一分片发生问题,整个 Redis 的访问性能和 QPS 会大幅降低。针对这个情况我们优化了 Jedis,如果某个分片发生故障,就只针对这个分片进行重建。 在业务访问 Redis 时我们会对 Master 绑定一个读写域名,多个从库绑定读域名。但如果我们进行 Master failover,会将读写域名从某旧 Master 解绑,再绑定到新 Master 节点上。 DNS 本身有一个超时时间,所以数据库做完 failover 后业务程序里没有立刻获取到新的 Master 节点的 IP的话,有可能还会连到原来的机器上,造成访问失败。 我们的解决方法是把 DNS 的 TTL 缩短,但对 DNS 服务又会造成很大的压力,所以我们在 SDK 上提供 Redis 的名字服务 RNS,RNS 从 Sentinel 里获取集群的拓扑和拓扑的变化情况,如果集群 failover,Sentinel 会接到通知,客户端就可以通过 RNS 来获取新的 Master 节点的 IP 地址。我们去掉域名,通过 IP 地址来访问整个集群,屏蔽了 DNS 的超时,缩短了故障的恢复时间。 SDK 上还做了一些功能,例如 Load Balance 以及故障检测,比如某个节点延时较高的话会被临时熔断等。 客户端分片的方式会造成 Redis 的扩容非常痛苦,如果客户端已经进行了一定量的分片,之后再增加就会非常艰难。 Redis 在 3.0 版本后会提供 Redis Cluster,因为功能受限在爱奇艺应用的不是很多,例如不支持显示跨 DC 部署和访问,读写只在主库上等。 我们某些业务场景下会使用 Redis 集群,例如数据库访问只发生在本 DC,我们会在 DC 内部进行 Cluster 部署。 但有些业务在使用的过程中还是想做 failover,如果集群故障可以切换到其他集群。根据这种情况我们做了一个 Proxy,读写都通过它来进行。写入数据时 Proxy 会做一个旁路,把新增的数据写在 Kafka 里,后台启用同步程序再把 Kafka 里的数据同步到其他集群,但存在一些限制,比如我们没有做冲突检测,所以集群间数据需要业务的同学做单元化。线上环境的Redis Cluster 集群间场景跨 DC 同步 需要 50 毫秒左右的时间。 2、Couchbase在爱奇艺的使用 Redis 虽然提供 Cluster 这种部署方式,但存在一些问题。所以数据量较大的时候(经验是 160G),就不推荐 Redis 了,而是采用另一种存储方式 Couchbase。 Couchbase 在国内互联网公司用的比较少,一开始我们是把他当做一个 Memcached 来使用的,即纯粹的缓存系统。 但其实它性能还是比较强大的,是一个分布式高性能的 KV 系统,支持多种存储引擎 (bucket)。第一种是 Memcached bucket,使用方式和 Memcached 一样为 KV 存储,不支持数据持久化也没有数据副本,如果节点故障会丢失数据; 第二种是 Couchbase bucket,支持数据持久化,使用 Json 写入,有副本,我们一般会在线上配置两个副本,如果新加节点会对数据进行 rebalance,爱奇艺使用的一般是 Couchbase bucket 这种配置。 Couchbase 数据的分布如下图,数据写入时在客户端上会先进行一次哈希运算,运算完后会定位 Key 在哪一个 vBucket (相当于数据库里的某个分片)。之后客户端会根据 Cluster Map 发送信息至对应的服务端,客户端的 Cluster Map 保存的是 vBucket 和服务器的映射关系,在服务端数据迁移的过程中客户端的 Cluster Map 映射关系会动态更新,因此客户端对于服务端的 failover 操作不需要做特殊处理,但可能在 rebalance 过程中会有短暂的超时,导致的告警对业务影响不大。 Couchbase 在爱奇艺应用比较早,2012 年还没有 Redis Cluster 的时候就开始使用了。集群管理使用 erlang 语言开发,最大功能是进行集群间的复制,提供多种复制方式:单向、双向、星型、环式、链式等。 爱奇艺从最初的 1.8 版本使用到如今的 5.0 版本,正在调研的 6.0,中间也遇到了很多坑,例如 NTP 时间配置出错会导致崩溃,如果每个集群对外 XDCR 并发过高导致不稳定,同步方向变更会导致数据丢失等等,我们通过运维和一些外部工具来进行规避。 Couchbase 的集群是独立集群,集群间的数据同步通过 XDCR,我们一般配置为双向同步。对于业务来说,如果 Cluster 1 写入, Cluster 2 不写入,正常情况下客户端会写 Cluster 1。如果 Cluster 1 有故障,我们提供了一个 Java SDK,可以在配置中心把写入更改到 Cluster 2,把原来到 Cluster 1 的连接逐步断掉再与Cluster 2 新建连接。这种集群 failover 的过程对于客户端来说是相对透明和无感的。 3、爱奇艺自研数据库HiKV的使用 Couchbase 虽然性能非常高,并且数据的存储可以超过内存。但是,如果数据量超过内存 75% 这个阈值,性能就会下降地特别快。在爱奇艺,我们会把数据量控制在可用内存的范围之内,当做内存数据库使用。但是它的成本非常高,所以我们后面又开发了一个新的数据库—— HiKV。 开发 HiKV 的目的是为了把一些对性能要求没那么高的 Couchbase 应用迁移到 HiKV 上。HiKV 基于开源系统 ScyllaDB,主要使用了其分布式数据库的管理功能,增加了单机存储引擎 HiKV。 ScyllaDB 比较吸引人的是它宣称性能高于 Cassandra 十倍,又完全兼容 Cassandra 接口,设计基本一致,可以视为 C++ 版 Cassandra 系统。 ScyllaDB 性能的提升主要是使用了一些新的技术框架,例如 C++ 异步框架 seastar,主要原理是在j每台物理机的核上会 attach 一个应用线程,每个核上有自己独立的内存、网络、IO 资源,核与核之间没有数据共享但可以通信,其最大的好处是内存访问无锁,没有冲突过程。 当一个数据读或写到达 ScyllaDB 的 server 时,会按照哈希算法来判断请求的 Key 是否是该线程需要处理的,如果是则本线程处理,否则会转发到对应线程上去。 除此之外,它还支持多副本、多数据中心、多写多活,功能比较强大。 在爱奇艺,我们基于 SSD 做了一个 KV 存储引擎。Key 放在内存里,Value 放在盘上的文件里,我们在读和写文件时,只需要在内存索引里定位,再进行一次盘的 IO 开销就可以把数据读出来,相比 ScyllaDB 原本基于 LSM Tree 的存储引擎方式对 IO 的开销较少。 索引数据全部放在内存中,如果索引长度较长会限制单机可存储的数据量,于是我们通过开发定长的内存分布器,对于比较长的 Key 做摘要缩短长度至 20 字节,采用红黑树索引,限制每条记录在内存里的索引长度至为 64 字节。内存数据要定期做 checkpoint,客户端要做限流、熔断等。 HiKV 目前在爱奇艺应用范围比较大,截至目前已经替换了 30% 的 Couchbase,有效地降低了存储成本。 4、爱奇艺的数据库运维管理 爱奇艺数据库种类较多,如何高效地运维和管理这些数据库也是经历了不同的阶段。 最初我们通过 DBA 写脚本的方式管理,如果脚本出问题就找 DBA,导致了 DBA 特别忙碌。 第二个阶段我们考虑让大家自己去查问题的答案,于是在内部构建了一个私有云,通过 Web 的方式展示数据库运行状态,让业务的同学可以自己去申请集群,一些简单的操作也可以通过自服务平台实现,解放了 DBA。一些需要人工处理的大型运维操作经常会造成一些人为故障,敲错参数造成数据丢失等。 于是在第三个阶段我们把运维操作 Web 化,通过网页点击可以进行 90% 的操作。 第四个阶段让经验丰富的 DBA 把自身经验变成一些工具,比如有业务同学说 MySQL master-slave 延时了,DBA 会通过一系列操作排查问题。现在我们把这些操作串起来形成一套工具,出问题时业务的同学可以自己通过网页上的一键诊断工具去排查,自助进行处理。 除此之外我们还会定期做预警检查,对业务集群里潜在的问题进行预警报告;开发智能客服,回答问题;通过监控的数据对实例打标签,进行削峰填谷地智能调度,提高资源利用率。 三、不同场景下数据库选型建议 1、实用数据库选型树 最后来说一些具体数据库选型建议。这是 DBA 和业务一起,通过经验得出来的一些结论。 对于关系型数据库的选型来说,可以从数据量和扩展性两个维度考虑,再根据数据库有没有冷备、要不要使用 Toku 存储引擎,要不要使用 Proxy 等等进行抉择。 NoSQL 也是什么情况下使用 master-slave,什么情况下使用客户端分片、集群、Couchbase、HiKV 等,我们内部自服务平台上都有这个选型树信息。 2、一些思考 ① 需求 我们在选型时先思考需求,判断需求是否真实。 你可以从数据量、QPS、延时等方面考虑需求,但这些都是真实需求吗?是否可以通过其他方式把这个需求消耗掉,例如在数据量大的情况下可以先做数据编码或者压缩,数据量可能就降下来了。 不要把所有需求都推到数据库层面,它其实是一个兜底的系统。 ② 选择 第二个思考的点是对于某个数据库系统或是某个技术选型我们应该考虑什么?是因为热门吗?还是因为技术上比较先进?但是不是能真正地解决你的问题?如果你数据量不是很大的话就不需要选择可以存储大数据量的系统。 ③ 放弃 第三是放弃,当你放弃一个系统时真的是因为不好用吗?还是没有用好?放弃一个东西很难,但在放弃时最好有一个充分的理由,包括实测的结果。 ④ 自研 第四是自研,在需要自己开发数据库时可以参考和使用一些成熟的产品,但不要盲目自研。 ⑤ 开源 最后是开源,要有拥抱开源的态度。
茶什i 2019-12-27 14:17:56 0 浏览量 回答数 0

回答

在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们战略上 要重 视 它 , 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级?现在很流行的优步(Uber),从媒体公布的信息看,它每天接单量平均在百万左右, 假如每天有10个小时的服务时间,平均QPS只有30左右。对于一个后台服务器,单机的平均QPS可以到达800-1000,单独看写的业务量很简单 。为什么我们又不能说轻视它?第一,我们看它的数据存储,每天一百万的话,一年数据量的规模是多少?其次,刚才说的订单量,每一个订单要推送给附近的司机、司机要并发抢单,后面业务场景的访问量往往是前者的上百倍,轻松就超过上亿级别了。 今天我想从架构的本质谈起之后,希望大家理解在做一些建构设计的时候,它的出发点以及它解决的问题是什么。 架构,刚开始的解释是我从知乎上看到的。什么是架构?有人讲, 说架构并不是一 个很 悬 乎的 东西 , 实际 上就是一个架子 , 放一些 业务 和算法,跟我们的生活中的晾衣架很像。更抽象一点,说架构其 实 是 对 我 们 重复性业务 的抽象和我 们 未来 业务 拓展的前瞻,强调过去的经验和你对整个行业的预见。 我们要想做一个架构的话需要哪些能力?我觉得最重要的是架构师一个最重要的能力就是你要有 战 略分解能力。这个怎么来看呢: 第一,你必须要有抽象的能力,抽象的能力最基本就是去重,去重在整个架构中体现在方方面面,从定义一个函数,到定义一个类,到提供的一个服务,以及模板,背后都是要去重提高可复用率。 第二, 分类能力。做软件需要做对象的解耦,要定义对象的属性和方法,做分布式系统的时候要做服务的拆分和模块化,要定义服务的接口和规范。 第三, 算法(性能),它的价值体现在提升系统的性能,所有性能的提升,最终都会落到CPU,内存,IO和网络这4大块上。 这一页PPT举了一些例子来更深入的理解常见技术背后的架构理念。 第一个例子,在分布式系统我们会做 MySQL分 库 分表,我们要从不同的库和表中读取数据,这样的抽象最直观就是使用模板,因为绝大多数SQL语义是相同的,除了路由到哪个库哪个表,如果不使用Proxy中间件,模板就是性价比最高的方法。 第二看一下加速网络的CDN,它是做速度方面的性能提升,刚才我们也提到从CPU、内存、IO、网络四个方面来考虑,CDN本质上一个是做网络智能调度优化,另一个是多级缓存优化。 第三个看一下服务化,刚才已经提到了,各个大网站转型过程中一定会做服务化,其实它就是做抽象和做服务的拆分。第四个看一下消息队列,本质上还是做分类,只不过不是两个边际清晰的类,而是把两个边际不清晰的子系统通过队列解构并且异步化。新浪微博整体架构是什么样的 接下我们看一下微博整体架构,到一定量级的系统整个架构都会变成三层,客户端包括WEB、安卓和IOS,这里就不说了。接着还都会有一个接口层, 有三个主要作用: 第一个作用,要做 安全隔离,因为前端节点都是直接和用户交互,需要防范各种恶意攻击; 第二个还充当着一个 流量控制的作用,大家知道,在2014年春节的时候,微信红包,每分钟8亿多次的请求,其实真正到它后台的请求量,只有十万左右的数量级(这里的数据可能不准),剩余的流量在接口层就被挡住了; 第三,我们看对 PC 端和移 动 端的需求不一样的,所以我们可以进行拆分。接口层之后是后台,可以看到微博后台有三大块: 一个是 平台服 务, 第二, 搜索, 第三, 大数据。到了后台的各种服务其实都是处理的数据。 像平台的业务部门,做的就是 数据存储和读 取,对搜索来说做的是 数据的 检 索,对大数据来说是做的数据的 挖掘。微博其实和淘宝是很类似 微博其实和淘宝是很类似的。一般来说,第一代架构,基本上能支撑到用户到 百万 级别,到第二代架构基本能支撑到 千万 级别都没什么问题,当业务规模到 亿级别时,需要第三代的架构。 从 LAMP 的架构到面向服 务 的架构,有几个地方是非常难的,首先不可能在第一代基础上通过简单的修修补补满足用户量快速增长的,同时线上业务又不能停, 这是我们常说的 在 飞 机上 换 引擎的 问题。前两天我有一个朋友问我,说他在内部推行服务化的时候,把一个模块服务化做完了,其他部门就是不接。我建议在做服务化的时候,首先更多是偏向业务的梳理,同时要找准一个很好的切入点,既有架构和服务化上的提升,业务方也要有收益,比如提升性能或者降低维护成本同时升级过程要平滑,建议开始从原子化服务切入,比如基础的用户服务, 基础的短消息服务,基础的推送服务。 第二,就是可 以做无状 态 服 务,后面会详细讲,还有数据量大了后需要做数据Sharding,后面会将。 第三代 架构 要解决的 问题,就是用户量和业务趋于稳步增加(相对爆发期的指数级增长),更多考虑技术框架的稳定性, 提升系统整体的性能,降低成本,还有对整个系统监控的完善和升级。 大型网站的系统架构是如何演变的 我们通过通过数据看一下它的挑战,PV是在10亿级别,QPS在百万,数据量在千亿级别。我们可用性,就是SLA要求4个9,接口响应最多不能超过150毫秒,线上所有的故障必须得在5分钟内解决完。如果说5分钟没处理呢?那会影响你年终的绩效考核。2015年微博DAU已经过亿。我们系统有上百个微服务,每周会有两次的常规上线和不限次数的紧急上线。我们的挑战都一样,就是数据量,bigger and bigger,用户体验是faster and faster,业务是more and more。互联网业务更多是产品体验驱动, 技 术 在 产 品 体验上最有效的贡献 , 就是你的性能 越来越好 。 每次降低加载一个页面的时间,都可以间接的降低这个页面上用户的流失率。微博的技术挑战和正交分解法解析架构 下面看一下 第三代的 架构 图 以及 我 们 怎么用正交分解法 阐 述。 我们可以看到我们从两个维度,横轴和纵轴可以看到。 一个 维 度 是 水平的 分层 拆分,第二从垂直的维度会做拆分。水平的维度从接口层、到服务层到数据存储层。垂直怎么拆分,会用业务架构、技术架构、监控平台、服务治理等等来处理。我相信到第二代的时候很多架构已经有了业务架构和技术架构的拆分。我们看一下, 接口层有feed、用户关系、通讯接口;服务层,SOA里有基层服务、原子服务和组合服务,在微博我们只有原子服务和组合服务。原子服务不依赖于任何其他服务,组合服务由几个原子服务和自己的业务逻辑构建而成 ,资源层负责海量数据的存储(后面例子会详细讲)。技 术框架解决 独立于 业务 的海量高并发场景下的技术难题,由众多的技术组件共同构建而成 。在接口层,微博使用JERSY框架,帮助你做参数的解析,参数的验证,序列化和反序列化;资源层,主要是缓存、DB相关的各类组件,比如Cache组件和对象库组件。监 控平台和服 务 治理 , 完成系统服务的像素级监控,对分布式系统做提前诊断、预警以及治理。包含了SLA规则的制定、服务监控、服务调用链监控、流量监控、错误异常监控、线上灰度发布上线系统、线上扩容缩容调度系统等。 下面我们讲一下常见的设计原则。 第一个,首先是系统架构三个利器: 一个, 我 们 RPC 服 务组 件 (这里不讲了), 第二个,我们 消息中 间 件 。消息中间件起的作用:可以把两个模块之间的交互异步化,其次可以把不均匀请求流量输出为匀速的输出流量,所以说消息中间件 异步化 解耦 和流量削峰的利器。 第三个是配置管理,它是 代码级灰度发布以及 保障系统降级的利器。 第二个 , 无状态 , 接口 层 最重要的就是无状 态。我们在电商网站购物,在这个过程中很多情况下是有状态的,比如我浏览了哪些商品,为什么大家又常说接口层是无状态的,其实我们把状态从接口层剥离到了数据层。像用户在电商网站购物,选了几件商品,到了哪一步,接口无状态后,状态要么放在缓存中,要么放在数据库中, 其 实 它并不是没有状 态 , 只是在 这 个 过 程中我 们 要把一些有状 态 的 东 西抽离出来 到了数据层。 第三个, 数据 层 比服 务层 更需要 设计,这是一条非常重要的经验。对于服务层来说,可以拿PHP写,明天你可以拿JAVA来写,但是如果你的数据结构开始设计不合理,将来数据结构的改变会花费你数倍的代价,老的数据格式向新的数据格式迁移会让你痛不欲生,既有工作量上的,又有数据迁移跨越的时间周期,有一些甚至需要半年以上。 第四,物理结构与逻辑结构的映射,上一张图看到两个维度切成十二个区间,每个区间代表一个技术领域,这个可以看做我们的逻辑结构。另外,不论后台还是应用层的开发团队,一般都会分几个垂直的业务组加上一个基础技术架构组,这就是从物理组织架构到逻辑的技术架构的完美的映射,精细化团队分工,有利于提高沟通协作的效率 。 第五, www .sanhao.com 的访问过程,我们这个架构图里没有涉及到的,举个例子,比如当你在浏览器输入www.sanhao网址的时候,这个请求在接口层之前发生了什么?首先会查看你本机DNS以及DNS服务,查找域名对应的IP地址,然后发送HTTP请求过去。这个请求首先会到前端的VIP地址(公网服务IP地址),VIP之后还要经过负载均衡器(Nginx服务器),之后才到你的应用接口层。在接口层之前发生了这么多事,可能有用户报一个问题的时候,你通过在接口层查日志根本发现不了问题,原因就是问题可能发生在到达接口层之前了。 第六,我们说分布式系统,它最终的瓶颈会落在哪里呢?前端时间有一个网友跟我讨论的时候,说他们的系统遇到了一个瓶颈, 查遍了CPU,内存,网络,存储,都没有问题。我说你再查一遍,因为最终你不论用上千台服务器还是上万台服务器,最终系统出瓶颈的一定会落在某一台机(可能是叶子节点也可能是核心的节点),一定落在CPU、内存、存储和网络上,最后查出来问题出在一台服务器的网卡带宽上。微博多级双机房缓存架构 接下来我们看一下微博的Feed多级缓存。我们做业务的时候,经常很少做业务分析,技术大会上的分享又都偏向技术架构。其实大家更多的日常工作是需要花费更多时间在业务优化上。这张图是统计微博的信息流前几页的访问比例,像前三页占了97%,在做缓存设计的时候,我们最多只存最近的M条数据。 这里强调的就是做系统设计 要基于用 户 的 场 景 , 越细致越好 。举了一个例子,大家都会用电商,电商在双十一会做全国范围内的活动,他们做设计的时候也会考虑场景的,一个就是购物车,我曾经跟相关开发讨论过,购物车是在双十一之前用户的访问量非常大,就是不停地往里加商品。在真正到双十一那天他不会往购物车加东西了,但是他会频繁的浏览购物车。针对这个场景,活动之前重点设计优化购物车的写场景, 活动开始后优化购物车的读场景。 你看到的微博是由哪些部分聚合而成的呢?最右边的是Feed,就是微博所有关注的人,他们的微博所组成的。微博我们会按照时间顺序把所有关注人的顺序做一个排序。随着业务的发展,除了跟时间序相关的微博还有非时间序的微博,就是会有广告的要求,增加一些广告,还有粉丝头条,就是拿钱买的,热门微博,都会插在其中。分发控制,就是说和一些推荐相关的,我推荐一些相关的好友的微博,我推荐一些你可能没有读过的微博,我推荐一些其他类型的微博。 当然对非时序的微博和分发控制微博,实际会起多个并行的程序来读取,最后同步做统一的聚合。这里稍微分享一下, 从SNS社交领域来看,国内现在做的比较好的三个信息流: 微博 是 基于弱关系的媒体信息流 ; 朋友圈是基于 强 关系的信息流 ; 另外一个做的比 较 好的就是今日 头 条 , 它并不是基于关系来构建信息流 , 而是基于 兴趣和相关性的个性化推荐 信息流 。 信息流的聚合,体现在很多很多的产品之中,除了SNS,电商里也有信息流的聚合的影子。比如搜索一个商品后出来的列表页,它的信息流基本由几部分组成:第一,打广告的;第二个,做一些推荐,热门的商品,其次,才是关键字相关的搜索结果。 信息流 开始的时候 很 简单 , 但是到后期会 发现 , 你的 这 个流 如何做控制分发 , 非常复杂, 微博在最近一两年一直在做 这样 的工作。刚才我们是从业务上分析,那么技术上怎么解决高并发,高性能的问题?微博访问量很大的时候,底层存储是用MySQL数据库,当然也会有其他的。对于查询请求量大的时候,大家知道一定有缓存,可以复用可重用的计算结果。可以看到,发一条微博,我有很多粉丝,他们都会来看我发的内容,所以 微博是最适合使用 缓 存 的系统,微博的读写比例基本在几十比一。微博使用了 双 层缓 存,上面是L1,每个L1上都是一组(包含4-6台机器),左边的框相当于一个机房,右边又是一个机房。在这个系统中L1缓存所起的作用是什么? 首先,L1 缓 存增加整个系 统 的 QPS, 其次 以低成本灵活扩容的方式 增加 系统 的 带宽 。想象一个极端场景,只有一篇博文,但是它的访问量无限增长,其实我们不需要影响L2缓存,因为它的内容存储的量小,但它就是访问量大。这种场景下,你就需要使用L1来扩容提升QPS和带宽瓶颈。另外一个场景,就是L2级缓存发生作用,比如我有一千万个用户,去访问的是一百万个用户的微博 ,这个时候,他不只是说你的吞吐量和访问带宽,就是你要缓存的博文的内容也很多了,这个时候你要考虑缓存的容量, 第二 级缓 存更多的是从容量上来 规划,保证请求以较小的比例 穿透到 后端的 数据 库 中 ,根据你的用户模型你可以估出来,到底有百分之多少的请求不能穿透到DB, 评估这个容量之后,才能更好的评估DB需要多少库,需要承担多大的访问的压力。另外,我们看双机房的话,左边一个,右边一个。 两个机房是互 为 主 备 , 或者互 为热备 。如果两个用户在不同地域,他们访问两个不同机房的时候,假设用户从IDC1过来,因为就近原理,他会访问L1,没有的话才会跑到Master,当在IDC1没找到的时候才会跑到IDC2来找。同时有用户从IDC2访问,也会有请求从L1和Master返回或者到IDC1去查找。 IDC1 和 IDC2 ,两个机房都有全量的用户数据,同时在线提供服务,但是缓存查询又遵循最近访问原理。还有哪些多级缓存的例子呢?CDN是典型的多级缓存。CDN在国内各个地区做了很多节点,比如在杭州市部署一个节点时,在机房里肯定不止一台机器,那么对于一个地区来说,只有几台服务器到源站回源,其他节点都到这几台服务器回源即可,这么看CDN至少也有两级。Local Cache+ 分布式 缓 存,这也是常见的一种策略。有一种场景,分布式缓存并不适用, 比如 单 点 资 源 的爆发性峰值流量,这个时候使用Local Cache + 分布式缓存,Local Cache 在 应用 服 务 器 上用很小的 内存资源 挡住少量的 极端峰值流量,长尾的流量仍然访问分布式缓存,这样的Hybrid缓存架构通过复用众多的应用服务器节点,降低了系统的整体成本。 我们来看一下 Feed 的存 储 架构,微博的博文主要存在MySQL中。首先来看内容表,这个比较简单,每条内容一个索引,每天建一张表,其次看索引表,一共建了两级索引。首先想象一下用户场景,大部分用户刷微博的时候,看的是他关注所有人的微博,然后按时间来排序。仔细分析发现在这个场景下, 跟一个用户的自己的相关性很小了。所以在一级索引的时候会先根据关注的用户,取他们的前条微博ID,然后聚合排序。我们在做哈希(分库分表)的时候,同时考虑了按照UID哈希和按照时间维度。很业务和时间相关性很高的,今天的热点新闻,明天就没热度了,数据的冷热非常明显,这种场景就需要按照时间维度做分表,首先冷热数据做了分离(可以对冷热数据采用不同的存储方案来降低成本),其次, 很容止控制我数据库表的爆炸。像微博如果只按照用户维度区分,那么这个用户所有数据都在一张表里,这张表就是无限增长的,时间长了查询会越来越慢。二级索引,是我们里面一个比较特殊的场景,就是我要快速找到这个人所要发布的某一时段的微博时,通过二级索引快速定位。 分布式服务追踪系统 分布式追踪服务系统,当系统到千万级以后的时候,越来越庞杂,所解决的问题更偏向稳定性,性能和监控。刚才说用户只要有一个请求过来,你可以依赖你的服务RPC1、RPC2,你会发现RPC2又依赖RPC3、RPC4。分布式服务的时候一个痛点,就是说一个请求从用户过来之后,在后台不同的机器之间不停的调用并返回。 当你发现一个问题的时候,这些日志落在不同的机器上,你也不知道问题到底出在哪儿,各个服务之间互相隔离,互相之间没有建立关联。所以导致排查问题基本没有任何手段,就是出了问题没法儿解决。 我们要解决的问题,我们刚才说日志互相隔离,我们就要把它建立联系。建立联系我们就有一个请求ID,然后结合RPC框架, 服务治理功能。假设请求从客户端过来,其中包含一个ID 101,到服务A时仍然带有ID 101,然后调用RPC1的时候也会标识这是101 ,所以需要 一个唯一的 请求 ID 标识 递归迭代的传递到每一个 相关 节点。第二个,你做的时候,你不能说每个地方都加,对业务系统来说需要一个框架来完成这个工作, 这 个框架要 对业务 系 统 是最低侵入原 则 , 用 JAVA 的 话 就可以用 AOP,要做到零侵入的原则,就是对所有相关的中间件打点,从接口层组件(HTTP Client、HTTP Server)至到服务层组件(RPC Client、RPC Server),还有数据访问中间件的,这样业务系统只需要少量的配置信息就可以实现全链路监控 。为什么要用日志?服务化以后,每个服务可以用不同的开发语言, 考虑多种开发语言的兼容性 , 内部定 义标 准化的日志 是唯一且有效的办法。最后,如何构建基于GPS导航的路况监控?我们刚才讲分布式服务追踪。分布式服务追踪能解决的问题, 如果 单一用 户发现问题 后 , 可以通 过请 求 ID 快速找到 发 生 问题 的 节 点在什么,但是并没有解决如何发现问题。我们看现实中比较容易理解的道路监控,每辆车有GPS定位,我想看北京哪儿拥堵的时候,怎么做? 第一个 , 你肯定要知道每个 车 在什么位置,它走到哪儿了。其实可以说每个车上只要有一个标识,加上每一次流动的信息,就可以看到每个车流的位置和方向。 其次如何做 监 控和 报 警,我们怎么能了解道路的流量状况和负载,并及时报警。我们要定义这条街道多宽多高,单位时间可以通行多少辆车,这就是道路的容量。有了道路容量,再有道路的实时流量,我们就可以基于实习路况做预警? 对应于 分布式系 统 的话如何构建? 第一 , 你要 定义 每个服 务节 点它的 SLA A 是多少 ?SLA可以从系统的CPU占用率、内存占用率、磁盘占用率、QPS请求数等来定义,相当于定义系统的容量。 第二个 , 统计 线 上 动态 的流量,你要知道服务的平均QPS、最低QPS和最大QPS,有了流量和容量,就可以对系统做全面的监控和报警。 刚才讲的是理论,实际情况肯定比这个复杂。微博在春节的时候做许多活动,必须保障系统稳定,理论上你只要定义容量和流量就可以。但实际远远不行,为什么?有技术的因素,有人为的因素,因为不同的开发定义的流量和容量指标有主观性,很难全局量化标准,所以真正流量来了以后,你预先评估的系统瓶颈往往不正确。实际中我们在春节前主要采取了三个措施:第一,最简单的就是有降 级 的 预 案,流量超过系统容量后,先把哪些功能砍掉,需要有明确的优先级 。第二个, 线上全链路压测,就是把现在的流量放大到我们平常流量的五倍甚至十倍(比如下线一半的服务器,缩容而不是扩容),看看系统瓶颈最先发生在哪里。我们之前有一些例子,推测系统数据库会先出现瓶颈,但是实测发现是前端的程序先遇到瓶颈。第三,搭建在线 Docker 集群 , 所有业务共享备用的 Docker集群资源,这样可以极大的避免每个业务都预留资源,但是实际上流量没有增长造成的浪费。 总结 接下来说的是如何不停的学习和提升,这里以Java语言为例,首先, 一定要 理解 JAVA;第二步,JAVA完了以后,一定要 理 解 JVM;其次,还要 理解 操作系统;再次还是要了解一下 Design Pattern,这将告诉你怎么把过去的经验抽象沉淀供将来借鉴;还要学习 TCP/IP、 分布式系 统、数据结构和算法。
hiekay 2019-12-02 01:39:25 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 发送访问OSS的请求 您可以直接使用OSS提供的RESTful API接口访问或者使用对API接口进行完整封装的SDK开发包。而每一次向OSS的请求根据当前Bucket权限和操作不同要求用户进行身份验证或者直接匿名访问。对OSS的资源访问的分类如下: 按访问者的角色可分为拥有者访问和第三方用户访问。这里的拥有者指的是Bucket的Owner,也称为开发者。第三方用户是指访问Bucket里资源的用户。 按访问者的身份信息可分为匿名访问和带签名访问。对于OSS来说,如果请求中没有携带任何和身份相关的信息即为匿名访问。带签名访问指的是按照OSS API文档中规定的在请求头部或者在请求URL中携带签名的相关信息。 AccessKey 类型 目前访问 OSS 使用的 AK(AccessKey)有三种类型,具体如下: 阿里云账号AccessKey 阿里云账号AK特指Bucket拥有者的AK,每个阿里云账号提供的AccessKey对拥有的资源有完全的权限。每个阿里云账号能够同时拥有不超过5个active或者inactive的AK对(AccessKeyId和AccessKeySecret)。 用户可以登录AccessKey管理控制台,申请新增或删除AK对。 每个AK对都有active/inactive两种状态。 Active 表明用户的 AK 处于激活状态,可以在身份验证的时候使用。 Inactive 表明用户的 AK 处于非激活状态,不能在身份验证的时候使用。 说明 请避免直接使用阿里云账户的 AccessKey。 RAM子账号AccessKey RAM (Resource Access Management) 是阿里云提供的资源访问控制服务。RAM账号AK指的是通过RAM被授权的AK。这组AK只能按照RAM定义的规则去访问Bucket里的资源。通过RAM,您可以集中管理您的用户(比如员工、系统或应用程序),以及控制用户可以访问您名下哪些资源的权限。比如能够限制您的用户只拥有对某一个Bucket的读权限。子账号是从属于主账号的,并且这些账号下不能拥有实际的任何资源,所有资源都属于主账号。 STS账号AccessKey STS(Security Token Service)是阿里云提供的临时访问凭证服务。STS账号AK指的是通过STS颁发的AK。这组AK只能按照STS定义的规则去访问Bucket里的资源。 身份验证具体实现 目前主要有三种身份验证方式: AK验证 RAM验证 STS验证 当用户以个人身份向OSS发送请求时,其身份验证的实现如下: 用户将发送的请求按照OSS指定的格式生成签名字符串。 用户使用AccessKeySecret对签名字符串进行加密产生验证码。 OSS收到请求以后,通过AccessKeyId找到对应的AccessKeySecret,以同样的方法提取签名字符串和验证码。 如果计算出来的验证码和提供的一样即认为该请求是有效的。 否则,OSS将拒绝处理这次请求,并返回HTTP 403错误。 对于用户来说可以直接使用OSS提供的SDK,配合不同类型的AccessKey即可实现不同的身份验证。 权限控制 针对存放在Bucket的Object的访问,OSS提供了多种权限控制,主要有: Bucket级别权限 Object级别权限 账号级别权限(RAM) 临时账号权限(STS) Bucket级别权限 Bucket权限类型 OSS提供ACL(Access Control List)权限控制方法,OSS ACL提供Bucket级别的权限访问控制,Bucket目前有三种访问权限:public-read-write,public-read和private,它们的含义如下: 权限值 中文名称 权限对访问者的限制 public-read-write 公共读写 任何人(包括匿名访问)都可以对该Bucket中的Object进行读/写/删除操作;所有这些操作产生的费用由该Bucket的Owner承担,请慎用该权限。 public-read 公共读,私有写 只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行写/删除操作;任何人(包括匿名访问)可以对Object进行读操作。 private 私有读写 只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行读/写/删除操作;其他人在未经授权的情况下无法访问该Bucket内的Object。 Bucket权限设定和读取方法 功能使用参考: API:Put BucketACL SDK:Java SDK-设置Bucket ACL 控制台:创建Bucket权限设置 API:Get BucketACL SDK:Java SDK-获取Bucket ACL Object级别权限 Object权限类型 OSS ACL也提供Object级别的权限访问控制。目前Object有四种访问权限:private, public-read, public-read-write, default。Put Object ACL操作通过Put请求中的“x-oss-object-acl”头来设置,这个操作只有Bucket Owner有权限执行。 权限值 中文名称 权限对访问者的限制 public-read-write 公共读写 该ACL表明某个Object是公共读写资源,即所有用户拥有对该Object的读写权限。 public-read 公共读,私有写 该ACL表明某个Object是公共读资源,即非Object Owner只有该Object的读权限,而Object Owner拥有该Object的读写权限。 private 私有读写 该ACL表明某个Object是私有资源,即只有该Object的Owner拥有该Object的读写权限,其他的用户没有权限操作该Object。 default 默认权限 该ACL表明某个Object是遵循Bucket读写权限的资源,即Bucket是什么权限,Object就是什么权限。 说明 如果没有设置Object的权限,即Object的ACL为default,Object的权限和Bucket权限一致。 如果设置了Object的权限,Object的权限大于Bucket权限。举个例子,如果设置了Object的权限是public-read,无论Bucket是什么权限,该Object都可以被身份验证访问和匿名访问。 Object权限设定和读取方法 功能使用参考: API:Put Object ACL SDK:Java SDK-ObjectACL 中设定Object ACL API:Get Object ACL SDK:Java SDK-ObjectACL 中读取Object ACL 账号级别权限(RAM) 使用场景 如果您购买了云资源,您的组织里有多个用户需要使用这些云资源,这些用户只能共享使用您的云账号AccessKey。这里有两个问题: 您的密钥由多人共享,泄露的风险很高。 您无法控制特定用户能访问哪些资源(比如Bucket)的权限。 解决方法:在您的阿里云账号下面,通过RAM可以创建具有自己AccessKey的子用户。您的阿里云账号被称为主账号,创建出来的账号被称为子账号,使用子账号的AccessKey只能使用主账号授权的操作和资源。 具体实现 有关RAM详情,请参考RAM用户手册。 对于授权中需要的Policy的配置方式可以参考本章最后一节:RAM和STS授权策略(Policy)配置。 临时账号权限(STS) 使用场景 对于您本地身份系统所管理的用户,比如您的App的用户、您的企业本地账号、第三方App,也有直接访问OSS资源的可能,将这部分用户称为联盟用户。此外,用户还可以是您创建的能访问您的阿里云资源的应用程序。 对于这部分联盟用户,通过阿里云STS (Security Token Service) 服务为阿里云账号(或RAM用户)提供短期访问权限管理。您不需要透露云账号(或RAM用户)的长期密钥(如登录密码、AccessKey),只需要生成一个短期访问凭证给联盟用户使用即可。这个凭证的访问权限及有效期限都可以由您自定义。您不需要关心权限撤销问题,访问凭证过期后会自动失效。 用户通过STS生成的凭证包括安全令牌(SecurityToken)、临时访问密钥(AccessKeyId, AccessKeySecret)。使用AccessKey方法与您在使用阿里云账户或RAM用户AccessKey发送请求时的方法相同。此外还需要注意的是在每个向OSS发送的请求中必须携带安全令牌。 具体实现 STS安全令牌、角色管理和使用相关内容详情,请参考RAM用户指南中的角色管理。关键是调用STS服务接口AssumeRole来获取有效访问凭证即可,也可以直接使用STS SDK来调用该方法。 RAM和STS应用场景实践 对于不同的应用场景,涉及到的访问身份验证方式可能存在差异。下面以几种典型的应用场景来说明访问身份验证中几种使用方式。 以一个移动App举例。假设您是一个移动App开发者,打算使用阿里云OSS服务来保存App的终端用户数据,并且要保证每个App用户之间的数据隔离,防止一个App用户获取到其它App用户的数据。 方式一:使用AppServer来做数据中转和数据隔离如上图所示,您需要开发一个AppServer。只有AppServer能访问云服务,ClientApp的每次读写数据都需要通过AppServer,AppServer来保证不同用户数据的隔离访问。 对于该种使用方式,使用阿里云账号或者RAM账号提供的密钥来进行签名验证访问。建议您尽量不要直接使用阿里云账号(主账号)的密钥访问OSS,避免出现安全问题。 方式二:使用STS让用户直接访问OSS STS方案描述如下图所示:方案的详细描述如下: App用户登录。App用户和云账号无关,它是App的终端用户,AppServer支持App用户登录。对于每个有效的App用户来说,需要AppServer能定义出每个App用户的最小访问权限。 AppServer请求STS服务获取一个安全令牌(SecurityToken)。在调用STS之前,AppServer需要确定App用户的最小访问权限(用Policy语法描述)以及授权的过期时间。然后通过扮演角色(AssumeRole)来获取一个代表角色身份的安全令牌。 STS返回给AppServer一个有效的访问凭证,包括一个安全令牌(SecurityToken)、临时访问密钥(AccessKeyId, AccessKeySecret)以及过期时间。 AppServer将访问凭证返回给ClientApp。ClientApp可以缓存这个凭证。当凭证失效时,ClientApp需要向AppServer申请新的有效访问凭证。比如,访问凭证有效期为1小时,那么ClientApp可以每30分钟向AppServer请求更新访问凭证。 ClientApp使用本地缓存的访问凭证去请求Aliyun Service API。云服务会感知STS访问凭证,并会依赖STS服务来验证访问凭证,正确响应用户请求。 RAM和STS授权策略(Policy)配置 对于RAM或者STS授权中使用Policy,详细规则如下。 示例 先看下面的一个Policy示例: { "Version": "1", "Statement": [ { "Action": [ "oss:GetBucketAcl", "oss:ListObjects" ], "Resource": [ "acs:oss:*:1775305056529849:mybucket" ], "Effect": "Allow", "Condition": { "StringEquals": { "acs:UserAgent": "java-sdk", "oss:Prefix": "foo" }, "IpAddress": { "acs:SourceIp": "192.168.0.1" } } }, { "Action": [ "oss:PutObject", "oss:GetObject", "oss:DeleteObject" ], "Resource": [ "acs:oss:*:1775305056529849:mybucket/file*" ], "Effect": "Allow", "Condition": { "IpAddress": { "acs:SourceIp": "192.168.0.1" } } } ] } 这是一个授权的Policy,用户用这样的一个Policy通过RAM或STS服务向其他用户授权。Policy当中有一个Statement(一条Policy当中可以有多条Statement)。Statement里面规定了相应的Action、Resource、Effect和Condition。 这条Policy把用户自己名下的mybucket和mybucket/file*这些资源授权给相应的用户,并且支持GetBucketAcl、GetBucket、PutObject、GetObject和DeleteObject这几种操作。Condition中的条件表示UserAgent为java-sdk,源IP为192.168.0.1的时候鉴权才能通过,被授权的用户才能访问相关的资源。Prefix这个Condition是在GetBucket(ListObjects)的时候起作用的,关于这个字段的解释详见OSS的API文档。 配置细则 Version Version定义了Policy的版本,本文档中sw2q的配置方式,设置为1。 Statement 通过Statement描述授权语义,其中可以根据业务场景包含多条语义,每条包含对Action、Effect、Resource和Condition的描述。每次请求系统会逐条依次匹配检查,所有匹配成功的Statement会根据Effect的设置不同分为通过(Allow)、禁止(Deny),其中禁止(Deny)的优先。如果匹配成功的都为通过,该条请求即鉴权通过。如果匹配成功有一条禁止,或者没有任何条目匹配成功,该条请求被禁止访问。 Action Action分为三大类:Service级别操作,对应的是GetService操作,用来列出所有属于该用户的Bucket列表。 Bucket级别操作,对应类似于oss:PutBucketAcl、oss:GetBucketLocation之类的操作,操作的对象是Bucket,它们的名称和相应的接口名称一一对应。 Object级别操作,分为oss:GetObject、oss:PutObject、oss:DeleteObject和oss:AbortMultipartUpload,操作对象是Object。 如想授权某一类的Object的操作,可以选择这几种的一种或几种。另外,所有的Action前面都必须加上oss:,如上面例子所示。Action是一个列表,可以有多个Action。具体的Action和API接口的对应关系如下: Service级别 API Action GetService(ListBuckets) oss:ListBuckets Bucket级别 API Action PutBucket oss:PutBucket GetBucket(ListObjects) oss:ListObjects PutBucketAcl oss:PutBucketAcl DeleteBucket oss:DeleteBucket GetBucketLocation oss:GetBucketLocation GetBucketAcl oss:GetBucketAcl GetBucketLogging oss:GetBucketLogging PutBucketLogging oss:PutBucketLogging DeleteBucketLogging oss:DeleteBucketLogging GetBucketWebsite oss:GetBucketWebsite PutBucketWebsite oss:PutBucketWebsite DeleteBucketWebsite oss:DeleteBucketWebsite GetBucketReferer oss:GetBucketReferer PutBucketReferer oss:PutBucketReferer GetBucketLifecycle oss:GetBucketLifecycle PutBucketLifecycle oss:PutBucketLifecycle DeleteBucketLifecycle oss:DeleteBucketLifecycle ListMultipartUploads oss:ListMultipartUploads PutBucketCors oss:PutBucketCors GetBucketCors oss:GetBucketCors DeleteBucketCors oss:DeleteBucketCors PutBucketReplication oss:PutBucketReplication GetBucketReplication oss:GetBucketReplication DeleteBucketReplication oss:DeleteBucketReplication GetBucketReplicationLocation oss:GetBucketReplicationLocation GetBucketReplicationProgress oss:GetBucketReplicationProgress Object级别 API Action GetObject oss:GetObject HeadObject oss:GetObject PutObject oss:PutObject PostObject oss:PutObject InitiateMultipartUpload oss:PutObject UploadPart oss:PutObject CompleteMultipart oss:PutObject DeleteObject oss:DeleteObject DeleteMultipartObjects oss:DeleteObject AbortMultipartUpload oss:AbortMultipartUpload ListParts oss:ListParts CopyObject oss:GetObject,oss:PutObject UploadPartCopy oss:GetObject,oss:PutObject AppendObject oss:PutObject GetObjectAcl oss:GetObjectAcl PutObjectAcl oss:PutObjectAcl Resource Resource指代的是OSS上面的某个具体的资源或者某些资源(支持*通配),resource的规则是acs:oss:{region}:{bucket_owner}:{bucket_name}/{object_name}。对于所有Bucket级别的操作来说不需要最后的斜杠和{object_name},即acs:oss:{region}:{bucket_owner}:{bucket_name}。Resource也是一个列表,可以有多个Resource。其中的region字段暂时不做支持,设置为*。 Effect Effect代表本条的Statement的授权的结果,分为Allow和Deny,分别指代通过和禁止。多条Statement同时匹配成功时,禁止(Deny)的优先级更高。 例如,期望禁止用户对某一目录进行删除,但对于其他文件有全部权限: { "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:*" ], "Resource": [ "acs:oss:*:*:bucketname" ] }, { "Effect": "Deny", "Action": [ "oss:DeleteObject" ], "Resource": [ "acs:oss:*:*:bucketname/index/*", ] } ] } Condition Condition代表Policy授权的一些条件,上面的示例里面可以设置对于acs:UserAgent的检查、acs:SourceIp的检查、还有oss:Prefix这项用来在GetBucket的时候对资源进行限制。 OSS支持的Condition如下: condition 功能 合法取值 acs:SourceIp 指定ip网段 普通的ip,支持*通配 acs:UserAgent 指定http useragent头 字符串 acs:CurrentTime 指定合法的访问时间 ISO8601格式 acs:SecureTransport 是否是https协议 “true”或者”false” oss:Prefix 用作ListObjects时的prefix 合法的object name 更多示例 针对具体场景更多的授权策略配置示例,可以参考教程示例:控制存储空间和文件夹的访问权限和OSS授权常见问题。 Policy在线图形化便捷配置工具,请单击这里。 最佳实践 RAM和STS使用指南
2019-12-01 23:12:47 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 发送访问OSS的请求 您可以直接使用OSS提供的RESTful API接口访问或者使用对API接口进行完整封装的SDK开发包。而每一次向OSS的请求根据当前Bucket权限和操作不同要求用户进行身份验证或者直接匿名访问。对OSS的资源访问的分类如下: 按访问者的角色可分为拥有者访问和第三方用户访问。这里的拥有者指的是Bucket的Owner,也称为开发者。第三方用户是指访问Bucket里资源的用户。 按访问者的身份信息可分为匿名访问和带签名访问。对于OSS来说,如果请求中没有携带任何和身份相关的信息即为匿名访问。带签名访问指的是按照OSS API文档中规定的在请求头部或者在请求URL中携带签名的相关信息。 AccessKey 类型 目前访问 OSS 使用的 AK(AccessKey)有三种类型,具体如下: 阿里云账号AccessKey 阿里云账号AK特指Bucket拥有者的AK,每个阿里云账号提供的AccessKey对拥有的资源有完全的权限。每个阿里云账号能够同时拥有不超过5个active或者inactive的AK对(AccessKeyId和AccessKeySecret)。 用户可以登录AccessKey管理控制台,申请新增或删除AK对。 每个AK对都有active/inactive两种状态。 Active 表明用户的 AK 处于激活状态,可以在身份验证的时候使用。 Inactive 表明用户的 AK 处于非激活状态,不能在身份验证的时候使用。 说明 请避免直接使用阿里云账户的 AccessKey。 RAM子账号AccessKey RAM (Resource Access Management) 是阿里云提供的资源访问控制服务。RAM账号AK指的是通过RAM被授权的AK。这组AK只能按照RAM定义的规则去访问Bucket里的资源。通过RAM,您可以集中管理您的用户(比如员工、系统或应用程序),以及控制用户可以访问您名下哪些资源的权限。比如能够限制您的用户只拥有对某一个Bucket的读权限。子账号是从属于主账号的,并且这些账号下不能拥有实际的任何资源,所有资源都属于主账号。 STS账号AccessKey STS(Security Token Service)是阿里云提供的临时访问凭证服务。STS账号AK指的是通过STS颁发的AK。这组AK只能按照STS定义的规则去访问Bucket里的资源。 身份验证具体实现 目前主要有三种身份验证方式: AK验证 RAM验证 STS验证 当用户以个人身份向OSS发送请求时,其身份验证的实现如下: 用户将发送的请求按照OSS指定的格式生成签名字符串。 用户使用AccessKeySecret对签名字符串进行加密产生验证码。 OSS收到请求以后,通过AccessKeyId找到对应的AccessKeySecret,以同样的方法提取签名字符串和验证码。 如果计算出来的验证码和提供的一样即认为该请求是有效的。 否则,OSS将拒绝处理这次请求,并返回HTTP 403错误。 对于用户来说可以直接使用OSS提供的SDK,配合不同类型的AccessKey即可实现不同的身份验证。 权限控制 针对存放在Bucket的Object的访问,OSS提供了多种权限控制,主要有: Bucket级别权限 Object级别权限 账号级别权限(RAM) 临时账号权限(STS) Bucket级别权限 Bucket权限类型 OSS提供ACL(Access Control List)权限控制方法,OSS ACL提供Bucket级别的权限访问控制,Bucket目前有三种访问权限:public-read-write,public-read和private,它们的含义如下: 权限值 中文名称 权限对访问者的限制 public-read-write 公共读写 任何人(包括匿名访问)都可以对该Bucket中的Object进行读/写/删除操作;所有这些操作产生的费用由该Bucket的Owner承担,请慎用该权限。 public-read 公共读,私有写 只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行写/删除操作;任何人(包括匿名访问)可以对Object进行读操作。 private 私有读写 只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行读/写/删除操作;其他人在未经授权的情况下无法访问该Bucket内的Object。 Bucket权限设定和读取方法 功能使用参考: API:Put BucketACL SDK:Java SDK-设置Bucket ACL 控制台:创建Bucket权限设置 API:Get BucketACL SDK:Java SDK-获取Bucket ACL Object级别权限 Object权限类型 OSS ACL也提供Object级别的权限访问控制。目前Object有四种访问权限:private, public-read, public-read-write, default。Put Object ACL操作通过Put请求中的“x-oss-object-acl”头来设置,这个操作只有Bucket Owner有权限执行。 权限值 中文名称 权限对访问者的限制 public-read-write 公共读写 该ACL表明某个Object是公共读写资源,即所有用户拥有对该Object的读写权限。 public-read 公共读,私有写 该ACL表明某个Object是公共读资源,即非Object Owner只有该Object的读权限,而Object Owner拥有该Object的读写权限。 private 私有读写 该ACL表明某个Object是私有资源,即只有该Object的Owner拥有该Object的读写权限,其他的用户没有权限操作该Object。 default 默认权限 该ACL表明某个Object是遵循Bucket读写权限的资源,即Bucket是什么权限,Object就是什么权限。 说明 如果没有设置Object的权限,即Object的ACL为default,Object的权限和Bucket权限一致。 如果设置了Object的权限,Object的权限大于Bucket权限。举个例子,如果设置了Object的权限是public-read,无论Bucket是什么权限,该Object都可以被身份验证访问和匿名访问。 Object权限设定和读取方法 功能使用参考: API:Put Object ACL SDK:Java SDK-ObjectACL 中设定Object ACL API:Get Object ACL SDK:Java SDK-ObjectACL 中读取Object ACL 账号级别权限(RAM) 使用场景 如果您购买了云资源,您的组织里有多个用户需要使用这些云资源,这些用户只能共享使用您的云账号AccessKey。这里有两个问题: 您的密钥由多人共享,泄露的风险很高。 您无法控制特定用户能访问哪些资源(比如Bucket)的权限。 解决方法:在您的阿里云账号下面,通过RAM可以创建具有自己AccessKey的子用户。您的阿里云账号被称为主账号,创建出来的账号被称为子账号,使用子账号的AccessKey只能使用主账号授权的操作和资源。 具体实现 有关RAM详情,请参考RAM用户手册。 对于授权中需要的Policy的配置方式可以参考本章最后一节:RAM和STS授权策略(Policy)配置。 临时账号权限(STS) 使用场景 对于您本地身份系统所管理的用户,比如您的App的用户、您的企业本地账号、第三方App,也有直接访问OSS资源的可能,将这部分用户称为联盟用户。此外,用户还可以是您创建的能访问您的阿里云资源的应用程序。 对于这部分联盟用户,通过阿里云STS (Security Token Service) 服务为阿里云账号(或RAM用户)提供短期访问权限管理。您不需要透露云账号(或RAM用户)的长期密钥(如登录密码、AccessKey),只需要生成一个短期访问凭证给联盟用户使用即可。这个凭证的访问权限及有效期限都可以由您自定义。您不需要关心权限撤销问题,访问凭证过期后会自动失效。 用户通过STS生成的凭证包括安全令牌(SecurityToken)、临时访问密钥(AccessKeyId, AccessKeySecret)。使用AccessKey方法与您在使用阿里云账户或RAM用户AccessKey发送请求时的方法相同。此外还需要注意的是在每个向OSS发送的请求中必须携带安全令牌。 具体实现 STS安全令牌、角色管理和使用相关内容详情,请参考RAM用户指南中的角色管理。关键是调用STS服务接口AssumeRole来获取有效访问凭证即可,也可以直接使用STS SDK来调用该方法。 RAM和STS应用场景实践 对于不同的应用场景,涉及到的访问身份验证方式可能存在差异。下面以几种典型的应用场景来说明访问身份验证中几种使用方式。 以一个移动App举例。假设您是一个移动App开发者,打算使用阿里云OSS服务来保存App的终端用户数据,并且要保证每个App用户之间的数据隔离,防止一个App用户获取到其它App用户的数据。 方式一:使用AppServer来做数据中转和数据隔离如上图所示,您需要开发一个AppServer。只有AppServer能访问云服务,ClientApp的每次读写数据都需要通过AppServer,AppServer来保证不同用户数据的隔离访问。 对于该种使用方式,使用阿里云账号或者RAM账号提供的密钥来进行签名验证访问。建议您尽量不要直接使用阿里云账号(主账号)的密钥访问OSS,避免出现安全问题。 方式二:使用STS让用户直接访问OSS STS方案描述如下图所示:方案的详细描述如下: App用户登录。App用户和云账号无关,它是App的终端用户,AppServer支持App用户登录。对于每个有效的App用户来说,需要AppServer能定义出每个App用户的最小访问权限。 AppServer请求STS服务获取一个安全令牌(SecurityToken)。在调用STS之前,AppServer需要确定App用户的最小访问权限(用Policy语法描述)以及授权的过期时间。然后通过扮演角色(AssumeRole)来获取一个代表角色身份的安全令牌。 STS返回给AppServer一个有效的访问凭证,包括一个安全令牌(SecurityToken)、临时访问密钥(AccessKeyId, AccessKeySecret)以及过期时间。 AppServer将访问凭证返回给ClientApp。ClientApp可以缓存这个凭证。当凭证失效时,ClientApp需要向AppServer申请新的有效访问凭证。比如,访问凭证有效期为1小时,那么ClientApp可以每30分钟向AppServer请求更新访问凭证。 ClientApp使用本地缓存的访问凭证去请求Aliyun Service API。云服务会感知STS访问凭证,并会依赖STS服务来验证访问凭证,正确响应用户请求。 RAM和STS授权策略(Policy)配置 对于RAM或者STS授权中使用Policy,详细规则如下。 示例 先看下面的一个Policy示例: { "Version": "1", "Statement": [ { "Action": [ "oss:GetBucketAcl", "oss:ListObjects" ], "Resource": [ "acs:oss:*:1775305056529849:mybucket" ], "Effect": "Allow", "Condition": { "StringEquals": { "acs:UserAgent": "java-sdk", "oss:Prefix": "foo" }, "IpAddress": { "acs:SourceIp": "192.168.0.1" } } }, { "Action": [ "oss:PutObject", "oss:GetObject", "oss:DeleteObject" ], "Resource": [ "acs:oss:*:1775305056529849:mybucket/file*" ], "Effect": "Allow", "Condition": { "IpAddress": { "acs:SourceIp": "192.168.0.1" } } } ] } 这是一个授权的Policy,用户用这样的一个Policy通过RAM或STS服务向其他用户授权。Policy当中有一个Statement(一条Policy当中可以有多条Statement)。Statement里面规定了相应的Action、Resource、Effect和Condition。 这条Policy把用户自己名下的mybucket和mybucket/file*这些资源授权给相应的用户,并且支持GetBucketAcl、GetBucket、PutObject、GetObject和DeleteObject这几种操作。Condition中的条件表示UserAgent为java-sdk,源IP为192.168.0.1的时候鉴权才能通过,被授权的用户才能访问相关的资源。Prefix这个Condition是在GetBucket(ListObjects)的时候起作用的,关于这个字段的解释详见OSS的API文档。 配置细则 Version Version定义了Policy的版本,本文档中sw2q的配置方式,设置为1。 Statement 通过Statement描述授权语义,其中可以根据业务场景包含多条语义,每条包含对Action、Effect、Resource和Condition的描述。每次请求系统会逐条依次匹配检查,所有匹配成功的Statement会根据Effect的设置不同分为通过(Allow)、禁止(Deny),其中禁止(Deny)的优先。如果匹配成功的都为通过,该条请求即鉴权通过。如果匹配成功有一条禁止,或者没有任何条目匹配成功,该条请求被禁止访问。 Action Action分为三大类:Service级别操作,对应的是GetService操作,用来列出所有属于该用户的Bucket列表。 Bucket级别操作,对应类似于oss:PutBucketAcl、oss:GetBucketLocation之类的操作,操作的对象是Bucket,它们的名称和相应的接口名称一一对应。 Object级别操作,分为oss:GetObject、oss:PutObject、oss:DeleteObject和oss:AbortMultipartUpload,操作对象是Object。 如想授权某一类的Object的操作,可以选择这几种的一种或几种。另外,所有的Action前面都必须加上oss:,如上面例子所示。Action是一个列表,可以有多个Action。具体的Action和API接口的对应关系如下: Service级别 API Action GetService(ListBuckets) oss:ListBuckets Bucket级别 API Action PutBucket oss:PutBucket GetBucket(ListObjects) oss:ListObjects PutBucketAcl oss:PutBucketAcl DeleteBucket oss:DeleteBucket GetBucketLocation oss:GetBucketLocation GetBucketAcl oss:GetBucketAcl GetBucketLogging oss:GetBucketLogging PutBucketLogging oss:PutBucketLogging DeleteBucketLogging oss:DeleteBucketLogging GetBucketWebsite oss:GetBucketWebsite PutBucketWebsite oss:PutBucketWebsite DeleteBucketWebsite oss:DeleteBucketWebsite GetBucketReferer oss:GetBucketReferer PutBucketReferer oss:PutBucketReferer GetBucketLifecycle oss:GetBucketLifecycle PutBucketLifecycle oss:PutBucketLifecycle DeleteBucketLifecycle oss:DeleteBucketLifecycle ListMultipartUploads oss:ListMultipartUploads PutBucketCors oss:PutBucketCors GetBucketCors oss:GetBucketCors DeleteBucketCors oss:DeleteBucketCors PutBucketReplication oss:PutBucketReplication GetBucketReplication oss:GetBucketReplication DeleteBucketReplication oss:DeleteBucketReplication GetBucketReplicationLocation oss:GetBucketReplicationLocation GetBucketReplicationProgress oss:GetBucketReplicationProgress Object级别 API Action GetObject oss:GetObject HeadObject oss:GetObject PutObject oss:PutObject PostObject oss:PutObject InitiateMultipartUpload oss:PutObject UploadPart oss:PutObject CompleteMultipart oss:PutObject DeleteObject oss:DeleteObject DeleteMultipartObjects oss:DeleteObject AbortMultipartUpload oss:AbortMultipartUpload ListParts oss:ListParts CopyObject oss:GetObject,oss:PutObject UploadPartCopy oss:GetObject,oss:PutObject AppendObject oss:PutObject GetObjectAcl oss:GetObjectAcl PutObjectAcl oss:PutObjectAcl Resource Resource指代的是OSS上面的某个具体的资源或者某些资源(支持*通配),resource的规则是acs:oss:{region}:{bucket_owner}:{bucket_name}/{object_name}。对于所有Bucket级别的操作来说不需要最后的斜杠和{object_name},即acs:oss:{region}:{bucket_owner}:{bucket_name}。Resource也是一个列表,可以有多个Resource。其中的region字段暂时不做支持,设置为*。 Effect Effect代表本条的Statement的授权的结果,分为Allow和Deny,分别指代通过和禁止。多条Statement同时匹配成功时,禁止(Deny)的优先级更高。 例如,期望禁止用户对某一目录进行删除,但对于其他文件有全部权限: { "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:*" ], "Resource": [ "acs:oss:*:*:bucketname" ] }, { "Effect": "Deny", "Action": [ "oss:DeleteObject" ], "Resource": [ "acs:oss:*:*:bucketname/index/*", ] } ] } Condition Condition代表Policy授权的一些条件,上面的示例里面可以设置对于acs:UserAgent的检查、acs:SourceIp的检查、还有oss:Prefix这项用来在GetBucket的时候对资源进行限制。 OSS支持的Condition如下: condition 功能 合法取值 acs:SourceIp 指定ip网段 普通的ip,支持*通配 acs:UserAgent 指定http useragent头 字符串 acs:CurrentTime 指定合法的访问时间 ISO8601格式 acs:SecureTransport 是否是https协议 “true”或者”false” oss:Prefix 用作ListObjects时的prefix 合法的object name 更多示例 针对具体场景更多的授权策略配置示例,可以参考教程示例:控制存储空间和文件夹的访问权限和OSS授权常见问题。 Policy在线图形化便捷配置工具,请单击这里。 最佳实践 RAM和STS使用指南
2019-12-01 23:12:47 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 发送访问OSS的请求 您可以直接使用OSS提供的RESTful API接口访问或者使用对API接口进行完整封装的SDK开发包。而每一次向OSS的请求根据当前Bucket权限和操作不同要求用户进行身份验证或者直接匿名访问。对OSS的资源访问的分类如下: 按访问者的角色可分为拥有者访问和第三方用户访问。这里的拥有者指的是Bucket的Owner,也称为开发者。第三方用户是指访问Bucket里资源的用户。 按访问者的身份信息可分为匿名访问和带签名访问。对于OSS来说,如果请求中没有携带任何和身份相关的信息即为匿名访问。带签名访问指的是按照OSS API文档中规定的在请求头部或者在请求URL中携带签名的相关信息。 AccessKey 类型 目前访问 OSS 使用的 AK(AccessKey)有三种类型,具体如下: 阿里云账号AccessKey 阿里云账号AK特指Bucket拥有者的AK,每个阿里云账号提供的AccessKey对拥有的资源有完全的权限。每个阿里云账号能够同时拥有不超过5个active或者inactive的AK对(AccessKeyId和AccessKeySecret)。 用户可以登录AccessKey管理控制台,申请新增或删除AK对。 每个AK对都有active/inactive两种状态。 Active 表明用户的 AK 处于激活状态,可以在身份验证的时候使用。 Inactive 表明用户的 AK 处于非激活状态,不能在身份验证的时候使用。 说明 请避免直接使用阿里云账户的 AccessKey。 RAM子账号AccessKey RAM (Resource Access Management) 是阿里云提供的资源访问控制服务。RAM账号AK指的是通过RAM被授权的AK。这组AK只能按照RAM定义的规则去访问Bucket里的资源。通过RAM,您可以集中管理您的用户(比如员工、系统或应用程序),以及控制用户可以访问您名下哪些资源的权限。比如能够限制您的用户只拥有对某一个Bucket的读权限。子账号是从属于主账号的,并且这些账号下不能拥有实际的任何资源,所有资源都属于主账号。 STS账号AccessKey STS(Security Token Service)是阿里云提供的临时访问凭证服务。STS账号AK指的是通过STS颁发的AK。这组AK只能按照STS定义的规则去访问Bucket里的资源。 身份验证具体实现 目前主要有三种身份验证方式: AK验证 RAM验证 STS验证 当用户以个人身份向OSS发送请求时,其身份验证的实现如下: 用户将发送的请求按照OSS指定的格式生成签名字符串。 用户使用AccessKeySecret对签名字符串进行加密产生验证码。 OSS收到请求以后,通过AccessKeyId找到对应的AccessKeySecret,以同样的方法提取签名字符串和验证码。 如果计算出来的验证码和提供的一样即认为该请求是有效的。 否则,OSS将拒绝处理这次请求,并返回HTTP 403错误。 对于用户来说可以直接使用OSS提供的SDK,配合不同类型的AccessKey即可实现不同的身份验证。 权限控制 针对存放在Bucket的Object的访问,OSS提供了多种权限控制,主要有: Bucket级别权限 Object级别权限 账号级别权限(RAM) 临时账号权限(STS) Bucket级别权限 Bucket权限类型 OSS提供ACL(Access Control List)权限控制方法,OSS ACL提供Bucket级别的权限访问控制,Bucket目前有三种访问权限:public-read-write,public-read和private,它们的含义如下: 权限值 中文名称 权限对访问者的限制 public-read-write 公共读写 任何人(包括匿名访问)都可以对该Bucket中的Object进行读/写/删除操作;所有这些操作产生的费用由该Bucket的Owner承担,请慎用该权限。 public-read 公共读,私有写 只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行写/删除操作;任何人(包括匿名访问)可以对Object进行读操作。 private 私有读写 只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行读/写/删除操作;其他人在未经授权的情况下无法访问该Bucket内的Object。 Bucket权限设定和读取方法 功能使用参考: API:Put BucketACL SDK:Java SDK-设置Bucket ACL 控制台:创建Bucket权限设置 API:Get BucketACL SDK:Java SDK-获取Bucket ACL Object级别权限 Object权限类型 OSS ACL也提供Object级别的权限访问控制。目前Object有四种访问权限:private, public-read, public-read-write, default。Put Object ACL操作通过Put请求中的“x-oss-object-acl”头来设置,这个操作只有Bucket Owner有权限执行。 权限值 中文名称 权限对访问者的限制 public-read-write 公共读写 该ACL表明某个Object是公共读写资源,即所有用户拥有对该Object的读写权限。 public-read 公共读,私有写 该ACL表明某个Object是公共读资源,即非Object Owner只有该Object的读权限,而Object Owner拥有该Object的读写权限。 private 私有读写 该ACL表明某个Object是私有资源,即只有该Object的Owner拥有该Object的读写权限,其他的用户没有权限操作该Object。 default 默认权限 该ACL表明某个Object是遵循Bucket读写权限的资源,即Bucket是什么权限,Object就是什么权限。 说明 如果没有设置Object的权限,即Object的ACL为default,Object的权限和Bucket权限一致。 如果设置了Object的权限,Object的权限大于Bucket权限。举个例子,如果设置了Object的权限是public-read,无论Bucket是什么权限,该Object都可以被身份验证访问和匿名访问。 Object权限设定和读取方法 功能使用参考: API:Put Object ACL SDK:Java SDK-ObjectACL 中设定Object ACL API:Get Object ACL SDK:Java SDK-ObjectACL 中读取Object ACL 账号级别权限(RAM) 使用场景 如果您购买了云资源,您的组织里有多个用户需要使用这些云资源,这些用户只能共享使用您的云账号AccessKey。这里有两个问题: 您的密钥由多人共享,泄露的风险很高。 您无法控制特定用户能访问哪些资源(比如Bucket)的权限。 解决方法:在您的阿里云账号下面,通过RAM可以创建具有自己AccessKey的子用户。您的阿里云账号被称为主账号,创建出来的账号被称为子账号,使用子账号的AccessKey只能使用主账号授权的操作和资源。 具体实现 有关RAM详情,请参考RAM用户手册。 对于授权中需要的Policy的配置方式可以参考本章最后一节:RAM和STS授权策略(Policy)配置。 临时账号权限(STS) 使用场景 对于您本地身份系统所管理的用户,比如您的App的用户、您的企业本地账号、第三方App,也有直接访问OSS资源的可能,将这部分用户称为联盟用户。此外,用户还可以是您创建的能访问您的阿里云资源的应用程序。 对于这部分联盟用户,通过阿里云STS (Security Token Service) 服务为阿里云账号(或RAM用户)提供短期访问权限管理。您不需要透露云账号(或RAM用户)的长期密钥(如登录密码、AccessKey),只需要生成一个短期访问凭证给联盟用户使用即可。这个凭证的访问权限及有效期限都可以由您自定义。您不需要关心权限撤销问题,访问凭证过期后会自动失效。 用户通过STS生成的凭证包括安全令牌(SecurityToken)、临时访问密钥(AccessKeyId, AccessKeySecret)。使用AccessKey方法与您在使用阿里云账户或RAM用户AccessKey发送请求时的方法相同。此外还需要注意的是在每个向OSS发送的请求中必须携带安全令牌。 具体实现 STS安全令牌、角色管理和使用相关内容详情,请参考RAM用户指南中的角色管理。关键是调用STS服务接口AssumeRole来获取有效访问凭证即可,也可以直接使用STS SDK来调用该方法。 RAM和STS应用场景实践 对于不同的应用场景,涉及到的访问身份验证方式可能存在差异。下面以几种典型的应用场景来说明访问身份验证中几种使用方式。 以一个移动App举例。假设您是一个移动App开发者,打算使用阿里云OSS服务来保存App的终端用户数据,并且要保证每个App用户之间的数据隔离,防止一个App用户获取到其它App用户的数据。 方式一:使用AppServer来做数据中转和数据隔离如上图所示,您需要开发一个AppServer。只有AppServer能访问云服务,ClientApp的每次读写数据都需要通过AppServer,AppServer来保证不同用户数据的隔离访问。 对于该种使用方式,使用阿里云账号或者RAM账号提供的密钥来进行签名验证访问。建议您尽量不要直接使用阿里云账号(主账号)的密钥访问OSS,避免出现安全问题。 方式二:使用STS让用户直接访问OSS STS方案描述如下图所示:方案的详细描述如下: App用户登录。App用户和云账号无关,它是App的终端用户,AppServer支持App用户登录。对于每个有效的App用户来说,需要AppServer能定义出每个App用户的最小访问权限。 AppServer请求STS服务获取一个安全令牌(SecurityToken)。在调用STS之前,AppServer需要确定App用户的最小访问权限(用Policy语法描述)以及授权的过期时间。然后通过扮演角色(AssumeRole)来获取一个代表角色身份的安全令牌。 STS返回给AppServer一个有效的访问凭证,包括一个安全令牌(SecurityToken)、临时访问密钥(AccessKeyId, AccessKeySecret)以及过期时间。 AppServer将访问凭证返回给ClientApp。ClientApp可以缓存这个凭证。当凭证失效时,ClientApp需要向AppServer申请新的有效访问凭证。比如,访问凭证有效期为1小时,那么ClientApp可以每30分钟向AppServer请求更新访问凭证。 ClientApp使用本地缓存的访问凭证去请求Aliyun Service API。云服务会感知STS访问凭证,并会依赖STS服务来验证访问凭证,正确响应用户请求。 RAM和STS授权策略(Policy)配置 对于RAM或者STS授权中使用Policy,详细规则如下。 示例 先看下面的一个Policy示例: { "Version": "1", "Statement": [ { "Action": [ "oss:GetBucketAcl", "oss:ListObjects" ], "Resource": [ "acs:oss:*:1775305056529849:mybucket" ], "Effect": "Allow", "Condition": { "StringEquals": { "acs:UserAgent": "java-sdk", "oss:Prefix": "foo" }, "IpAddress": { "acs:SourceIp": "192.168.0.1" } } }, { "Action": [ "oss:PutObject", "oss:GetObject", "oss:DeleteObject" ], "Resource": [ "acs:oss:*:1775305056529849:mybucket/file*" ], "Effect": "Allow", "Condition": { "IpAddress": { "acs:SourceIp": "192.168.0.1" } } } ] } 这是一个授权的Policy,用户用这样的一个Policy通过RAM或STS服务向其他用户授权。Policy当中有一个Statement(一条Policy当中可以有多条Statement)。Statement里面规定了相应的Action、Resource、Effect和Condition。 这条Policy把用户自己名下的mybucket和mybucket/file*这些资源授权给相应的用户,并且支持GetBucketAcl、GetBucket、PutObject、GetObject和DeleteObject这几种操作。Condition中的条件表示UserAgent为java-sdk,源IP为192.168.0.1的时候鉴权才能通过,被授权的用户才能访问相关的资源。Prefix这个Condition是在GetBucket(ListObjects)的时候起作用的,关于这个字段的解释详见OSS的API文档。 配置细则 Version Version定义了Policy的版本,本文档中sw2q的配置方式,设置为1。 Statement 通过Statement描述授权语义,其中可以根据业务场景包含多条语义,每条包含对Action、Effect、Resource和Condition的描述。每次请求系统会逐条依次匹配检查,所有匹配成功的Statement会根据Effect的设置不同分为通过(Allow)、禁止(Deny),其中禁止(Deny)的优先。如果匹配成功的都为通过,该条请求即鉴权通过。如果匹配成功有一条禁止,或者没有任何条目匹配成功,该条请求被禁止访问。 Action Action分为三大类:Service级别操作,对应的是GetService操作,用来列出所有属于该用户的Bucket列表。 Bucket级别操作,对应类似于oss:PutBucketAcl、oss:GetBucketLocation之类的操作,操作的对象是Bucket,它们的名称和相应的接口名称一一对应。 Object级别操作,分为oss:GetObject、oss:PutObject、oss:DeleteObject和oss:AbortMultipartUpload,操作对象是Object。 如想授权某一类的Object的操作,可以选择这几种的一种或几种。另外,所有的Action前面都必须加上oss:,如上面例子所示。Action是一个列表,可以有多个Action。具体的Action和API接口的对应关系如下: Service级别 API Action GetService(ListBuckets) oss:ListBuckets Bucket级别 API Action PutBucket oss:PutBucket GetBucket(ListObjects) oss:ListObjects PutBucketAcl oss:PutBucketAcl DeleteBucket oss:DeleteBucket GetBucketLocation oss:GetBucketLocation GetBucketAcl oss:GetBucketAcl GetBucketLogging oss:GetBucketLogging PutBucketLogging oss:PutBucketLogging DeleteBucketLogging oss:DeleteBucketLogging GetBucketWebsite oss:GetBucketWebsite PutBucketWebsite oss:PutBucketWebsite DeleteBucketWebsite oss:DeleteBucketWebsite GetBucketReferer oss:GetBucketReferer PutBucketReferer oss:PutBucketReferer GetBucketLifecycle oss:GetBucketLifecycle PutBucketLifecycle oss:PutBucketLifecycle DeleteBucketLifecycle oss:DeleteBucketLifecycle ListMultipartUploads oss:ListMultipartUploads PutBucketCors oss:PutBucketCors GetBucketCors oss:GetBucketCors DeleteBucketCors oss:DeleteBucketCors PutBucketReplication oss:PutBucketReplication GetBucketReplication oss:GetBucketReplication DeleteBucketReplication oss:DeleteBucketReplication GetBucketReplicationLocation oss:GetBucketReplicationLocation GetBucketReplicationProgress oss:GetBucketReplicationProgress Object级别 API Action GetObject oss:GetObject HeadObject oss:GetObject PutObject oss:PutObject PostObject oss:PutObject InitiateMultipartUpload oss:PutObject UploadPart oss:PutObject CompleteMultipart oss:PutObject DeleteObject oss:DeleteObject DeleteMultipartObjects oss:DeleteObject AbortMultipartUpload oss:AbortMultipartUpload ListParts oss:ListParts CopyObject oss:GetObject,oss:PutObject UploadPartCopy oss:GetObject,oss:PutObject AppendObject oss:PutObject GetObjectAcl oss:GetObjectAcl PutObjectAcl oss:PutObjectAcl Resource Resource指代的是OSS上面的某个具体的资源或者某些资源(支持*通配),resource的规则是acs:oss:{region}:{bucket_owner}:{bucket_name}/{object_name}。对于所有Bucket级别的操作来说不需要最后的斜杠和{object_name},即acs:oss:{region}:{bucket_owner}:{bucket_name}。Resource也是一个列表,可以有多个Resource。其中的region字段暂时不做支持,设置为*。 Effect Effect代表本条的Statement的授权的结果,分为Allow和Deny,分别指代通过和禁止。多条Statement同时匹配成功时,禁止(Deny)的优先级更高。 例如,期望禁止用户对某一目录进行删除,但对于其他文件有全部权限: { "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:*" ], "Resource": [ "acs:oss:*:*:bucketname" ] }, { "Effect": "Deny", "Action": [ "oss:DeleteObject" ], "Resource": [ "acs:oss:*:*:bucketname/index/*", ] } ] } Condition Condition代表Policy授权的一些条件,上面的示例里面可以设置对于acs:UserAgent的检查、acs:SourceIp的检查、还有oss:Prefix这项用来在GetBucket的时候对资源进行限制。 OSS支持的Condition如下: condition 功能 合法取值 acs:SourceIp 指定ip网段 普通的ip,支持*通配 acs:UserAgent 指定http useragent头 字符串 acs:CurrentTime 指定合法的访问时间 ISO8601格式 acs:SecureTransport 是否是https协议 “true”或者”false” oss:Prefix 用作ListObjects时的prefix 合法的object name 更多示例 针对具体场景更多的授权策略配置示例,可以参考教程示例:控制存储空间和文件夹的访问权限和OSS授权常见问题。 Policy在线图形化便捷配置工具,请单击这里。 最佳实践 RAM和STS使用指南
2019-12-01 23:12:47 0 浏览量 回答数 0

问题

荆门开诊断证明-scc

(微)电〗【186-6605-3854〗号【精品问答】Java技术1000问(1) 问问小秘 2019-11-15 11:24:15 9099 为了方便Java开发者快速找到相关技术问题和答案,开发...
游客5k2abgdj3m2ti 2019-12-01 22:09:00 1 浏览量 回答数 0

问题

【精品问答】Java技术1000问(1)

为了方便Java开发者快速找到相关技术问题和答案,开发者社区策划了Java技术1000问内容,包含最基础的如何学Java、实践中遇到的技术问题、RocketMQ面试、Java容器部署实践等维度内容。 我们会以每...
问问小秘 2019-12-01 21:57:43 39926 浏览量 回答数 17
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 企业建站模板