• 关于

    COM格式出问题什么情况

    的搜索结果

问题

用hx写js的时候,它不会自己格适化,在后边加分号也不行

游客mxpnxp6g3cq7o 2019-12-01 19:48:40 3 浏览量 回答数 0

问题

C语言基础 【精品问答合集】

马铭芳 2019-12-01 20:09:24 24451 浏览量 回答数 13

问题

springboot项目启动问题

刘刚_ 2020-05-23 21:05:56 1 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

问题

【iOS学习全家桶】190道iOS热门问题,阿里百位技术专家答疑解惑

管理贝贝 2019-12-01 20:07:23 5197 浏览量 回答数 1

问题

域名相关

麒麟论坛 2019-12-01 19:38:53 2165 浏览量 回答数 3

问题

【活动结束】分享业务场景 赢取SSD公测资格 更有多重好礼等你拿

xiaofanqie 2019-12-01 21:19:53 20779 浏览量 回答数 36

问题

【Java学习全家桶】1460道Java热门问题,阿里百位技术专家答疑解惑

管理贝贝 2019-12-01 20:07:15 27612 浏览量 回答数 19

问题

从HTML中攫取你所需的信息:报错

kun坤 2020-06-08 11:01:51 3 浏览量 回答数 1

问题

MaxCompute百问集锦(持续更新20171011)

隐林 2019-12-01 20:19:23 38430 浏览量 回答数 18

问题

搞清楚这些,你就是域名高手——域名百问大合集

yq传送门 2019-12-01 19:38:17 24482 浏览量 回答数 41

问题

【精品回答】视频点播

montos 2020-04-09 09:57:05 5 浏览量 回答数 1

问题

《公交线路客流预测》攻略-附平台mr示例代码

楠兮 2019-12-01 21:31:10 16683 浏览量 回答数 5

问题

使用智能手机随时随地管理云服务器

leehon 2019-12-01 21:28:54 14004 浏览量 回答数 7

问题

程序员报错QA大分享(1)

问问小秘 2020-06-18 15:46:14 8 浏览量 回答数 1

问题

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

问问小秘 2019-12-01 21:57:48 454222 浏览量 回答数 19

问题

使用HTTPDNS时该如何API访问

猫饭先生 2019-12-01 21:51:27 1353 浏览量 回答数 0

问题

log4j 配置祥解:报错

kun坤 2020-06-14 15:04:10 0 浏览量 回答数 1

回答

详细解答可以参考官方帮助文档  各运营商 DNS 也就是“本地 DNS”,主要是指各地电信运营商提供的域名解析服务器。 您的网站、邮箱等应用的域名,通过设置域名解析来达到访问效果。互联网的 DNS 提供正常的域名解析指向服务,而您本地电脑设置的 DNS 服务器,则是获取互联网上的这些解析地址,本地 DNS 是否正常,直接决定了能否上网或顺利打开网站。一般来说系统内是采用自动设置 DNS 服务器地址,环境多样性造成有时候会出现一些问题,如以下例子,我们需要自行更改自己电脑的 DNS 来进行解决: 在访问网站的过程中,我们或许经常会遭遇无法访问网页的现象,遇到这种现象时,相信多数人会认为是网络掉线,或者是目标网站出现了问题,可是在一番仔细排查之后,并不是由这些因素引起的,那么究竟是什么原因让网页内容无法打开呢? 事实上,在网络连接以及目标服务器都正常的情况下,造成网页无法打开现象最可能的原因就是 DNS 服务发生了意外,导致网站地址被无法正常解析,就像开车找不到目的地了,而且自动设置的DNS 服务运行不正常的现象十分常见。那么如何能够确认网页打开故障就是 DNS 服务引起的呢?遇到 DNS 服务运行不正常时,我们又该如何让 DNS 服务快速恢复常态呢? 通常情况下,我们访问某个目标网站时都是通过输入形如“www.aaa.com”格式的网址来完成访问任务的,以域名的形式来访问网站内容,输入的网站地址会被自动解析翻译成 IP 地址;一旦 DNS 服务器运行不正常,无法提供地址解析服务或者将域名解析成错误的 IP 地址时,我们就无法通过网站域名的形式打开目标站点的页面内容了。 在遇到网页内容无法打开,并且怀疑 DNS 服务运行不正常时,我们首先要做的事情就是可以利用 Windows 系统自带的 nslookup 命令来确认一下本地的 DNS 服务是否真的运行不正常,下面就是确认 DNS 服务运行是否正常的具体操作步骤: 首先在本地工作站系统桌面中打开“开始”菜单,并执行其中的“运行”命令,从弹出的系统对话框中输入字符串命令“cmd”,单击“确定”按钮后,将系统屏幕切换到 MS-DOS 命令行工作模式; 其次在 DOS 命令行中输入字符串命令“nslookup -q=ns www.net.cn”,单击回车键后要是在地址解析过程中 DNS 服务运行不正常的话,那我们会在结果界面中只看到“DNS request timed out,timeout was 2 seconds”这样的提示信息。   在确认网站内容无法打开是由于地址不能被解析后,我们下一步就是要进行 DNS 修改,进入到本地工作站的 TCP/IP 属性设置窗口,将 DNS 地址更换成其他能够运行正常的 DNS 服务器地址,就能解决无法打开网页的问题了,如下图中举例为 google 和万网提供的 DNS 地址,您也可以在网上搜索其他的 DNS 使用。 如您在一个内部网络中,可以请单位网络管理人员检查一下局域网内部的 DNS 服务器是否运行正常,只要解决了 DNS 服务器的运行故障,一般就能够顺利解决网页无法打开故障了。 (图中以win7系统为例,如XP系统,也可在控制面板中找到网络与连接,之后具体更改流程则是一样的)    l ?例1: google 提供的 DNS :8.8.8.8和8.8.4.4    例2:万网的 DNS:223.5.5.5 和 223.6.6.6 因为 DNS 服务受到本身与网络线路等方面的因素,所以遇到 DNS 服务运行不正常的现象是有小机率发生的事情,面对这种故障现象我们只要依照本文所提供的应对要决进行逐一尝试,相信 DNS 解析错误故障一定会快速被排除掉。      

