• 关于

    单方向可以做什么

    的搜索结果

回答

单算带宽的话,阿里云确实没什么优势。 不过国内的BGP带宽价格普遍都是这个价了。 大多数时候,计算服务器不需要多少带宽,很多情况都可以通过购买额外的按流量计费服务,如OSS和CDN来解决问题。 从系统稳定性方向思考,网站做大之后也应该往这个方向调整。 ------------------------- 回 6楼(ap7980i2i) 的帖子 哈哈,我一向忽略水军的帖子。 在啥地方谈啥内容,谈其它家太多的,明显就是水军。 对水军,只有厌恶
hilyjiang 2019-12-02 03:16:21 0 浏览量 回答数 0

回答

用cache实现session###### 你这个问题描述 真66 不是同一个浏览器  你居然想session共享? 貌似我没在开源看到过过。 单点登录和session共享 ??######回复 @easymbol : 服务器需要存储uid和session之间的映射吧……密码改了,全部的session都要过期######不是,如果写单点登陆的话,那么也就不会出现这个问题了,但是不想用单点登陆,想直接操作session来处理,所以考虑的方向到了session共享###### 当然是考虑做监听啊###### 你如果把这个功能做出来,请告诉我你公司的网址###### 这不太可能吧###### 只能每次操作里面去验证密码是否正确了###### 不需要那么麻烦   在修改密码的的逻辑里添加session相关验证就可以了,当然也可以反过来在session验证的时候添加上密码验证就可以了   没必要搞什么session共享     按照你的这个描述感觉系统应该挺小的,你要是上了session共享后,你会发现牛刀无地用;当然要是用来做研究的可以上    共享session推荐你个中间件mycat###### 如果密码修改了,将除了最后登录的那个客户端以外的其它客户端生成的所有 session 设置为过期,然后其它客户端自然会被踢出,并要求重新登录   这里的前提是,每个客户端拥有各自不同的 session######如何做到在一个浏览器修改密码,seesion过期######这种操作有想过,但是会引出一个问题,就是其他的用户会在同一时段同时请求用户表的查询操作...###### 不同的浏览器之间做session共享...这就有点牛逼了...######最靠谱的办法就是Jfinal说的那样,登录的时候把用户和session映射存起来,修改密码的时候,把其他session给过期就行了,不同的浏览器的session管理机制都不一样,而且在网页代码中,不开发浏览器插件的情况下是无法去改变这些东西的,通常意义的单点登录,是在本地安装有对应的客户端程序才能实现的,纯网页是实现不了的
kun坤 2020-06-06 14:56:36 0 浏览量 回答数 0

回答

Re:【阿里云产品公测】开放搜索服务 opensearch java jdk 应用体验之 机器人 .. 1,关于非全部匹配的召回,希望可以尽快上线。 吧 ---已经排期,预计12月左右上线。 2,是否可以开放分词接口; ---以后会考虑把分词结果返回给用户,这样应该可以实现你的功能吧。单独的api接口暂时没计划,这部分不是opensearch的方向; 3,排序算法上是否可以有更多的文档给予一定的讲解,很多人这方面还是比较弱的 ---目前的文档已经有详细的说明和各个feature的用户及适用场景,我理解你说的应该是怎么跟实际场景做对应吧,这部分我们会加强,你可以看下导入模板中是如何设计的,应该能明白。 4,文档的管理不知道是否可以做一个展示,比如我有8000调数据,是否可以有个地方让我看到都添加了什么数据。 ---是说把目前所有的文档主键列出来吗?这个不是opensearch的重点呢,如果数据量非常大的话,这个功能是不太现实的。 5,opensearch 应该是支持外部网站使用的,但是在文档上没有体现,我在实例化的时候就出现了一些问题,建议这块做一些说明。 ---支持外部网站使用这个是什么意思呢?
zhengmay 2019-12-02 00:43:11 0 浏览量 回答数 0

回答

" 用了两年的时间,终于把这个问题解决了。。######能分享下如何解决的吗###### 分布式事务的基本理论,2PC, QUORUM, PAXOS,系统要达到100w/s的水准靠水平分割 ######好问题,。。。######mark######你的解法是正确可行的,不知道面试官是怎么想的,估计面试官自己都没有答案。 消息队列是可以集群的,最终的瓶颈只是在数据库上面,所以要做多master应该就可以解决了。 如果单库多master还无法解决的话,那就要进行数据库分割。 如果分割了还无法解决的话,那就要采用内存数据库,然后在持久化到磁盘。 灵活运用吧。 ###### 两阶段提交本身属于强一致性模型,你又说做最终一致检查,有点概念不清的嫌疑。 所以面试官在听到你说2PC的时候,估计已经不想跟你扯了, 猜测~~。    其实海量分布式事务的解决方案就是最终一致性模型。 ######因为他的说法中有错别字,我没有看到2pc,这一点他的强一致模型确实和最终一致模型概念不清。楼主本身估计不是做架构的,是根据自己公司原来的架构体系自己总结的一些东西。不过楼主的解决方案的大体方向是可行的。###### 引用来自“jobet”的评论你的解法是正确可行的,不知道面试官是怎么想的,估计面试官自己都没有答案。 消息队列是可以集群的,最终的瓶颈只是在数据库上面,所以要做多master应该就可以解决了。 如果单库多master还无法解决的话,那就要进行数据库分割。 如果分割了还无法解决的话,那就要采用内存数据库,然后在持久化到磁盘。 灵活运用吧。 什么东西一大了,单纯靠数据库,分布式平台等数据工具是解决不了的。一定要结合具体业务特性,大概率下数据分布特征来做模型的重新设计和优化。这就是我说的,大数据的工作,hadoop之类的工具,并不能帮你做什么。还是自身业务模型设计的问题。哈######其实这个问题基本上没有正确的方案,每一个平台根据业务性质都会不同,唯一能够提供的就是一个大体的思虑,其他的根据自己的业务性质自行提炼和优化。###### 引用来自“兮风古道”的评论 两阶段提交本身属于强一致性模型,你又说做最终一致检查,有点概念不清的嫌疑。 所以面试官在听到你说2PC的时候,估计已经不想跟你扯了, 猜测~~。    其实海量分布式事务的解决方案就是最终一致性模型。 二段提交的时候,最后一次commit还是会出错的。。######回复 @jobet : 收到。。我搞错了。。######回复 @Brin想写程序 : 2pc是针对于多数据源的事务处理,也就是分布式事务。你说的这个不是。######回复 @jobet : 问一下mysql的autocommit=false后的,commit和rollback难道不是二段提交的吗?这个应该就是数据库的二段提交吧?######2pc的话,对性能的消耗是很大的。估计面试官是因为听到他说2pc就直接否决了,后续的已经没有兴趣了。###### Brin有什么好办法了,记得 博客里补上######我的解决方案是根据用户顺序处理,也就是用顺序一致性替代绝对一致性,然后用分布式消息队列,用一致性哈希算法,只将一个用户的数据发送给同一个处理者,然后按顺序执行这一个人的操作。所以这个是无锁的,可并行的。###### 引用来自“jobet”的评论你的解法是正确可行的,不知道面试官是怎么想的,估计面试官自己都没有答案。 消息队列是可以集群的,最终的瓶颈只是在数据库上面,所以要做多master应该就可以解决了。 如果单库多master还无法解决的话,那就要进行数据库分割。 如果分割了还无法解决的话,那就要采用内存数据库,然后在持久化到磁盘。 灵活运用吧。 引用来自“中山野鬼”的评论什么东西一大了,单纯靠数据库,分布式平台等数据工具是解决不了的。一定要结合具体业务特性,大概率下数据分布特征来做模型的重新设计和优化。这就是我说的,大数据的工作,hadoop之类的工具,并不能帮你做什么。还是自身业务模型设计的问题。哈 我也觉得是具体业务具体分析,比如在电商平台里面,在怎么分布式,买东西这个过程是一个用户触发的。 所以按照用户对纬度,对资源进行水平分割,应该可以解决大部分问题。 但是但是,最麻烦的是先有很多电商平台非常庞大,而且一开始就没有做这种分割,业务是一团乱麻,没人清楚这个用户的购买行为会影响多少台服务器里面的数据,所以只能寻找比较通用的解决方案。 也就是在某个层面上能彻底解决,现在好像思路还是从rpc层面去解决这个问题。找到统一的一劳永逸的中间价或者说体系结构。。 所以我也很难想明白。。######马克,学习了"
kun坤 2020-05-26 13:15:05 0 浏览量 回答数 0

问题

安全组容器服务安全组规则是什么

查看安全组规则 操作步骤 登录 容器服务管理控制台。单击左侧导航栏中的 [backcolor=transparent]集群。选择所需集群并单击右侧的 [backcolor=transparent]管理。 ...
反向一觉 2019-12-01 21:17:42 2420 浏览量 回答数 0

回答