2019-12-01 23:32:18 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档  各运营商 DNS 也就是“本地 DNS”,主要是指各地电信运营商提供的域名解析服务器。 您的网站、邮箱等应用的域名,通过设置域名解析来达到访问效果。互联网的 DNS 提供正常的域名解析指向服务,而您本地电脑设置的 DNS 服务器,则是获取互联网上的这些解析地址,本地 DNS 是否正常,直接决定了能否上网或顺利打开网站。一般来说系统内是采用自动设置 DNS 服务器地址,环境多样性造成有时候会出现一些问题,如以下例子,我们需要自行更改自己电脑的 DNS 来进行解决: 在访问网站的过程中,我们或许经常会遭遇无法访问网页的现象,遇到这种现象时,相信多数人会认为是网络掉线,或者是目标网站出现了问题,可是在一番仔细排查之后,并不是由这些因素引起的,那么究竟是什么原因让网页内容无法打开呢? 事实上,在网络连接以及目标服务器都正常的情况下,造成网页无法打开现象最可能的原因就是 DNS 服务发生了意外,导致网站地址被无法正常解析,就像开车找不到目的地了,而且自动设置的DNS 服务运行不正常的现象十分常见。那么如何能够确认网页打开故障就是 DNS 服务引起的呢?遇到 DNS 服务运行不正常时,我们又该如何让 DNS 服务快速恢复常态呢? 通常情况下,我们访问某个目标网站时都是通过输入形如“www.aaa.com”格式的网址来完成访问任务的,以域名的形式来访问网站内容,输入的网站地址会被自动解析翻译成 IP 地址;一旦 DNS 服务器运行不正常,无法提供地址解析服务或者将域名解析成错误的 IP 地址时,我们就无法通过网站域名的形式打开目标站点的页面内容了。 在遇到网页内容无法打开,并且怀疑 DNS 服务运行不正常时,我们首先要做的事情就是可以利用 Windows 系统自带的 nslookup 命令来确认一下本地的 DNS 服务是否真的运行不正常,下面就是确认 DNS 服务运行是否正常的具体操作步骤: 首先在本地工作站系统桌面中打开“开始”菜单,并执行其中的“运行”命令,从弹出的系统对话框中输入字符串命令“cmd”,单击“确定”按钮后,将系统屏幕切换到 MS-DOS 命令行工作模式; 其次在 DOS 命令行中输入字符串命令“nslookup -q=ns www.net.cn”,单击回车键后要是在地址解析过程中 DNS 服务运行不正常的话,那我们会在结果界面中只看到“DNS request timed out,timeout was 2 seconds”这样的提示信息。   在确认网站内容无法打开是由于地址不能被解析后,我们下一步就是要进行 DNS 修改,进入到本地工作站的 TCP/IP 属性设置窗口,将 DNS 地址更换成其他能够运行正常的 DNS 服务器地址,就能解决无法打开网页的问题了,如下图中举例为 google 和万网提供的 DNS 地址,您也可以在网上搜索其他的 DNS 使用。 如您在一个内部网络中,可以请单位网络管理人员检查一下局域网内部的 DNS 服务器是否运行正常,只要解决了 DNS 服务器的运行故障,一般就能够顺利解决网页无法打开故障了。 (图中以win7系统为例,如XP系统,也可在控制面板中找到网络与连接,之后具体更改流程则是一样的)    l ?例1: google 提供的 DNS :8.8.8.8和8.8.4.4    例2:万网的 DNS:223.5.5.5 和 223.6.6.6 因为 DNS 服务受到本身与网络线路等方面的因素,所以遇到 DNS 服务运行不正常的现象是有小机率发生的事情,面对这种故障现象我们只要依照本文所提供的应对要决进行逐一尝试,相信 DNS 解析错误故障一定会快速被排除掉。      

2019-12-01 23:32:18 0 浏览量 回答数 0

回答

一 、iOS APP 上架流程简介 1. 申请开发者账号 苹果的开发者账号主要分为个人(Individual)、公司(Company)、企业(Enterprise)、高校(University)四种类型,每年资费分别为$99、$99、$299、免费)。一般开发者申请的都是个人或者公司的,企业的开发者账号开发应用不能发布到App Store,只能企业内部使用。这个申请过程一般可能需要一个星期左右。公司和企业的需要邓白氏码,如果邓白氏码未申请,请先申请邓白氏码,这个过程需要一到两个星期。 创建证书、AppID、生成描述文件 通过 Mac 的钥匙串工具,生成证书请求文件,下载证书,这里需要注意的是下载下来的证书只能在请求该证书的电脑上使用,如果想给其他开发者使用需要将已经导入的证书导出为个人信息交换(.p12)格式供他人使用。 AppID 的创建需要用到项目的 Bundle ID,之后便可以创建描述文件了。 在开发者中心的 iTunes Connect 中配置 App 相关信息 在开发者中心里的 iTunes Connect 里的 APP 选项中新建 APP 项目并配置相应的信息(需要各个版本的屏幕截图,运行模拟器,调到最大(command+1)用 command+s 截图,还有就是一个1024*1024的图标,不能有圆角) 使用 Xcode 打包上传 App 将 2 步骤中申请好的证书和描述文件正确配置到 Xcode 中,设置好Xcode 的一些属性: 在Xcode中选择iOS Device(这里不能选择模拟器) 如果应用不支持横屏,请在 General 选项中将 Landscape Left 和 Landscape Right 两项的勾选去掉 查看版本号和构建版本号 将断点、全局断点、僵尸模式等都去掉 设置为 Release 模式 之后便可选择 Xcode->Product->Archive 打包项目,打包完成后选择 Upload to App Store 上传。如果不想使用 Xcode 上传的话,也可以选择 Export 导出 ipa 文件, 需要注意的是在导出时,必须选择 Save for iOS App Store Deployment。然后通过Application Loader 工具上传 ipa 文件。 提交审核 以上步骤完成后,返回 iTunes Connect 上查看自己的 App 信息,在构建版本中选择刚刚上传的 App 版本,此时有可能显示正在处理,这时可能需要等几分钟再回来查看。选择好版本后点击提交以供审核,这时 App 会变成等待审核状态。 后续 后续就是等待苹果的审核人员审核应用了,如果一切顺利的话,这个过程需要一到两个工作日便可完成审核,当然前提是你的应用符合苹果的审核条款。如果审核不通过,请及时根据反馈信息修改应用,再次提交直到符合要求。审核通过后,如果之前选择已经选择好自动发布,便可在 AppStore 上查看和下载应用了。 二 、iOS 上架审核过程常见的坑与解决方法 1. 问题:用户生成内容(UGC)缺少必要的审核 为了防止非法滥用用户生成的内容,从而给用户提供虚假信息、盗取用户的知识产权,社交应用以及应用当中包含用户生成的信息的应用必须包括下述功能: 过滤不良内容 提供举报机制 后台服务可以提供阻止骚扰用户的行为 提供官方联系方式,让用户可以快速联系到开发商 解决方案: 维秀直播 App 提供了用户实时弹幕功能,所以涉及到了 UGC,他们的处理方法是增加关键词过滤,还有通过房管的方式人工审核,处理违规用户。 问题:应用中使用了 IDFA 被拒绝 IDFA 主要被用于广告中区分设备的作用。AppStore 禁止没有使用广告而采集 IDFA 的 App 上架,所以如果 App 本身没有广告的话,使用第三方 SDK 要注意检查是否含有 IDFA 广告模块。 解决方案: 如果应用本身有集成广告的话,只需要在提交审核的时候勾选正确的广告标识符选项即可。 如果应用本身未集成广告,却包含 IDFA 的话。这种情况一般都是集成的第三方 SDK 中包含 IDFA 导致的。首先寻找是否有不包含 IDFA 的 SDK 版本,如果没有的话可以参考 ShareSDK 的解决方法,通过后台配置在审核期间为应用添加广告,审核完成过后将广告展示去掉。 3. 问题:应用不支持 IPv6网络下使用 2016年6月1号起,苹果的审核人员会在 IPv6 网络上审核你的应用,所以如果你的应用程序无法使用 IPv6 协议,可能会被拒绝。 解决方案: 卓易夺宝和乐动听 App 上架过程中就因为 IPv6 的支持原因被拒。他们的解决方案是: 协调后端人员添加对 IPv6 网络的支持。 App 端更新相关的第三方 SDK,比如使用 ASI 或者 AFN 的版本太低,使用最新的 AFN 即可解决问题。 当然这些做完之后最好在Mac 上面搭建 IPv6网络供测试人员进行完测试再重新发布。 4. 问题:第三方登录、支付、分享未安装应用,提示下载被拒 这个问题其实被拒的原因有两种,第一种是未安装应用没有任何提示,这种情况下相当于应用有无效的按钮所以会被拒;第二种是提示下载对应的第三方 App,这也是苹果所不允许的。 解决方案: 最新的第三方登录等相关的 SDK 目前已知的(微信,QQ,微博)都已经对这种情况做了处理,在未安装的情况下会调用 web 进行登录,所以如果测试过程中发现可以成功在 web 上登录的话可以不做处理。以前在没有这种处理机制的情况下需要开发者调用对应接口,先判断是否安装了相应的第三方 APP,如果未安装,需要隐藏按钮,这样便可轻松过审。 问题:虚拟产品未使用应用内支付(IAP)被拒 根据苹果官方最新的审核条款:如果你希望通过付费才可以解锁你的应用当中的一些功能(例如,订阅内容,游戏货币,游戏关卡,获取优质内容,解锁完整版本),你必须使用应用内付费(IAP)。如果这种情况下,应用使用了其他的第三方支付,应用将被拒绝上架。 解决方案: 审核的时候,把相应的虚拟产品隐藏起来,通过后再放出来,此招有风险,可能会受到警告信,甚至被封号,如果用户量小就无所谓了,先把App 搞上架! 审核的时候,走 IAP 的支付方式,审核完成后再通过服务器配置动态切换到支付宝、微信等第三方支付。该法类似于方案1,也存在风险。 学习58同城,让用户去网站购买产品,买了产品的账号到移动端使用功能。 老老实实的使用 IAP 吧。 6. 问题:使用后台定位被拒 关于位置服务苹果的审核条款原文如下: 使用位置服务的应用程序必须提供和位置服务直接相关的功能。使用基于位置的API不允许用于提供紧急服务,或者实现自动控制车辆、飞行器以及其他设备(小型的设备例如小型无人机和玩具例外),远程控制汽车警报系统等。在收集、传输和使用用户的位置数据之前,请确保你已经取得了用户的同意。 如果应用程序使用了后台定位服务,务必在应用当中阐明其目的。并且使用后台定位的话需要提供一个明确的提醒告诉用户这么做会加快电量消耗。 一般应用在这一块被拒的原因有以下几种: 应用根本不需要定位功能。 应用需要定位功能,但是只需要短暂的获取少数的用户的位置,比如美团,新闻类的应用需要获得当前用户的所在城市,却使用了后台定位模式。 应用确实需要使用后台定位,比如打车类软件,但是应用中却没有任何界面展示这些定位数据。 解决方案: 如果你的应用根本不需要定位功能,但是还是在 info.plist 里面添加了 location in the UIBackgroundModes key ,那么在 plist 文件里面移除 UIBackgroundModes key 就可以,这中情况较少,新手小白会犯这种错误。 如果只是简单获取位置不需要使用后台定位,只需要去掉info.plist 的文件中的 UIBackgroundModes 即可。 这种情况比较复杂,推荐的做法是通过表格或者轨迹展示出后台定位的数据,再提交审核的时候告诉苹果那个功能需要后台定位,具体展示后台定位的 数据在那个界面,最后需要 Continued use of GPS running in the background can dramatically decrease battery life加到 App 描述里 面,可以参考滴滴出行的描述,否则也会被拒绝。 7. 问题:info.plist 权限配置被拒 iOS 10 之后如果需要调用相机,蓝牙等设备时,需要在 info.plist 文件中进行相应的配置,否则应用会直接崩溃,在 iOS 10 之前则是无法访问。另外,如果在 info.plist 中调用了配置了权限在应用中却没有使用到也是会被拒的。 解决方案: 一定要注意自己的 App 在使用中用到了哪些权限,不要添加无用的权限,也不要缺少必要的权限。 问题:应用提示更新被拒 应用内不能有任何提示更新应用的字样,且应用的更新只能通过 AppStore。因为苹果对于应用的更新有自己的一套策略,所以禁止应用本身提供更新方式,只要应用内出现。 解决方案: 如果不是很必要的话,尽量将应用内涉及到应用更新的部分去掉。如果真的需要使用应用更新,推荐的方法是应用启动的时候获取下应用在 AppStore 上面的版本号,与自己的版本号进行比较,当自己的版本号小于 AppStore 上面的版本号时,提示更新,否则的话不显示更新相关的内容。 问题:夺宝(抽奖)类应用被拒 根据 AppStore 审核准则 20.4 的规定,抽奖卷或抽奖参与权的购买,不论是透过第三方支付渠道或者余额扣款实现,都不能够在 app 内执行。 解决方案: 卓易夺宝 App 上架过程中遇到的问题,最后的解决方法是在审核过程中,所有的支付行为都跳转到 Safari 浏览器上面进行,审核完成后再使用支付宝等 app 平台支付。 问题:隐私条款问题被拒 在未获得用户事先允许,或未告知用户信息将被如何,在哪里使用的情况下,应用不可以传输用户数据。 解决方案: 《网站服务协议》《隐私条款》这些都不要少,注册时候让用户可勾选。另外注明需要的用户信息用来做什么。 问题:未提供测试账号被拒 如果应用中有需要用到账号或者其他资源的(例如:一个二维码)才能使用的一些功能,但未提供给苹果,可能会被拒绝上架。原因是苹果审核人员无法测试这些功能。 解决方案: 提供一个有效的测试帐号以及登录信息,并提供测试功能必要的的硬件和资源(例如,一个测试用的二维码) 问题:未通过 HTTPS 访问被拒 App Transport Security(ATS) 是 Apple 为增强 iOS App 网络通信安全提出的安全功能,适用于 iOS App 和 App Extension;在启用 ATS 之后,它会强制应用通过 HTTPS(而不是 HTTP )连接网络服务。 WWDC 2016上提出,2016年底或2017年初,具体时间未定。App Store 上架审核加强对 ATS 配置的 review,即强制应用必须通过 HTTPS 连接网络服务,而不是随手将 NSAllowsArbitraryLoads 置为 YES,否则审核不予通过。 解决方案: ATS 的提出,是为了在系统层面保障 iOS APP 网络通信的安全;Apple 只所以加强对 ATS 配置的审核,是为了防止开发者们遇到ATS相关的场景时,只是简单地将 ATS完全关闭(只要没有强制性措施,开发者会这么做);在此基础上,App 审核同样会遵循原则:App Review will require "reasonable justification" for most ATS exceptions。 Apple 官方给出的可以通过审核的声明 demo 如下: 必须使用第三方提供的服务,但是其没有支持 HTTPS; 必须通过域名连接到设备,但该设备不能支持安全连接; 必须展示不同来源的网页内容,但是不能基于 NSAllowsArbitraryLoadsInWebContent 支持的类(UIWebView / WKWebView)实现; 载入加密的媒体资源并且其中不涉及个人信息。 由于 Apple 官方并没有给出 ATS 审核的完整说明,ATS 审核时什么才是合适合理的声明也没有明确的客观定义,以上 demo 描述仅能作为参照。 参考文章: http://www.jianshu.com/p/b1b77d804254 https://github.com/wg689/Solve-App-Store-Review-Problem 22人点赞 iOS 作者:Jon1993 链接:https://www.jianshu.com/p/a992c88087a5 来源:简书