不矛盾啊,既然是单列,每次访问都是不同的线程,只要注意线程安全问题就可以了啊。所以在你的bean里面不能有成员变量,这样就不会有并发问题啊。######回复 @HUncle : no 3k,我也是新手,自己的理解而已。######回复 @妹夫 : 对,单例特别方便,但是有隐患,3Q######回复 @妹夫 : 还有一个就是单例能在程序中随处获得实例,很方便。个人觉得。######回复 @HUncle : 既然用了spring,都知道spring有依赖注入这么个东西,我们可以把需要依赖的bean交给spring去管理。如果使用了成员变量,操作它的时候就必须保证同步,这就是我说为什么不能使用成员变量,至少我没见过别人系统里会使用spring然后用同步方法去操作内部依赖的bean的。######回复 @HUncle : 单例能保证程序中这个实例是唯一的,减少java的内存回收,所以性能高。我不知道别人在哪些方面用单例,但我在写GUI程序的时候单例用的多,因为GUI程序并发少。并不是说不能存在成员变量,如果存在成员变量的时候你去操作它的时候必须保证线程同步,java中用synchronized。大量使用synchronized会导致性能降低######搜索一下 Bean的作用域,会找到你要的答案。######我说的就是singletion 的情形,此情况下如何处理多请求?######单例多线程######不知道底层如何规避线程安全的######这有矛盾吗?你多个请求过来 不就是多个线程访问单例么? ######有线程安全的问题######我也是有些迷惑,假如是单利的话,成员变量 是有危险的,但是如果每次来的都是不同的线程来调用这个单利 也是没有问题的,或者是单例调用单例应该也是没有问题的,就怕是多个线程重复的访问这个单例!######对的,正有此忧虑######这个问题问的好。 Spring默认的却是单例的,多线程和并发量特别大的情况下需要开发人员自己作出选择。singleton, prototype, request等######singleton的适用场合有哪些?######好像是TreadLocal的bean。前兩天專門查了查。######这个应该是spring自行管理的吧?######没错,核心就是ThreadLocal 去解决######对的,这个问题需要编码人员控制。如果多个线程操作同一个对象,是很危险的。特别是并发模式下。顶你,现在国内软件需要刨根问底的人。###### 学习Spring有段时间了,说说我的认识吧:并不是所有的bean都可以配置成单例的。对于Spring的系统,一般都分为Controller,Service,DAO;对于Service,一般会注入DAO,而DAO就回用到数据连接Connection,我们知道Connection是有状态的,在多线程环境下,肯定会遇到问题,Spring为我们考虑到了这种情况,对此做了特殊处理,只要使用Spring提供的线程绑定资源获取工具得到的Connection就是线程安全的,JDBC或iBatis对应DataSourceUtils,Hibernate对应SessionFactoryUtils,从相应的工具类中获取的Connection,通过了ThreadLocal处理,所以不会出现线程安全问题。另外Spring为我们做了更多事情,我们可以不必自己取获取Connection,Spring为我们提供了DAO模板类,JDBC对应JdbcTemplate,Hibernate对应HibernateTemplate,iBatis对应SqlMapClientTemplate,直接使用模板进行数据访问操作完全不用担心线程安全问题(其内部其实也是调用了相应的工具类)。所以我们的DAO完全可以成为singletion 对象。然后只要使用Spring提供的事务管理,我们的Service也同样可以成为singletion 对象。而我们的Controller,如果只注入了Service,而没有其他状态对象,同样可以成为singletion 对象。当然了,如果还包含其他有状态的成员属性,Spring也是无能为力的,这时候只能定义为request或者其他合适的对象了。 希望对你有所帮助。 ######讲的挺好,其实我只是想知道单例的情况,不过还是感谢你,3Q###### 引用来自“妹夫”的答案 不矛盾啊,既然是单列,每次访问都是不同的线程,只要注意线程安全问题就可以了啊。所以在你的bean里面不能有成员变量,这样就不会有并发问题啊。 我只看过struts源码,它在WEB应用方面,对象默认是非单例化的。其实Spring刚开始的时候不是作为WEB方向使用的,而作为最基本的容器使用的。虽然Spring的对象容器是synchronized的,但是只是容器操作时synchronized的,粒度太大。无法保证安全。而并发是测试过程最难定位的,国内和国外行业的区别就在这里。普通测试还行,但是需要定位到代码的BUG所在范围,就比较困难了。
爱吃鱼的程序员 2020-05-30 21:43:41 0 浏览量 回答数 0

问题

Swarm mode 集群容器服务安全组规则

查看安全组规则 操作步骤 登录 容器服务管理控制台。单击左侧导航栏中的 [backcolor=transparent]集群。选择所需集群并单击右侧的 [backcolor=transparent]管理。 ...
反向一觉 2019-12-01 21:21:18 1282 浏览量 回答数 0

问题

百问百答《文娱智能算法》

UPGC 视频来源主要有哪些? 由正片切条产生的短小视频经用户上传的UPGC 视频问题有哪些? 由用户拍摄上传的UPGC 视频问题有哪些? UPGC 视频和图像质量面临的挑战有哪些࿱...
不语奈何 2021-03-25 13:32:31 19 浏览量 回答数 1

问题

Android关于service的常驻和共享的问题

关于service的一些问题:1.在使用微信和微博时,打开android的"设置-应用-正在运行"里面,能看到微信和微博两个应用同时在运行,里面有各自的进程和服务。请问这是如何实现的?2.现在想给自己的应用加上推送服务,把服务以独立进程运行...
蛮大人123 2019-12-01 20:06:46 1161 浏览量 回答数 1

回答

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

回答

不矛盾啊,既然是单列,每次访问都是不同的线程,只要注意线程安全问题就可以了啊。所以在你的bean里面不能有成员变量,这样就不会有并发问题啊。######回复<aclass="referer"target="_blank">@HUncle:no3k,我也是新手,自己的理解而已。######回复<aclass="referer"target="_blank">@妹夫:对,单例特别方便,但是有隐患,3Q######回复<aclass="referer"target="_blank">@妹夫:还有一个就是单例能在程序中随处获得实例,很方便。个人觉得。######回复<aclass="referer"target="_blank">@HUncle:既然用了spring,都知道spring有依赖注入这么个东西,我们可以把需要依赖的bean交给spring去管理。如果使用了成员变量,操作它的时候就必须保证同步,这就是我说为什么不能使用成员变量,至少我没见过别人系统里会使用spring然后用同步方法去操作内部依赖的bean的。######回复<aclass="referer"target="_blank">@HUncle:单例能保证程序中这个实例是唯一的,减少java的内存回收,所以性能高。我不知道别人在哪些方面用单例,但我在写GUI程序的时候单例用的多,因为GUI程序并发少。并不是说不能存在成员变量,如果存在成员变量的时候你去操作它的时候必须保证线程同步,java中用synchronized。大量使用synchronized会导致性能降低######搜索一下<spanstyle="font-family:Arial;font-size:14px;line-height:26px;background-color:#FFFFFF;">Bean的作用域,会找到你要的答案。######我说的就是singletion的情形,此情况下如何处理多请求?######单例多线程######不知道底层如何规避线程安全的######这有矛盾吗?你多个请求过来不就是多个线程访问单例么?######有线程安全的问题######我也是有些迷惑,假如是单利的话,成员变量是有危险的,但是如果每次来的都是不同的线程来调用这个单利也是没有问题的,或者是单例调用单例应该也是没有问题的,就怕是多个线程重复的访问这个单例!######对的,正有此忧虑######这个问题问的好。Spring默认的却是单例的,多线程和并发量特别大的情况下需要开发人员自己作出选择。singleton,prototype,request等######singleton的适用场合有哪些?######好像是TreadLocal的bean。前兩天專門查了查。######这个应该是spring自行管理的吧?######没错,核心就是ThreadLocal去解决######对的,这个问题需要编码人员控制。如果多个线程操作同一个对象,是很危险的。特别是并发模式下。顶你,现在国内软件需要刨根问底的人。###### 学习Spring有段时间了,说说我的认识吧:并不是所有的bean都可以配置成单例的。对于Spring的系统,一般都分为Controller,Service,DAO;对于Service,一般会注入DAO,而DAO就回用到数据连接Connection,我们知道Connection是有状态的,在多线程环境下,肯定会遇到问题,Spring为我们考虑到了这种情况,对此做了特殊处理,只要使用Spring提供的线程绑定资源获取工具得到的Connection就是线程安全的,JDBC或iBatis对应DataSourceUtils,Hibernate对应SessionFactoryUtils,从相应的工具类中获取的Connection,通过了ThreadLocal处理,所以不会出现线程安全问题。另外Spring为我们做了更多事情,我们可以不必自己取获取Connection,Spring为我们提供了DAO模板类,JDBC对应JdbcTemplate,Hibernate对应HibernateTemplate,iBatis对应SqlMapClientTemplate,直接使用模板进行数据访问操作完全不用担心线程安全问题(其内部其实也是调用了相应的工具类)。所以我们的DAO完全可以成为<spanstyle="color:#FF6600;font-family:Verdana,sans-serif,宋体;line-height:normal;background-color:#FFFFFF;">singletion<spanstyle="color:#000000;">对象。然后只要使用Spring提供的事务管理,我们的Service也同样可以成为<spanstyle="color:#FF6600;font-family:Verdana,sans-serif,宋体;line-height:normal;background-color:#FFFFFF;">singletion<spanstyle="color:#000000;">对象。而我们的Controller,如果只注入了Service,而没有其他状态对象,同样可以成为<spanstyle="color:#FF6600;font-family:Verdana,sans-serif,宋体;line-height:normal;background-color:#FFFFFF;">singletion <spanstyle="color:#000000;">对象。当然了,如果还包含其他有状态的成员属性,Spring也是无能为力的,这时候只能定义为request或者其他合适的对象了。 希望对你有所帮助。######讲的挺好,其实我只是想知道单例的情况,不过还是感谢你,3Q######<divclass="ref"> 引用来自“妹夫”的答案<divclass="ref_body">不矛盾啊,既然是单列,每次访问都是不同的线程,只要注意线程安全问题就可以了啊。所以在你的bean里面不能有成员变量,这样就不会有并发问题啊。<divclass="a_body">我只看过struts源码,它在WEB应用方面,对象默认是非单例化的。其实Spring刚开始的时候不是作为WEB方向使用的,而作为最基本的容器使用的。虽然Spring的对象容器是synchronized的,但是只是容器操作时synchronized的,粒度太大。无法保证安全。而并发是测试过程最难定位的,国内和国外行业的区别就在这里。普通测试还行,但是需要定位到代码的BUG所在范围,就比较困难了。
优选2 2020-06-09 15:38:13 0 浏览量 回答数 0