一只刺猬 2020-03-27 10:03:40 0 浏览量 回答数 0

问题

从BUG库看一个测试开发团队的自我修养

技术小菜鸟 2019-12-01 21:25:45 2799 浏览量 回答数 1

回答

参考:https://www.iteblog.com/archives/2530.html分布式和去中心化(Distributed and Decentralized)Cassandra 是分布式的,这意味着它可以运行在多台机器上,并呈现给用户一个一致的整体。事实上,在一个节点上运行 Cassandra 是没啥用的,虽然我们可以这么做,并且这可以帮助我们了解它的工作机制,但是你很快就会意识到,需要多个节点才能真正了解 Cassandra 的强大之处。它的很多设计和实现让系统不仅可以在多个节点上运行,更为多机架部署进行了优化,甚至一个 Cassandra 集群可以运行在分散于世界各地的数据中心上。你可以放心地将数据写到集群的任意一台机器上,Cassandra 都会收到数据。对于很多存储系统(比如 MySQL, Bigtable),一旦你开始扩展它,就需要把某些节点设为主节点,其他则作为从节点。但 Cassandra 是无中心的,也就是说每个节点都是一样的。与主从结构相反,Cassandra 的协议是 P2P 的,并使用 gossip 来维护存活或死亡节点的列表。关于 gossip 可以参见《分布式原理:一文了解 Gossip 协议》。去中心化这一事实意味着 Cassandra 不会存在单点失效。Cassandra 集群中的所有节点的功能都完全一样, 所以不存在一个特殊的主机作为主节点来承担协调任务。有时这被叫做服务器对称(server symmetry)。综上所述,Cassandra 是分布式、无中心的,它不会有单点失效,所以支持高可用性。弹性可扩展(Elastic Scalability)可扩展性是指系统架构可以让系统提供更多的服务而不降低使用性能的特性。仅仅通过给现有的机器增加硬件的容量、内存进行垂直扩展,是最简单的达到可扩展性的手段。而水平扩展则需要增加更多机器,每台机器提供全部或部分数据,这样所有主机都不必负担全部业务请求。但软件自己需要有内部机制来保证集群中节点间的数据同步。弹性可扩展是指水平扩展的特性,意即你的集群可以不间断的情况下,方便扩展或缩减服务的规模。这样,你就不需要重新启动进程,不必修改应用的查询,也无需自己手工重新均衡数据分布。在 Cassandra 里,你只要加入新的计算机,Cassandra 就会自动地发现它并让它开始工作。高可用和容错(High Availability and Fault Tolerance)从一般架构的角度来看,系统的可用性是由满足请求的能力来量度的。但计算机可能会有各种各样的故障,从硬件器件故障到网络中断都有可能。如何计算机都可能发生这些情况,所以它们一般都有硬件冗余,并在发生故障事件的情况下会自动响应并进行热切换。对一个需要高可用的系统,它必须由多台联网的计算机构成,并且运行于其上的软件也必须能够在集群条件下工作,有设备能够识别节点故障,并将发生故障的中端的功能在剩余系统上进行恢复。Cassandra 就是高可用的。你可以在不中断系统的情况下替换故障节点,还可以把数据分布到多个数据中心里,从而提供更好的本地访问性能,并且在某一数据中心发生火灾、洪水等不可抗灾难的时候防止系统彻底瘫痪。可调节的一致性(Tuneable Consistency)2000年,加州大学伯克利分校的 Eric Brewer 在 ACM 分布式计算原理会议提出了著名的 CAP 定律。CAP 定律表明,对于任意给定的系统,只能在一致性(Consistency)、可用性(Availability)以及分区容错性(Partition Tolerance)之间选择两个。关于 CAP 定律的详细介绍可参见《分布式系统一致性问题、CAP定律以及 BASE 理论》以及《一篇文章搞清楚什么是分布式系统 CAP 定理》。所以 Cassandra 在设计的时候也不得不考虑这些问题,因为分区容错性这个是每个分布式系统必须考虑的,所以只能在一致性和可用性之间做选择,而 Cassandra 的应用场景更多的是为了满足可用性,所以我们只能牺牲一致性了。但是根据 BASE 理论,我们其实可以通过牺牲强一致性获得可用性。Cassandra 提供了可调节的一致性,允许我们选定需要的一致性水平与可用性水平,在二者间找到平衡点。因为客户端可以控制在更新到达多少个副本之前,必须阻塞系统。这是通过设置副本因子(replication factor)来调节与之相对的一致性级别。通过副本因子(replication factor),你可以决定准备牺牲多少性能来换取一致性。 副本因子是你要求更新在集群中传播到的节点数(注意,更新包括所有增加、删除和更新操作)。客户端每次操作还必须设置一个一致性级别(consistency level)参数,这个参数决定了多少个副本写入成功才可以认定写操作是成功的,或者读取过程中读到多少个副本正确就可以认定是读成功的。这里 Cassandra 把决定一致性程度的权利留给了客户自己。所以,如果需要的话,你可以设定一致性级别和副本因子相等,从而达到一个较高的一致性水平,不过这样就必须付出同步阻塞操作的代价,只有所有节点都被更新完成才能成功返回一次更新。而实际上,Cassandra 一般都不会这么来用,原因显而易见(这样就丧失了可用性目标,影响性能,而且这不是你选择 Cassandra 的初衷)。而如果一个客户端设置一致性级别低于副本因子的话,即使有节点宕机了,仍然可以写成功。总体来说,Cassandra 更倾向于 CP,虽然它也可以通过调节一致性水平达到 AP;但是不推荐你这么设置。面向行(Row-Oriented)Cassandra 经常被看做是一种面向列(Column-Oriented)的数据库,这也并不算错。它的数据结构不是关系型的,而是一个多维稀疏哈希表。稀疏(Sparse)意味着任何一行都可能会有一列或者几列,但每行都不一定(像关系模型那样)和其他行有一样的列。每行都有一个唯一的键值,用于进行数据访问。所以,更确切地说,应该把 Cassandra 看做是一个有索引的、面向行的存储系统。Cassandra 的数据存储结构基本可以看做是一个多维哈希表。这意味着你不必事先精确地决定你的具体数据结构或是你的记录应该包含哪些具体字段。这特别适合处于草创阶段,还在不断增加或修改服务特性的应用。而且也特别适合应用在敏捷开发项目中,不必进行长达数月的预先分析。对于使用 Cassandra 的应用,如果业务发生变化了,只需要在运行中增加或删除某些字段就行了,不会造成服务中断。当然, 这不是说你不需要考虑数据。相反,Cassandra 需要你换个角度看数据。在 RDBMS 里, 你得首先设计一个完整的数据模型, 然后考虑查询方式, 而在 Cassandra 里,你可以首先思考如何查询数据,然后提供这些数据就可以了。灵活的模式(Flexible Schema)Cassandra 的早期版本支持无模式(schema-free)数据模型,可以动态定义新的列。 无模式数据库(如 Bigtable 和 MongoDB)在访问大量数据时具有高度可扩展性和高性能的优势。 无模式数据库的主要缺点是难以确定数据的含义和格式,这限制了执行复杂查询的能力。为了解决这些问题,Cassandra 引入了 Cassandra Query Language(CQL),它提供了一种通过类似于结构化查询语言(SQL)的语法来定义模式。 最初,CQL 是作为 Cassandra 的另一个接口,并且基于 Apache Thrift 项目提供无模式的接口。 在这个过渡阶段,术语“模式可选”(Schema-optional)用于描述数据模型,我们可以使用 CQL 的模式来定义。并且可以通过 Thrift API 实现动态扩展以此添加新的列。 在此期间,基础数据存储模型是基于 Bigtable 的。从 3.0 版本开始,不推荐使用基于 Thrift API 的动态列创建的 API,并且 Cassandra 底层存储已经重新实现了,以更紧密地与 CQL 保持一致。 Cassandra 并没有完全限制动态扩展架构的能力,但它的工作方式却截然不同。 CQL 集合(比如 list、set、尤其是 map)提供了在无结构化的格式里面添加内容的能力,从而能扩展现有的模式。CQL 还提供了改变列的类型的能力,以支持 JSON 格式的文本的存储。因此,描述 Cassandra 当前状态的最佳方式可能是它支持灵活的模式。高性能(High Performance)Cassandra 在设计之初就特别考虑了要充分利用多处理器和多核计算机的性能,并考虑在分布于多个数据中心的大量这类服务器上运行。它可以一致而且无缝地扩展到数百台机器,存储数 TB 的数据。Cassandra 已经显示出了高负载下的良好表现,在一个非常普通的工作站上,Cassandra 也可以提供非常高的写吞吐量。而如果你增加更多的服务器,你还可以继续保持 Cassandra 所有的特性而无需牺牲性能。