回答

  Tomcat 只是一个轻量级的容器,连接模型上还是采用了一请求,一线程的模型,这种模型最大的缺点是对延迟非常敏感,因为响应慢会导致新请求无可用连接可用。       但是,虽然理论上我们可以将配置中线程池设置到一个足够大的值,但是我们通常不建议这样做。更多的线程意味着更多的CPU切换时间。   解决这个问题的方案是 降低延迟,增加机器。 ######我也想换T_T######这是后台资源响应慢吧,例如数据库或者本地文件IO。可以分析看下各线程都在等待什么资源######大概知道卡在什么地方 但是对同样的地址压测却不会出现线程满的情况。。######可以看看最近网站上是不是有些会被请求的资源随着时间的增长而爆满了,比如数据库,文件目录等等,首先要找出为什么不卡现在卡的原因再做针对性的优化。######大概知道卡在什么地方 但是对同样的地址压测却不会出现线程满的情况。。。######达到极限了,你还是试一下resin,单机性能要高于tomcat######环境上暂时没法换中间件。。诶###### 不应该一味的从线程池增大的方向去解决性能问题,如果查询较慢,或者有比较复杂的算法、递归等操作,增大线程池没有意义的。 应该首先找到性能瓶颈。我建议先把线程池降下来。 ######从tomcat的管理页面知道大概都卡在什么地方 但是我自己对同样的地址压测却出不来线程阻塞的情况。。###### 换tomcat8 数据库数据量巨大?导致查询阻塞导致后来的线程都并发? 硬盘快挂了? ######tomcat7和8性能差很多么??######nginx 前端控制最大连接数######是想上nginx来着 但是目前没有条件 以及控制了最大连接数如果满了不是一样么= =######每个请求响应要多久 线程阻塞的话就没办法了  线程越多 切换越慢 ###### 查下日志,看下10:30 - 10:40有什么操作。 这期间响应时间明显变慢了。这期间如果有长时间未响应线程,线程池中的 线程很容易被耗尽。 ######不好查。。都是用户的操作###### compression="on" 这个关闭掉,让前面的Web服务器(Nginx / Apache)来做压缩。 ######那也关掉,压缩也是比较占计算资源的。######前面没有WEB服务器= =
爱吃鱼的程序员 2020-05-30 23:52:28 0 浏览量 回答数 0

回答

第一讲打卡 A1 B A2 云平台相对传统的虚拟化容器来讲,有强大的技术支持,完全将底层硬件设备归为整体,再其之上进行整合处理,很好的利用当前系统内的资源,同时进行分配资源 A3 SaaS、PaaS、IaaS都属于云计算服务,也就是云计算+服务 IaaS:用户可以在云服务提供商提供的基础设施上部署和运行任何软件,包括操作系统和应用软件 PaaS:PaaS给用户提供的能力是使用由云服务提供商支持的编程语言、库、服务以及开发工具来创建、开发应用程序并部署在相关的基础设施上 SaaS:SaaS给用户提供的能力是使用在云基础架构上运行的云服务提供商的应用程序。 A4 Java,Devops。 第二讲打卡 A1 不需要 A2 轻量级web服务器/反向代理服务器 四层/七层负载均衡 占用内存少,并发强丰富的插件功能模块 ###A3 不可以,SLB的四层采用的是LVS A4 一次连接:对数据仅做转发作用 二次连接:要增加与后端服务的连接 应用场景:一次连接会使得整个负载均衡的性能得到一定的高度,而二次连接较一次连接多一中间一次数据包的处理以及增加一次tcp连接,性能方面不如一次的,但是安全等等应该会有所保障。(个人觉得适用场景:一次可以类似于udp一样的存在,二次相当于tcp一样存在) A5 I/O 5分钟法则,什么情况下适用:::个人看法觉得高访问数据,热点数据都需要放在缓存中,当然注意缓存时效性以及缓存穿透。 A6 关系型数据库(ACID模型)、BASE模型、非关系型数据库 关系型:Oracle、MySQL、SQL Server非关系:Redis、Memcache A7 2* 8C16G 15M 第三讲打卡 A1 云平台能够更好的进行业务的水平方向扩展,并且能够跟随业务的特性能够动态伸缩。 A2 DNS + 跨地域/跨平台 + 容器化 分布式架构 A3 四层。后端项目ECS、nginx配置都需要一致 A4 系统数据:Rsync,快照 文件数据:NFS,OSS 数据库:主从 A5 IO读写相关压力 单表数据量过大查询不便 第四讲打卡 A1 云端配置选型 云端网络架构云端负载均衡云端静态资源访问云端运维管理 A2 Zabbix的Server端数据是以关系型数据库为主,对云容器支持不太好; Prometheus属于容器监控体系技术,对云产品、站点、日志、代码监控问题无法解决; A3 云监控会成为未来监控的主要趋势。 云平台把常见的开源环境,Web、缓存、数据库等进行封装产品化,统一对外提供基础功能入口。 A4 轻量级容器启动可以秒级完成发布; 对固定的ECS没有依赖;Docker容器资源自定义配置,最大化提升资源利用率;可以结合JIRA+Confluence做项目管理及知识库管理;可以更好的进行服务的水平扩增;容器之间环境配置可以进行很好的隔离; A5 使用Docker+K8S+DNS+Rancher 第五讲打卡 A1 不可以,WAF针对的是OSI七层模型中的HTTP层的防御。 A2 SLB ###A3 DDoS+WAF A4 DDoS+ WAF+CDN+SLB+ECS(水平方向多节点)
montos 2020-06-09 23:42:12 0 浏览量 回答数 0

问题

从 RocketMQ捐赠给Apache,来聊未来开源与商业化发展

16年11月阿里巴巴宣布将分布式消息中间件RocketMQ捐赠给了开源软件基金会Apache。其将在ASF精英文化的土壤下继续酝酿,成长,直至枝繁叶茂,有望成为金融领域和大数据领域的业界新宠。了解捐...
李博 bluemind 2019-12-01 21:52:08 2656 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 为了优化和提升网络体验,阿里云于 2016 年 6 月 16 日 12:00 启动了切换到专有网络策略,即截止到实施时间点在实施地域没有经典网络类型ECS实例(包含运行中或者已停止的)的客户,只能购买专有网络(VPC)类型的ECS产品,不能再购买经典网络类型的ECS实例。该策略会分阶段,按照地域段实施。 地域实施时间点 2016 年 12 月 1 日 12:00 在华南 1 实施。 2017 年 2 月 15 日 12:00 在华北 2、香港、亚太东南 1(新加坡)、美国西部(硅谷)实施。 2017 年 3 月 7 日 12:00 在华东 1 实施。 2017 年 3 月 31 日 12:00 在华东 1 、华北 1 实施。 说明 该策略只影响上述已实施地域。您仍可在其他未切换地域同时使用经典网络和专有网络。 具体策略 策略 1:截止到2016 年 6 月 1 日 00:00时间点,在阿里云有经典网络类型的ECS 实例(运行中或者已停止的)的客户,不受切换到专有网络策略影响。只要该地域有库存,就可以继续购买经典网络和专有网络这两种网络类型的 ECS 实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下没有经典网络类型的 ECS 实例(运行中或者已停止的),就只能购买专有网络的 ECS 实例,不能购买经典网络实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下有经典网络类型的 ECS 实例(运行中或者已停止的),只要在实施地域有库存,就可以继续购买经典网络和专有网络两种网络类型的 ECS 实例。 常见问题 Q:阿里云为什么要做这个调整? A:因为专有网络 VPC 更安全,性能更高,体验会更好,用户对网络管理更灵活,支持混合云的场景,代表了未来的发展方向。 Q:除上述地域,其它地域什么时候生效? A:其它地域会在 2017 年 3 月后执行,阿里云会另行通告。 Q:新用户只能购买专有网络类型的 ECS/负载均衡/RDS,对于其它云产品,还支持购买两种网络类型吗? A:支持。但是,建议您购买其它云产品也都购买专有网络类型,否则会对您的使用造成影响,后续其它云产品也会对新用户默认都切换到专有网络 VPC。 Q:如果只能购买专有网络云产品,是否会影响我的使用?比如是否会影响和其它云产品通信? A:正常情况下不会。因为阿里云的云产品绝大部分都支持专有网络 VPC。我们也会尽量确保生效地域的云产品都接入了专有网络 VPC。 Q:如何查询我在各地域能购买哪种网络类型的云产品? A:暂时不能查看,我们会尽快支持开放 OpenAPI 和控制台用户查看。 Q:会不会购买到错误网络类型的云产品? A:由于初期新用户只能购买专有网络的 ECS/负载均衡/RDS 云产品,用户有可能购买到经典网络的其它云产品。请在购买的时候注意网络类型的选择,如购买错误可能会出现使用问题。 Q:购买到了错误网络类型的云产品怎么办? A:可以通过云产品提供的网络切换功能进行网络切换,具体操作请参考各产品控制台。如遇到没有提供网络切换的产品请提工单给阿里云处理(云服务器 ECS 除外)。
2019-12-01 23:30:56 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 为了优化和提升网络体验,阿里云于 2016 年 6 月 16 日 12:00 启动了切换到专有网络策略,即截止到实施时间点在实施地域没有经典网络类型ECS实例(包含运行中或者已停止的)的客户,只能购买专有网络(VPC)类型的ECS产品,不能再购买经典网络类型的ECS实例。该策略会分阶段,按照地域段实施。 地域实施时间点 2016 年 12 月 1 日 12:00 在华南 1 实施。 2017 年 2 月 15 日 12:00 在华北 2、香港、亚太东南 1(新加坡)、美国西部(硅谷)实施。 2017 年 3 月 7 日 12:00 在华东 1 实施。 2017 年 3 月 31 日 12:00 在华东 1 、华北 1 实施。 说明 该策略只影响上述已实施地域。您仍可在其他未切换地域同时使用经典网络和专有网络。 具体策略 策略 1:截止到2016 年 6 月 1 日 00:00时间点,在阿里云有经典网络类型的ECS 实例(运行中或者已停止的)的客户,不受切换到专有网络策略影响。只要该地域有库存,就可以继续购买经典网络和专有网络这两种网络类型的 ECS 实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下没有经典网络类型的 ECS 实例(运行中或者已停止的),就只能购买专有网络的 ECS 实例,不能购买经典网络实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下有经典网络类型的 ECS 实例(运行中或者已停止的),只要在实施地域有库存,就可以继续购买经典网络和专有网络两种网络类型的 ECS 实例。 常见问题 Q:阿里云为什么要做这个调整? A:因为专有网络 VPC 更安全,性能更高,体验会更好,用户对网络管理更灵活,支持混合云的场景,代表了未来的发展方向。 Q:除上述地域,其它地域什么时候生效? A:其它地域会在 2017 年 3 月后执行,阿里云会另行通告。 Q:新用户只能购买专有网络类型的 ECS/负载均衡/RDS,对于其它云产品,还支持购买两种网络类型吗? A:支持。但是,建议您购买其它云产品也都购买专有网络类型,否则会对您的使用造成影响,后续其它云产品也会对新用户默认都切换到专有网络 VPC。 Q:如果只能购买专有网络云产品,是否会影响我的使用?比如是否会影响和其它云产品通信? A:正常情况下不会。因为阿里云的云产品绝大部分都支持专有网络 VPC。我们也会尽量确保生效地域的云产品都接入了专有网络 VPC。 Q:如何查询我在各地域能购买哪种网络类型的云产品? A:暂时不能查看,我们会尽快支持开放 OpenAPI 和控制台用户查看。 Q:会不会购买到错误网络类型的云产品? A:由于初期新用户只能购买专有网络的 ECS/负载均衡/RDS 云产品,用户有可能购买到经典网络的其它云产品。请在购买的时候注意网络类型的选择,如购买错误可能会出现使用问题。 Q:购买到了错误网络类型的云产品怎么办? A:可以通过云产品提供的网络切换功能进行网络切换,具体操作请参考各产品控制台。如遇到没有提供网络切换的产品请提工单给阿里云处理(云服务器 ECS 除外)。
2019-12-01 23:30:56 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 为了优化和提升网络体验,阿里云于 2016 年 6 月 16 日 12:00 启动了切换到专有网络策略,即截止到实施时间点在实施地域没有经典网络类型ECS实例(包含运行中或者已停止的)的客户,只能购买专有网络(VPC)类型的ECS产品,不能再购买经典网络类型的ECS实例。该策略会分阶段,按照地域段实施。 地域实施时间点 2016 年 12 月 1 日 12:00 在华南 1 实施。 2017 年 2 月 15 日 12:00 在华北 2、香港、亚太东南 1(新加坡)、美国西部(硅谷)实施。 2017 年 3 月 7 日 12:00 在华东 1 实施。 2017 年 3 月 31 日 12:00 在华东 1 、华北 1 实施。 说明 该策略只影响上述已实施地域。您仍可在其他未切换地域同时使用经典网络和专有网络。 具体策略 策略 1:截止到2016 年 6 月 1 日 00:00时间点,在阿里云有经典网络类型的ECS 实例(运行中或者已停止的)的客户,不受切换到专有网络策略影响。只要该地域有库存,就可以继续购买经典网络和专有网络这两种网络类型的 ECS 实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下没有经典网络类型的 ECS 实例(运行中或者已停止的),就只能购买专有网络的 ECS 实例,不能购买经典网络实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下有经典网络类型的 ECS 实例(运行中或者已停止的),只要在实施地域有库存,就可以继续购买经典网络和专有网络两种网络类型的 ECS 实例。 常见问题 Q:阿里云为什么要做这个调整? A:因为专有网络 VPC 更安全,性能更高,体验会更好,用户对网络管理更灵活,支持混合云的场景,代表了未来的发展方向。 Q:除上述地域,其它地域什么时候生效? A:其它地域会在 2017 年 3 月后执行,阿里云会另行通告。 Q:新用户只能购买专有网络类型的 ECS/负载均衡/RDS,对于其它云产品,还支持购买两种网络类型吗? A:支持。但是,建议您购买其它云产品也都购买专有网络类型,否则会对您的使用造成影响,后续其它云产品也会对新用户默认都切换到专有网络 VPC。 Q:如果只能购买专有网络云产品,是否会影响我的使用?比如是否会影响和其它云产品通信? A:正常情况下不会。因为阿里云的云产品绝大部分都支持专有网络 VPC。我们也会尽量确保生效地域的云产品都接入了专有网络 VPC。 Q:如何查询我在各地域能购买哪种网络类型的云产品? A:暂时不能查看,我们会尽快支持开放 OpenAPI 和控制台用户查看。 Q:会不会购买到错误网络类型的云产品? A:由于初期新用户只能购买专有网络的 ECS/负载均衡/RDS 云产品,用户有可能购买到经典网络的其它云产品。请在购买的时候注意网络类型的选择,如购买错误可能会出现使用问题。 Q:购买到了错误网络类型的云产品怎么办? A:可以通过云产品提供的网络切换功能进行网络切换,具体操作请参考各产品控制台。如遇到没有提供网络切换的产品请提工单给阿里云处理(云服务器 ECS 除外)。
2019-12-01 23:30:55 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 为了优化和提升网络体验,阿里云于 2016 年 6 月 16 日 12:00 启动了切换到专有网络策略,即截止到实施时间点在实施地域没有经典网络类型ECS实例(包含运行中或者已停止的)的客户,只能购买专有网络(VPC)类型的ECS产品,不能再购买经典网络类型的ECS实例。该策略会分阶段,按照地域段实施。 地域实施时间点 2016 年 12 月 1 日 12:00 在华南 1 实施。 2017 年 2 月 15 日 12:00 在华北 2、香港、亚太东南 1(新加坡)、美国西部(硅谷)实施。 2017 年 3 月 7 日 12:00 在华东 1 实施。 2017 年 3 月 31 日 12:00 在华东 1 、华北 1 实施。 说明 该策略只影响上述已实施地域。您仍可在其他未切换地域同时使用经典网络和专有网络。 具体策略 策略 1:截止到2016 年 6 月 1 日 00:00时间点,在阿里云有经典网络类型的ECS 实例(运行中或者已停止的)的客户,不受切换到专有网络策略影响。只要该地域有库存,就可以继续购买经典网络和专有网络这两种网络类型的 ECS 实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下没有经典网络类型的 ECS 实例(运行中或者已停止的),就只能购买专有网络的 ECS 实例,不能购买经典网络实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下有经典网络类型的 ECS 实例(运行中或者已停止的),只要在实施地域有库存,就可以继续购买经典网络和专有网络两种网络类型的 ECS 实例。 常见问题 Q:阿里云为什么要做这个调整? A:因为专有网络 VPC 更安全,性能更高,体验会更好,用户对网络管理更灵活,支持混合云的场景,代表了未来的发展方向。 Q:除上述地域,其它地域什么时候生效? A:其它地域会在 2017 年 3 月后执行,阿里云会另行通告。 Q:新用户只能购买专有网络类型的 ECS/负载均衡/RDS,对于其它云产品,还支持购买两种网络类型吗? A:支持。但是,建议您购买其它云产品也都购买专有网络类型,否则会对您的使用造成影响,后续其它云产品也会对新用户默认都切换到专有网络 VPC。 Q:如果只能购买专有网络云产品,是否会影响我的使用?比如是否会影响和其它云产品通信? A:正常情况下不会。因为阿里云的云产品绝大部分都支持专有网络 VPC。我们也会尽量确保生效地域的云产品都接入了专有网络 VPC。 Q:如何查询我在各地域能购买哪种网络类型的云产品? A:暂时不能查看,我们会尽快支持开放 OpenAPI 和控制台用户查看。 Q:会不会购买到错误网络类型的云产品? A:由于初期新用户只能购买专有网络的 ECS/负载均衡/RDS 云产品,用户有可能购买到经典网络的其它云产品。请在购买的时候注意网络类型的选择,如购买错误可能会出现使用问题。 Q:购买到了错误网络类型的云产品怎么办? A:可以通过云产品提供的网络切换功能进行网络切换,具体操作请参考各产品控制台。如遇到没有提供网络切换的产品请提工单给阿里云处理(云服务器 ECS 除外)。
2019-12-01 23:30:57 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 为了优化和提升网络体验,阿里云于 2016 年 6 月 16 日 12:00 启动了切换到专有网络策略,即截止到实施时间点在实施地域没有经典网络类型ECS实例(包含运行中或者已停止的)的客户,只能购买专有网络(VPC)类型的ECS产品,不能再购买经典网络类型的ECS实例。该策略会分阶段,按照地域段实施。 地域实施时间点 2016 年 12 月 1 日 12:00 在华南 1 实施。 2017 年 2 月 15 日 12:00 在华北 2、香港、亚太东南 1(新加坡)、美国西部(硅谷)实施。 2017 年 3 月 7 日 12:00 在华东 1 实施。 2017 年 3 月 31 日 12:00 在华东 1 、华北 1 实施。 说明 该策略只影响上述已实施地域。您仍可在其他未切换地域同时使用经典网络和专有网络。 具体策略 策略 1:截止到2016 年 6 月 1 日 00:00时间点,在阿里云有经典网络类型的ECS 实例(运行中或者已停止的)的客户,不受切换到专有网络策略影响。只要该地域有库存,就可以继续购买经典网络和专有网络这两种网络类型的 ECS 实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下没有经典网络类型的 ECS 实例(运行中或者已停止的),就只能购买专有网络的 ECS 实例,不能购买经典网络实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下有经典网络类型的 ECS 实例(运行中或者已停止的),只要在实施地域有库存,就可以继续购买经典网络和专有网络两种网络类型的 ECS 实例。 常见问题 Q:阿里云为什么要做这个调整? A:因为专有网络 VPC 更安全,性能更高,体验会更好,用户对网络管理更灵活,支持混合云的场景,代表了未来的发展方向。 Q:除上述地域,其它地域什么时候生效? A:其它地域会在 2017 年 3 月后执行,阿里云会另行通告。 Q:新用户只能购买专有网络类型的 ECS/负载均衡/RDS,对于其它云产品,还支持购买两种网络类型吗? A:支持。但是,建议您购买其它云产品也都购买专有网络类型,否则会对您的使用造成影响,后续其它云产品也会对新用户默认都切换到专有网络 VPC。 Q:如果只能购买专有网络云产品,是否会影响我的使用?比如是否会影响和其它云产品通信? A:正常情况下不会。因为阿里云的云产品绝大部分都支持专有网络 VPC。我们也会尽量确保生效地域的云产品都接入了专有网络 VPC。 Q:如何查询我在各地域能购买哪种网络类型的云产品? A:暂时不能查看,我们会尽快支持开放 OpenAPI 和控制台用户查看。 Q:会不会购买到错误网络类型的云产品? A:由于初期新用户只能购买专有网络的 ECS/负载均衡/RDS 云产品,用户有可能购买到经典网络的其它云产品。请在购买的时候注意网络类型的选择,如购买错误可能会出现使用问题。 Q:购买到了错误网络类型的云产品怎么办? A:可以通过云产品提供的网络切换功能进行网络切换,具体操作请参考各产品控制台。如遇到没有提供网络切换的产品请提工单给阿里云处理(云服务器 ECS 除外)。
2019-12-01 23:30:56 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 为了优化和提升网络体验,阿里云于 2016 年 6 月 16 日 12:00 启动了切换到专有网络策略,即截止到实施时间点在实施地域没有经典网络类型ECS实例(包含运行中或者已停止的)的客户,只能购买专有网络(VPC)类型的ECS产品,不能再购买经典网络类型的ECS实例。该策略会分阶段,按照地域段实施。 地域实施时间点 2016 年 12 月 1 日 12:00 在华南 1 实施。 2017 年 2 月 15 日 12:00 在华北 2、香港、亚太东南 1(新加坡)、美国西部(硅谷)实施。 2017 年 3 月 7 日 12:00 在华东 1 实施。 2017 年 3 月 31 日 12:00 在华东 1 、华北 1 实施。 说明 该策略只影响上述已实施地域。您仍可在其他未切换地域同时使用经典网络和专有网络。 具体策略 策略 1:截止到2016 年 6 月 1 日 00:00时间点,在阿里云有经典网络类型的ECS 实例(运行中或者已停止的)的客户,不受切换到专有网络策略影响。只要该地域有库存,就可以继续购买经典网络和专有网络这两种网络类型的 ECS 实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下没有经典网络类型的 ECS 实例(运行中或者已停止的),就只能购买专有网络的 ECS 实例,不能购买经典网络实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下有经典网络类型的 ECS 实例(运行中或者已停止的),只要在实施地域有库存,就可以继续购买经典网络和专有网络两种网络类型的 ECS 实例。 常见问题 Q:阿里云为什么要做这个调整? A:因为专有网络 VPC 更安全,性能更高,体验会更好,用户对网络管理更灵活,支持混合云的场景,代表了未来的发展方向。 Q:除上述地域,其它地域什么时候生效? A:其它地域会在 2017 年 3 月后执行,阿里云会另行通告。 Q:新用户只能购买专有网络类型的 ECS/负载均衡/RDS,对于其它云产品,还支持购买两种网络类型吗? A:支持。但是,建议您购买其它云产品也都购买专有网络类型,否则会对您的使用造成影响,后续其它云产品也会对新用户默认都切换到专有网络 VPC。 Q:如果只能购买专有网络云产品,是否会影响我的使用?比如是否会影响和其它云产品通信? A:正常情况下不会。因为阿里云的云产品绝大部分都支持专有网络 VPC。我们也会尽量确保生效地域的云产品都接入了专有网络 VPC。 Q:如何查询我在各地域能购买哪种网络类型的云产品? A:暂时不能查看,我们会尽快支持开放 OpenAPI 和控制台用户查看。 Q:会不会购买到错误网络类型的云产品? A:由于初期新用户只能购买专有网络的 ECS/负载均衡/RDS 云产品,用户有可能购买到经典网络的其它云产品。请在购买的时候注意网络类型的选择,如购买错误可能会出现使用问题。 Q:购买到了错误网络类型的云产品怎么办? A:可以通过云产品提供的网络切换功能进行网络切换,具体操作请参考各产品控制台。如遇到没有提供网络切换的产品请提工单给阿里云处理(云服务器 ECS 除外)。
2019-12-01 23:30:58 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 为了优化和提升网络体验,阿里云于 2016 年 6 月 16 日 12:00 启动了切换到专有网络策略,即截止到实施时间点在实施地域没有经典网络类型ECS实例(包含运行中或者已停止的)的客户,只能购买专有网络(VPC)类型的ECS产品,不能再购买经典网络类型的ECS实例。该策略会分阶段,按照地域段实施。 地域实施时间点 2016 年 12 月 1 日 12:00 在华南 1 实施。 2017 年 2 月 15 日 12:00 在华北 2、香港、亚太东南 1(新加坡)、美国西部(硅谷)实施。 2017 年 3 月 7 日 12:00 在华东 1 实施。 2017 年 3 月 31 日 12:00 在华东 1 、华北 1 实施。 说明 该策略只影响上述已实施地域。您仍可在其他未切换地域同时使用经典网络和专有网络。 具体策略 策略 1:截止到2016 年 6 月 1 日 00:00时间点,在阿里云有经典网络类型的ECS 实例(运行中或者已停止的)的客户,不受切换到专有网络策略影响。只要该地域有库存,就可以继续购买经典网络和专有网络这两种网络类型的 ECS 实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下没有经典网络类型的 ECS 实例(运行中或者已停止的),就只能购买专有网络的 ECS 实例,不能购买经典网络实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下有经典网络类型的 ECS 实例(运行中或者已停止的),只要在实施地域有库存,就可以继续购买经典网络和专有网络两种网络类型的 ECS 实例。 常见问题 Q:阿里云为什么要做这个调整? A:因为专有网络 VPC 更安全,性能更高,体验会更好,用户对网络管理更灵活,支持混合云的场景,代表了未来的发展方向。 Q:除上述地域,其它地域什么时候生效? A:其它地域会在 2017 年 3 月后执行,阿里云会另行通告。 Q:新用户只能购买专有网络类型的 ECS/负载均衡/RDS,对于其它云产品,还支持购买两种网络类型吗? A:支持。但是,建议您购买其它云产品也都购买专有网络类型,否则会对您的使用造成影响,后续其它云产品也会对新用户默认都切换到专有网络 VPC。 Q:如果只能购买专有网络云产品,是否会影响我的使用?比如是否会影响和其它云产品通信? A:正常情况下不会。因为阿里云的云产品绝大部分都支持专有网络 VPC。我们也会尽量确保生效地域的云产品都接入了专有网络 VPC。 Q:如何查询我在各地域能购买哪种网络类型的云产品? A:暂时不能查看,我们会尽快支持开放 OpenAPI 和控制台用户查看。 Q:会不会购买到错误网络类型的云产品? A:由于初期新用户只能购买专有网络的 ECS/负载均衡/RDS 云产品,用户有可能购买到经典网络的其它云产品。请在购买的时候注意网络类型的选择,如购买错误可能会出现使用问题。 Q:购买到了错误网络类型的云产品怎么办? A:可以通过云产品提供的网络切换功能进行网络切换,具体操作请参考各产品控制台。如遇到没有提供网络切换的产品请提工单给阿里云处理(云服务器 ECS 除外)。
2019-12-01 23:30:56 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 为了优化和提升网络体验,阿里云于 2016 年 6 月 16 日 12:00 启动了切换到专有网络策略,即截止到实施时间点在实施地域没有经典网络类型ECS实例(包含运行中或者已停止的)的客户,只能购买专有网络(VPC)类型的ECS产品,不能再购买经典网络类型的ECS实例。该策略会分阶段,按照地域段实施。 地域实施时间点 2016 年 12 月 1 日 12:00 在华南 1 实施。 2017 年 2 月 15 日 12:00 在华北 2、香港、亚太东南 1(新加坡)、美国西部(硅谷)实施。 2017 年 3 月 7 日 12:00 在华东 1 实施。 2017 年 3 月 31 日 12:00 在华东 1 、华北 1 实施。 说明 该策略只影响上述已实施地域。您仍可在其他未切换地域同时使用经典网络和专有网络。 具体策略 策略 1:截止到2016 年 6 月 1 日 00:00时间点,在阿里云有经典网络类型的ECS 实例(运行中或者已停止的)的客户,不受切换到专有网络策略影响。只要该地域有库存,就可以继续购买经典网络和专有网络这两种网络类型的 ECS 实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下没有经典网络类型的 ECS 实例(运行中或者已停止的),就只能购买专有网络的 ECS 实例,不能购买经典网络实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下有经典网络类型的 ECS 实例(运行中或者已停止的),只要在实施地域有库存,就可以继续购买经典网络和专有网络两种网络类型的 ECS 实例。 常见问题 Q:阿里云为什么要做这个调整? A:因为专有网络 VPC 更安全,性能更高,体验会更好,用户对网络管理更灵活,支持混合云的场景,代表了未来的发展方向。 Q:除上述地域,其它地域什么时候生效? A:其它地域会在 2017 年 3 月后执行,阿里云会另行通告。 Q:新用户只能购买专有网络类型的 ECS/负载均衡/RDS,对于其它云产品,还支持购买两种网络类型吗? A:支持。但是,建议您购买其它云产品也都购买专有网络类型,否则会对您的使用造成影响,后续其它云产品也会对新用户默认都切换到专有网络 VPC。 Q:如果只能购买专有网络云产品,是否会影响我的使用?比如是否会影响和其它云产品通信? A:正常情况下不会。因为阿里云的云产品绝大部分都支持专有网络 VPC。我们也会尽量确保生效地域的云产品都接入了专有网络 VPC。 Q:如何查询我在各地域能购买哪种网络类型的云产品? A:暂时不能查看,我们会尽快支持开放 OpenAPI 和控制台用户查看。 Q:会不会购买到错误网络类型的云产品? A:由于初期新用户只能购买专有网络的 ECS/负载均衡/RDS 云产品,用户有可能购买到经典网络的其它云产品。请在购买的时候注意网络类型的选择,如购买错误可能会出现使用问题。 Q:购买到了错误网络类型的云产品怎么办? A:可以通过云产品提供的网络切换功能进行网络切换,具体操作请参考各产品控制台。如遇到没有提供网络切换的产品请提工单给阿里云处理(云服务器 ECS 除外)。
2019-12-01 23:30:56 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 为了优化和提升网络体验,阿里云于 2016 年 6 月 16 日 12:00 启动了切换到专有网络策略,即截止到实施时间点在实施地域没有经典网络类型ECS实例(包含运行中或者已停止的)的客户,只能购买专有网络(VPC)类型的ECS产品,不能再购买经典网络类型的ECS实例。该策略会分阶段,按照地域段实施。 地域实施时间点 2016 年 12 月 1 日 12:00 在华南 1 实施。 2017 年 2 月 15 日 12:00 在华北 2、香港、亚太东南 1(新加坡)、美国西部(硅谷)实施。 2017 年 3 月 7 日 12:00 在华东 1 实施。 2017 年 3 月 31 日 12:00 在华东 1 、华北 1 实施。 说明 该策略只影响上述已实施地域。您仍可在其他未切换地域同时使用经典网络和专有网络。 具体策略 策略 1:截止到2016 年 6 月 1 日 00:00时间点,在阿里云有经典网络类型的ECS 实例(运行中或者已停止的)的客户,不受切换到专有网络策略影响。只要该地域有库存,就可以继续购买经典网络和专有网络这两种网络类型的 ECS 实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下没有经典网络类型的 ECS 实例(运行中或者已停止的),就只能购买专有网络的 ECS 实例,不能购买经典网络实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下有经典网络类型的 ECS 实例(运行中或者已停止的),只要在实施地域有库存,就可以继续购买经典网络和专有网络两种网络类型的 ECS 实例。 常见问题 Q:阿里云为什么要做这个调整? A:因为专有网络 VPC 更安全,性能更高,体验会更好,用户对网络管理更灵活,支持混合云的场景,代表了未来的发展方向。 Q:除上述地域,其它地域什么时候生效? A:其它地域会在 2017 年 3 月后执行,阿里云会另行通告。 Q:新用户只能购买专有网络类型的 ECS/负载均衡/RDS,对于其它云产品,还支持购买两种网络类型吗? A:支持。但是,建议您购买其它云产品也都购买专有网络类型,否则会对您的使用造成影响,后续其它云产品也会对新用户默认都切换到专有网络 VPC。 Q:如果只能购买专有网络云产品,是否会影响我的使用?比如是否会影响和其它云产品通信? A:正常情况下不会。因为阿里云的云产品绝大部分都支持专有网络 VPC。我们也会尽量确保生效地域的云产品都接入了专有网络 VPC。 Q:如何查询我在各地域能购买哪种网络类型的云产品? A:暂时不能查看,我们会尽快支持开放 OpenAPI 和控制台用户查看。 Q:会不会购买到错误网络类型的云产品? A:由于初期新用户只能购买专有网络的 ECS/负载均衡/RDS 云产品,用户有可能购买到经典网络的其它云产品。请在购买的时候注意网络类型的选择,如购买错误可能会出现使用问题。 Q:购买到了错误网络类型的云产品怎么办? A:可以通过云产品提供的网络切换功能进行网络切换,具体操作请参考各产品控制台。如遇到没有提供网络切换的产品请提工单给阿里云处理(云服务器 ECS 除外)。
2019-12-01 23:30:58 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 为了优化和提升网络体验,阿里云于 2016 年 6 月 16 日 12:00 启动了切换到专有网络策略,即截止到实施时间点在实施地域没有经典网络类型ECS实例(包含运行中或者已停止的)的客户,只能购买专有网络(VPC)类型的ECS产品,不能再购买经典网络类型的ECS实例。该策略会分阶段,按照地域段实施。 地域实施时间点 2016 年 12 月 1 日 12:00 在华南 1 实施。 2017 年 2 月 15 日 12:00 在华北 2、香港、亚太东南 1(新加坡)、美国西部(硅谷)实施。 2017 年 3 月 7 日 12:00 在华东 1 实施。 2017 年 3 月 31 日 12:00 在华东 1 、华北 1 实施。 说明 该策略只影响上述已实施地域。您仍可在其他未切换地域同时使用经典网络和专有网络。 具体策略 策略 1:截止到2016 年 6 月 1 日 00:00时间点,在阿里云有经典网络类型的ECS 实例(运行中或者已停止的)的客户,不受切换到专有网络策略影响。只要该地域有库存,就可以继续购买经典网络和专有网络这两种网络类型的 ECS 实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下没有经典网络类型的 ECS 实例(运行中或者已停止的),就只能购买专有网络的 ECS 实例,不能购买经典网络实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下有经典网络类型的 ECS 实例(运行中或者已停止的),只要在实施地域有库存,就可以继续购买经典网络和专有网络两种网络类型的 ECS 实例。 常见问题 Q:阿里云为什么要做这个调整? A:因为专有网络 VPC 更安全,性能更高,体验会更好,用户对网络管理更灵活,支持混合云的场景,代表了未来的发展方向。 Q:除上述地域,其它地域什么时候生效? A:其它地域会在 2017 年 3 月后执行,阿里云会另行通告。 Q:新用户只能购买专有网络类型的 ECS/负载均衡/RDS,对于其它云产品,还支持购买两种网络类型吗? A:支持。但是,建议您购买其它云产品也都购买专有网络类型,否则会对您的使用造成影响,后续其它云产品也会对新用户默认都切换到专有网络 VPC。 Q:如果只能购买专有网络云产品,是否会影响我的使用?比如是否会影响和其它云产品通信? A:正常情况下不会。因为阿里云的云产品绝大部分都支持专有网络 VPC。我们也会尽量确保生效地域的云产品都接入了专有网络 VPC。 Q:如何查询我在各地域能购买哪种网络类型的云产品? A:暂时不能查看,我们会尽快支持开放 OpenAPI 和控制台用户查看。 Q:会不会购买到错误网络类型的云产品? A:由于初期新用户只能购买专有网络的 ECS/负载均衡/RDS 云产品,用户有可能购买到经典网络的其它云产品。请在购买的时候注意网络类型的选择,如购买错误可能会出现使用问题。 Q:购买到了错误网络类型的云产品怎么办? A:可以通过云产品提供的网络切换功能进行网络切换,具体操作请参考各产品控制台。如遇到没有提供网络切换的产品请提工单给阿里云处理(云服务器 ECS 除外)。
2019-12-01 23:30:55 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 为了优化和提升网络体验,阿里云于 2016 年 6 月 16 日 12:00 启动了切换到专有网络策略,即截止到实施时间点在实施地域没有经典网络类型ECS实例(包含运行中或者已停止的)的客户,只能购买专有网络(VPC)类型的ECS产品,不能再购买经典网络类型的ECS实例。该策略会分阶段,按照地域段实施。 地域实施时间点 2016 年 12 月 1 日 12:00 在华南 1 实施。 2017 年 2 月 15 日 12:00 在华北 2、香港、亚太东南 1(新加坡)、美国西部(硅谷)实施。 2017 年 3 月 7 日 12:00 在华东 1 实施。 2017 年 3 月 31 日 12:00 在华东 1 、华北 1 实施。 说明 该策略只影响上述已实施地域。您仍可在其他未切换地域同时使用经典网络和专有网络。 具体策略 策略 1:截止到2016 年 6 月 1 日 00:00时间点,在阿里云有经典网络类型的ECS 实例(运行中或者已停止的)的客户,不受切换到专有网络策略影响。只要该地域有库存,就可以继续购买经典网络和专有网络这两种网络类型的 ECS 实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下没有经典网络类型的 ECS 实例(运行中或者已停止的),就只能购买专有网络的 ECS 实例,不能购买经典网络实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下有经典网络类型的 ECS 实例(运行中或者已停止的),只要在实施地域有库存,就可以继续购买经典网络和专有网络两种网络类型的 ECS 实例。 常见问题 Q:阿里云为什么要做这个调整? A:因为专有网络 VPC 更安全,性能更高,体验会更好,用户对网络管理更灵活,支持混合云的场景,代表了未来的发展方向。 Q:除上述地域,其它地域什么时候生效? A:其它地域会在 2017 年 3 月后执行,阿里云会另行通告。 Q:新用户只能购买专有网络类型的 ECS/负载均衡/RDS,对于其它云产品,还支持购买两种网络类型吗? A:支持。但是,建议您购买其它云产品也都购买专有网络类型,否则会对您的使用造成影响,后续其它云产品也会对新用户默认都切换到专有网络 VPC。 Q:如果只能购买专有网络云产品,是否会影响我的使用?比如是否会影响和其它云产品通信? A:正常情况下不会。因为阿里云的云产品绝大部分都支持专有网络 VPC。我们也会尽量确保生效地域的云产品都接入了专有网络 VPC。 Q:如何查询我在各地域能购买哪种网络类型的云产品? A:暂时不能查看,我们会尽快支持开放 OpenAPI 和控制台用户查看。 Q:会不会购买到错误网络类型的云产品? A:由于初期新用户只能购买专有网络的 ECS/负载均衡/RDS 云产品,用户有可能购买到经典网络的其它云产品。请在购买的时候注意网络类型的选择,如购买错误可能会出现使用问题。 Q:购买到了错误网络类型的云产品怎么办? A:可以通过云产品提供的网络切换功能进行网络切换,具体操作请参考各产品控制台。如遇到没有提供网络切换的产品请提工单给阿里云处理(云服务器 ECS 除外)。
2019-12-01 23:30:56 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 为了优化和提升网络体验,阿里云于 2016 年 6 月 16 日 12:00 启动了切换到专有网络策略,即截止到实施时间点在实施地域没有经典网络类型ECS实例(包含运行中或者已停止的)的客户,只能购买专有网络(VPC)类型的ECS产品,不能再购买经典网络类型的ECS实例。该策略会分阶段,按照地域段实施。 地域实施时间点 2016 年 12 月 1 日 12:00 在华南 1 实施。 2017 年 2 月 15 日 12:00 在华北 2、香港、亚太东南 1(新加坡)、美国西部(硅谷)实施。 2017 年 3 月 7 日 12:00 在华东 1 实施。 2017 年 3 月 31 日 12:00 在华东 1 、华北 1 实施。 说明 该策略只影响上述已实施地域。您仍可在其他未切换地域同时使用经典网络和专有网络。 具体策略 策略 1:截止到2016 年 6 月 1 日 00:00时间点,在阿里云有经典网络类型的ECS 实例(运行中或者已停止的)的客户,不受切换到专有网络策略影响。只要该地域有库存,就可以继续购买经典网络和专有网络这两种网络类型的 ECS 实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下没有经典网络类型的 ECS 实例(运行中或者已停止的),就只能购买专有网络的 ECS 实例,不能购买经典网络实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下有经典网络类型的 ECS 实例(运行中或者已停止的),只要在实施地域有库存,就可以继续购买经典网络和专有网络两种网络类型的 ECS 实例。 常见问题 Q:阿里云为什么要做这个调整? A:因为专有网络 VPC 更安全,性能更高,体验会更好,用户对网络管理更灵活,支持混合云的场景,代表了未来的发展方向。 Q:除上述地域,其它地域什么时候生效? A:其它地域会在 2017 年 3 月后执行,阿里云会另行通告。 Q:新用户只能购买专有网络类型的 ECS/负载均衡/RDS,对于其它云产品,还支持购买两种网络类型吗? A:支持。但是,建议您购买其它云产品也都购买专有网络类型,否则会对您的使用造成影响,后续其它云产品也会对新用户默认都切换到专有网络 VPC。 Q:如果只能购买专有网络云产品,是否会影响我的使用?比如是否会影响和其它云产品通信? A:正常情况下不会。因为阿里云的云产品绝大部分都支持专有网络 VPC。我们也会尽量确保生效地域的云产品都接入了专有网络 VPC。 Q:如何查询我在各地域能购买哪种网络类型的云产品? A:暂时不能查看,我们会尽快支持开放 OpenAPI 和控制台用户查看。 Q:会不会购买到错误网络类型的云产品? A:由于初期新用户只能购买专有网络的 ECS/负载均衡/RDS 云产品,用户有可能购买到经典网络的其它云产品。请在购买的时候注意网络类型的选择,如购买错误可能会出现使用问题。 Q:购买到了错误网络类型的云产品怎么办? A:可以通过云产品提供的网络切换功能进行网络切换,具体操作请参考各产品控制台。如遇到没有提供网络切换的产品请提工单给阿里云处理(云服务器 ECS 除外)。
2019-12-01 23:30:59 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 为了优化和提升网络体验,阿里云于 2016 年 6 月 16 日 12:00 启动了切换到专有网络策略,即截止到实施时间点在实施地域没有经典网络类型ECS实例(包含运行中或者已停止的)的客户,只能购买专有网络(VPC)类型的ECS产品,不能再购买经典网络类型的ECS实例。该策略会分阶段,按照地域段实施。 地域实施时间点 2016 年 12 月 1 日 12:00 在华南 1 实施。 2017 年 2 月 15 日 12:00 在华北 2、香港、亚太东南 1(新加坡)、美国西部(硅谷)实施。 2017 年 3 月 7 日 12:00 在华东 1 实施。 2017 年 3 月 31 日 12:00 在华东 1 、华北 1 实施。 说明 该策略只影响上述已实施地域。您仍可在其他未切换地域同时使用经典网络和专有网络。 具体策略 策略 1:截止到2016 年 6 月 1 日 00:00时间点,在阿里云有经典网络类型的ECS 实例(运行中或者已停止的)的客户,不受切换到专有网络策略影响。只要该地域有库存,就可以继续购买经典网络和专有网络这两种网络类型的 ECS 实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下没有经典网络类型的 ECS 实例(运行中或者已停止的),就只能购买专有网络的 ECS 实例,不能购买经典网络实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下有经典网络类型的 ECS 实例(运行中或者已停止的),只要在实施地域有库存,就可以继续购买经典网络和专有网络两种网络类型的 ECS 实例。 常见问题 Q:阿里云为什么要做这个调整? A:因为专有网络 VPC 更安全,性能更高,体验会更好,用户对网络管理更灵活,支持混合云的场景,代表了未来的发展方向。 Q:除上述地域,其它地域什么时候生效? A:其它地域会在 2017 年 3 月后执行,阿里云会另行通告。 Q:新用户只能购买专有网络类型的 ECS/负载均衡/RDS,对于其它云产品,还支持购买两种网络类型吗? A:支持。但是,建议您购买其它云产品也都购买专有网络类型,否则会对您的使用造成影响,后续其它云产品也会对新用户默认都切换到专有网络 VPC。 Q:如果只能购买专有网络云产品,是否会影响我的使用?比如是否会影响和其它云产品通信? A:正常情况下不会。因为阿里云的云产品绝大部分都支持专有网络 VPC。我们也会尽量确保生效地域的云产品都接入了专有网络 VPC。 Q:如何查询我在各地域能购买哪种网络类型的云产品? A:暂时不能查看,我们会尽快支持开放 OpenAPI 和控制台用户查看。 Q:会不会购买到错误网络类型的云产品? A:由于初期新用户只能购买专有网络的 ECS/负载均衡/RDS 云产品,用户有可能购买到经典网络的其它云产品。请在购买的时候注意网络类型的选择,如购买错误可能会出现使用问题。 Q:购买到了错误网络类型的云产品怎么办? A:可以通过云产品提供的网络切换功能进行网络切换,具体操作请参考各产品控制台。如遇到没有提供网络切换的产品请提工单给阿里云处理(云服务器 ECS 除外)。
2019-12-01 23:30:58 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 为了优化和提升网络体验,阿里云于 2016 年 6 月 16 日 12:00 启动了切换到专有网络策略,即截止到实施时间点在实施地域没有经典网络类型ECS实例(包含运行中或者已停止的)的客户,只能购买专有网络(VPC)类型的ECS产品,不能再购买经典网络类型的ECS实例。该策略会分阶段,按照地域段实施。 地域实施时间点 2016 年 12 月 1 日 12:00 在华南 1 实施。 2017 年 2 月 15 日 12:00 在华北 2、香港、亚太东南 1(新加坡)、美国西部(硅谷)实施。 2017 年 3 月 7 日 12:00 在华东 1 实施。 2017 年 3 月 31 日 12:00 在华东 1 、华北 1 实施。 说明 该策略只影响上述已实施地域。您仍可在其他未切换地域同时使用经典网络和专有网络。 具体策略 策略 1:截止到2016 年 6 月 1 日 00:00时间点,在阿里云有经典网络类型的ECS 实例(运行中或者已停止的)的客户,不受切换到专有网络策略影响。只要该地域有库存,就可以继续购买经典网络和专有网络这两种网络类型的 ECS 实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下没有经典网络类型的 ECS 实例(运行中或者已停止的),就只能购买专有网络的 ECS 实例,不能购买经典网络实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下有经典网络类型的 ECS 实例(运行中或者已停止的),只要在实施地域有库存,就可以继续购买经典网络和专有网络两种网络类型的 ECS 实例。 常见问题 Q:阿里云为什么要做这个调整? A:因为专有网络 VPC 更安全,性能更高,体验会更好,用户对网络管理更灵活,支持混合云的场景,代表了未来的发展方向。 Q:除上述地域,其它地域什么时候生效? A:其它地域会在 2017 年 3 月后执行,阿里云会另行通告。 Q:新用户只能购买专有网络类型的 ECS/负载均衡/RDS,对于其它云产品,还支持购买两种网络类型吗? A:支持。但是,建议您购买其它云产品也都购买专有网络类型,否则会对您的使用造成影响,后续其它云产品也会对新用户默认都切换到专有网络 VPC。 Q:如果只能购买专有网络云产品,是否会影响我的使用?比如是否会影响和其它云产品通信? A:正常情况下不会。因为阿里云的云产品绝大部分都支持专有网络 VPC。我们也会尽量确保生效地域的云产品都接入了专有网络 VPC。 Q:如何查询我在各地域能购买哪种网络类型的云产品? A:暂时不能查看,我们会尽快支持开放 OpenAPI 和控制台用户查看。 Q:会不会购买到错误网络类型的云产品? A:由于初期新用户只能购买专有网络的 ECS/负载均衡/RDS 云产品,用户有可能购买到经典网络的其它云产品。请在购买的时候注意网络类型的选择,如购买错误可能会出现使用问题。 Q:购买到了错误网络类型的云产品怎么办? A:可以通过云产品提供的网络切换功能进行网络切换,具体操作请参考各产品控制台。如遇到没有提供网络切换的产品请提工单给阿里云处理(云服务器 ECS 除外)。
2019-12-01 23:30:59 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 为了优化和提升网络体验,阿里云于 2016 年 6 月 16 日 12:00 启动了切换到专有网络策略,即截止到实施时间点在实施地域没有经典网络类型ECS实例(包含运行中或者已停止的)的客户,只能购买专有网络(VPC)类型的ECS产品,不能再购买经典网络类型的ECS实例。该策略会分阶段,按照地域段实施。 地域实施时间点 2016 年 12 月 1 日 12:00 在华南 1 实施。 2017 年 2 月 15 日 12:00 在华北 2、香港、亚太东南 1(新加坡)、美国西部(硅谷)实施。 2017 年 3 月 7 日 12:00 在华东 1 实施。 2017 年 3 月 31 日 12:00 在华东 1 、华北 1 实施。 说明 该策略只影响上述已实施地域。您仍可在其他未切换地域同时使用经典网络和专有网络。 具体策略 策略 1:截止到2016 年 6 月 1 日 00:00时间点,在阿里云有经典网络类型的ECS 实例(运行中或者已停止的)的客户,不受切换到专有网络策略影响。只要该地域有库存,就可以继续购买经典网络和专有网络这两种网络类型的 ECS 实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下没有经典网络类型的 ECS 实例(运行中或者已停止的),就只能购买专有网络的 ECS 实例,不能购买经典网络实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下有经典网络类型的 ECS 实例(运行中或者已停止的),只要在实施地域有库存,就可以继续购买经典网络和专有网络两种网络类型的 ECS 实例。 常见问题 Q:阿里云为什么要做这个调整? A:因为专有网络 VPC 更安全,性能更高,体验会更好,用户对网络管理更灵活,支持混合云的场景,代表了未来的发展方向。 Q:除上述地域,其它地域什么时候生效? A:其它地域会在 2017 年 3 月后执行,阿里云会另行通告。 Q:新用户只能购买专有网络类型的 ECS/负载均衡/RDS,对于其它云产品,还支持购买两种网络类型吗? A:支持。但是,建议您购买其它云产品也都购买专有网络类型,否则会对您的使用造成影响,后续其它云产品也会对新用户默认都切换到专有网络 VPC。 Q:如果只能购买专有网络云产品,是否会影响我的使用?比如是否会影响和其它云产品通信? A:正常情况下不会。因为阿里云的云产品绝大部分都支持专有网络 VPC。我们也会尽量确保生效地域的云产品都接入了专有网络 VPC。 Q:如何查询我在各地域能购买哪种网络类型的云产品? A:暂时不能查看,我们会尽快支持开放 OpenAPI 和控制台用户查看。 Q:会不会购买到错误网络类型的云产品? A:由于初期新用户只能购买专有网络的 ECS/负载均衡/RDS 云产品,用户有可能购买到经典网络的其它云产品。请在购买的时候注意网络类型的选择,如购买错误可能会出现使用问题。 Q:购买到了错误网络类型的云产品怎么办? A:可以通过云产品提供的网络切换功能进行网络切换,具体操作请参考各产品控制台。如遇到没有提供网络切换的产品请提工单给阿里云处理(云服务器 ECS 除外)。
2019-12-01 23:30:55 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 为了优化和提升网络体验,阿里云于 2016 年 6 月 16 日 12:00 启动了切换到专有网络策略,即截止到实施时间点在实施地域没有经典网络类型ECS实例(包含运行中或者已停止的)的客户,只能购买专有网络(VPC)类型的ECS产品,不能再购买经典网络类型的ECS实例。该策略会分阶段,按照地域段实施。 地域实施时间点 2016 年 12 月 1 日 12:00 在华南 1 实施。 2017 年 2 月 15 日 12:00 在华北 2、香港、亚太东南 1(新加坡)、美国西部(硅谷)实施。 2017 年 3 月 7 日 12:00 在华东 1 实施。 2017 年 3 月 31 日 12:00 在华东 1 、华北 1 实施。 说明 该策略只影响上述已实施地域。您仍可在其他未切换地域同时使用经典网络和专有网络。 具体策略 策略 1:截止到2016 年 6 月 1 日 00:00时间点,在阿里云有经典网络类型的ECS 实例(运行中或者已停止的)的客户,不受切换到专有网络策略影响。只要该地域有库存,就可以继续购买经典网络和专有网络这两种网络类型的 ECS 实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下没有经典网络类型的 ECS 实例(运行中或者已停止的),就只能购买专有网络的 ECS 实例,不能购买经典网络实例; 如果不满足策略 1,在实施的地域,对应的实施时间之前,您的账号下有经典网络类型的 ECS 实例(运行中或者已停止的),只要在实施地域有库存,就可以继续购买经典网络和专有网络两种网络类型的 ECS 实例。 常见问题 Q:阿里云为什么要做这个调整? A:因为专有网络 VPC 更安全,性能更高,体验会更好,用户对网络管理更灵活,支持混合云的场景,代表了未来的发展方向。 Q:除上述地域,其它地域什么时候生效? A:其它地域会在 2017 年 3 月后执行,阿里云会另行通告。 Q:新用户只能购买专有网络类型的 ECS/负载均衡/RDS,对于其它云产品,还支持购买两种网络类型吗? A:支持。但是,建议您购买其它云产品也都购买专有网络类型,否则会对您的使用造成影响,后续其它云产品也会对新用户默认都切换到专有网络 VPC。 Q:如果只能购买专有网络云产品,是否会影响我的使用?比如是否会影响和其它云产品通信? A:正常情况下不会。因为阿里云的云产品绝大部分都支持专有网络 VPC。我们也会尽量确保生效地域的云产品都接入了专有网络 VPC。 Q:如何查询我在各地域能购买哪种网络类型的云产品? A:暂时不能查看,我们会尽快支持开放 OpenAPI 和控制台用户查看。 Q:会不会购买到错误网络类型的云产品? A:由于初期新用户只能购买专有网络的 ECS/负载均衡/RDS 云产品,用户有可能购买到经典网络的其它云产品。请在购买的时候注意网络类型的选择,如购买错误可能会出现使用问题。 Q:购买到了错误网络类型的云产品怎么办? A:可以通过云产品提供的网络切换功能进行网络切换,具体操作请参考各产品控制台。如遇到没有提供网络切换的产品请提工单给阿里云处理(云服务器 ECS 除外)。
2019-12-01 23:30:58 0 浏览量 回答数 0

云产品推荐

上海奇点人才服务相关的云产品 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 阿里云AIoT