封神 2019-12-02 02:00:50 0 浏览量 回答数 0

回答

其实我的思路本来就很对,一开始就是这样,但是必须对s1和s2的副本进行操作。 现在附上我的代码。经测试,完全正确。 package _20th; public class A {  private static long count = 0;  private static void f(String s) {   // TODO Auto-generated method stub   StringBuffer stringBuffer = new StringBuffer(s);   f(new StringBuffer(), stringBuffer);  }  private static void f(StringBuffer s1, StringBuffer s2) {   // TODO Auto-generated method stub   if (s2.length() == 0) {    System.out.println(s1.toString());    count++;   } else {    for (int i = 0; i < s2.length(); i++) {     StringBuffer t1 = new StringBuffer(s1);     StringBuffer t2 = new StringBuffer(s2);     t1.append(s2.charAt(i));     t2.deleteCharAt(i);     f(t1, t2);    }   }  }  public static void main(String[] args) {   f("abcde");   System.out.println(count);  } } 最后count的结果是54321=120. ######回复 @李嘉图 : 我擦,牛逼啊!这是怎样一种心情呢!######回复 @wenming199 : 谢谢你,同时提醒各位,细节很重要呀,说这句话的时候,我是含着眼泪的,要不然你思路再好也是扯淡!######回复 @李嘉图 : 这个要求倒是第一次听说,哈哈……总的来说干的不错……######回复 @铂金眼 : 我是想了10几个小时才出的,你们回答好了,我更高兴呀,但是事实是最后还是我找到答案了!我从昨天下午到今天下午,不停地测试,找答案,我付出了很多的!下面的附上代码的我试了,到说这句话的时候都是不太完美的!######我擦,LZ自己提问,自己回答,然后自己设自己为最佳答案,作弊啊! @红薯######我的程序由于,初始的递归里面的循环只循环一次,导致“abc”输出2个,“abcd”输出3个,”abcde“输出4个,都是因为初始的递归只循环一次,这不科学呀!######我从昨天下午,想到今天上午,发现不知道为什么初始的递归只循环一次,为什么?救救我吧!######你的代码格式看着累眼,就没心情看问题了....######看看吗,自己也可以长进的,在帮助别人的同时。######我的win8.1的ie11,那个插件代码的插件不兼容呀,你可以复制到eclipse里面,然后ctrl+shift+f就行了,那样就舒服了!###### 难道我要出“abc”的递归,需要使用   f("abc");   f("bac");   f("cab"); 这不行呀,不符合我的思路呀! ######别告诉我你们都不用递归,学算法的时候,你们都没听!这不科学呀!###### 这代码写的真揪心啊。。。还循环递归new StringBuffer ######stringbuffer对于可变字符串的效率比较高!###### 你删除的索引是i,删除完以后,字符串索引是不是重建了? 你看看是不是因为这个问题? ###### public class Arrange25 { static int i = 0; private static void f(String s) { if (i < s.length()) { System.out.println(s.charAt(i) + s.replace(String.valueOf(s.charAt(i)), "")); i++; f(s); } } public static void main(String[] args) { f("abc"); } }######回复 @李日飞 : 3个字符串 全排列是3 21=6个,就是A3. abc acb bac bca cab cba######回复 @李嘉图 : 给abc现在输出的是这样 abc bac cab 你想变成什么样######回复 @李日飞 : 全排列!######回复 @李嘉图 : 你要什么样的效果######你的全排列思路很好,貌似效率也比较高,但是依然是错的!###### 1. For循环里面用递归? 2. 执行完s1="abc",s2="",打印“abc”,然后 返回上一层递归,此时i++; i=1, s1="ac" s2="b", 然后进入下一层递归,打印出 “acb”,i++,返回上一层递归 发现i=2,For循环已经执行完了,i++,然后返回上一层递归, 此时i=3 s1="",s2="abc" 于是 i<s2.length不成立  程序结束了。 3.问题就出现在程序里的 i 的值不是你预期的那样变化。 ######回复 @李嘉图 : 你说的都是每次 i = 0 开始循环的情况,实际情况不是这样,是我说的那样的。 你可以再看看。######回复 @李嘉图 : 那不就是插空位,先插a , 再插b,有两种情况ab,ba,再插c 有3 2种情况,abc,acb,cab,bac,bca,cba######回复 @wenming199 : 他的这种思路我也会,我是在一个空字符里面按顺序不断地加一个字符进去,作业要求我要这种思路。######假设是对“abc”递归排序,总共会有第一层循环3次,每个第一层包含2第二层,每个第二层包含1个第三层,总共就32*1=6。层和层之间怎么会有干涉呢!第一层的第1次循环执行完了,才会i++de,怎么会想你说的那样!######回复 @李嘉图 : http://pengmj.iteye.com/blog/830978

kun坤 2020-05-31 13:05:19 0 浏览量 回答数 0

问题

【阿里云产品公测】简单日志服务SLS使用评测含教程

mr_wid 2019-12-01 21:08:11 36639 浏览量 回答数 20

回答

在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们战略上 要重 视 它 , 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级?现在很流行的优步(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

问题

使用SeasLog打造PHP项目中的高性能日志组件(一) 400 请求报错 

kun坤 2020-05-30 16:12:25 0 浏览量 回答数 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
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站