• 关于

    线对增容是什么

    的搜索结果

回答

HashMap HashMap 底层是基于 数组 + 链表 组成的,不过在 jdk1.7 和 1.8 中具体实现稍有 不同 其实1.7一个很明显需要优化的地方就是: 当 Hash 冲突严重时,在桶上形成的链表会变的越来越长,这样在查询时的效 率就会越来越低;时间复杂度为 O(N)。 因此 1.8 中重点优化了这个查询效率。 1.8 HashMap 结构图 JDK 1.8 对 HashMap 进行了修改: 最大的不同就是利用了红黑树,其由数组+链表+红黑树组成。 JDK 1.7 中,查找元素时,根据 hash 值能够快速定位到数组的具体下标, 但之后需要顺着链表依次比较才能查找到需要的元素,时间复杂度取决于链 表的长度,为 O(N)。 为了降低这部分的开销,在 JDK 1.8 中,当链表中的元素超过 8 个以后,会 将链表转换为红黑树,在这些位置进行查找的时候可以降低时间复杂度为 O(logN)。 JDK 1.8 使用 Node(1.7 为 Entry) 作为链表的数据结点,仍然包含 key, value,hash 和 next 四个属性。 红黑树的情况使用的是 TreeNode。 根据数组元素中,第一个结点数据类型是 Node 还是 TreeNode 可以判断该位 置下是链表还是红黑树。 核心成员变量于 1.7 类似,增加了核心变量,如下表。 属性说明TREEIFY_THRESHOLD用于判断是否需要将链表转换为红黑树的阈值,默认 为 8。 put步骤: 判断当前桶是否为空,空的就需要初始化(resize 中会判断是否进行初始 化)。 根据当前 key 的 hashcode 定位到具体的桶中并判断是否为空,为空表明没有 Hash 冲突就直接在当前位置创建一个新桶即可。 如果当前桶有值( Hash 冲突),那么就要比较当前桶中的 key、key 的 hashcode 与写入的 key 是否相等,相等就赋值给 e,在第 8 步的时候会统一进 行赋值及返回。 如果当前桶为红黑树,那就要按照红黑树的方式写入数据。 如果是个链表,就需要将当前的 key、value 封装成一个新节点写入到当前桶的 后面(形成链表)。 接着判断当前链表的大小是否大于预设的阈值,大于时就要转换为红黑树。 如果在遍历过程中找到 key 相同时直接退出遍历。 如果 e != null 就相当于存在相同的 key,那就需要将值覆盖。 后判断是否需要进行扩容. get 方法看起来就要简单许多了。 首先将 key hash 之后取得所定位的桶。 如果桶为空则直接返回 null 。 否则判断桶的第一个位置(有可能是链表、红黑树)的 key 是否为查询的 key,是 就直接返回 value。 如果第一个不匹配,则判断它的下一个是红黑树还是链表。 红黑树就按照树的查找方式返回值。 不然就按照链表的方式遍历匹配返回值。 从这两个核心方法(get/put)可以看出 1.8 中对大链表做了优化,修改为红黑树之 后查询效率直接提高到了 O(logn)。 但是 HashMap 原有的问题也都存在,比如在并发场景下使用时容易出现死循环。 但是为什么呢?简单分析下。 看过上文的还记得在 HashMap 扩容的时候会调用 resize() 方法,就是这里的并 发操作容易在一个桶上形成环形链表;这样当获取一个不存在的 key 时,计算出的 index 正好是环形链表的下标就会出现死循环。 如下图: HashTable HashTable 容器使用 synchronized来保证线程安全,但在线程竞争激烈的情况下 HashTable 的效 率非常低下。 当一个线程访问 HashTable 的同步方法时,其他线程访问 HashTable 的同步方 法可能会进入阻塞或轮询状态。 HashTable 容器在竞争激烈的并发环境下表现出效率低下的原因,是因为所有 访问它的线程都必须竞争同一把锁,假如容器里有多把锁,每一把锁用于锁容 器其中一部分数据,那么当多线程访问容器里不同数据段的数据时,线程间就 不会存在锁竞争,从而可以有效的提高并发访问效率,这就是 ConcurrentHashMap(JDK 1.7) 使用的 锁分段技术。 ConcurrentHashMap 将数据分成一段一段的存储,然后给每一段数据配一把 锁,当一个线程占用锁访问其中一个段数据的时候,其他段的数据也能被其他 线程访问。 有些方法需要跨段,比如 size() 和 containsValue(),它们可能需要锁定整个表 而不仅仅是某个段,这需要按顺序锁定所有段,操作完毕后,又按顺序释放所 有段的锁。 按顺序 很重要,否则极有可能出现死锁,在 ConcurrentHashMap 内部,段数 组是 final 的,并且其成员变量实际也是 final 的,但是,仅仅是将数组声明为 final 的并不保证数组成员也是 final 的,需要实现上的保证。这可以确保不会 出现死锁,因为获得锁的顺序是固定的。 HashTable 的迭代器是强一致性的,而 ConcurrentHashMap 是弱一致的。 ConcurrentHashMap 的 get,clear,iterator 方法都是弱一致性的。 初识ConcurrentHashMap Concurrent翻译过来是并发的意思,字面理解它的作用是处理并发情况的 HashMap。 通过前面的学习,我们知道多线程并发下 HashMap 是不安全的(如死循环),更普遍 的是多线程并发下,由于堆内存对于各个线程是共享的,而 HashMap 的 put 方法 不是原子操作,假设Thread1先 put 值,然后 sleep 2秒(也可以是系统时间片切换失 去执行权),在这2秒内值被Thread2改了,Thread1“醒来”再 get 的时候发现已经不 是原来的值了,这就容易出问题。 那么如何避免这种多线程出错的情况呢? 常规思路就是给 HashMap 的 put 方法加锁(synchronized),保证同一个时刻只允 许一个线程拥有对 hashmap 有写的操作权限即可。然而假如线程1中操作耗时,其 他需要操作该 hashmap 的线程就需要在门口排队半天,严重影响用户体验, HashTable 就是这样子做的。 举个生活中的例子,很多银行除了存取钱,还支持存取贵重物品,贵重物品都放在 保险箱里,把 HashMap 和 HashTable 比作银行,结构: 把线程比作人,对应的情况如下: 多线程下用 HashMap 不确定性太高,有破产的风险,不能选;用 HashTable 不会 破产,但是用户体验不太好,那么怎样才能做到多人存取既不影响他人存值,又不 用排队呢? 有人提议搞个「银行者联盟」,多开几个像HashTable 这种「带锁」的银行就好 了,有多少人办理业务,就开多少个银行,一对一服务,这个区都是大老板,开银 行的成本都是小钱,于是「银行者联盟」成立了。 接下来的情况是这样的:比如用户A和用户B一起去银行存各自的项链,这个「银行 者联盟」操作后,然后对用户A说,1号银行现在没人你可以去那存,不用排队,然 后用户A就去1号银行存项链,1号银行把用户A接进门,马上拉闸,然后把用户A的 项链放在第x行第x个保险箱,等用户A办妥离开后,再开闸;对于用户B同理。此时 不管用户A和用户B在各自银行里面待多久都不会影响到彼此,不用担心自己的项链 被人偷换了。这就是ConcurrentHashMap的设计思路,用一个图来理解 从上图可以看出,此时锁的是对应的单个银行,而不是整个「银行者联盟」。分析 下这种设计的特点: 多个银行组成的「银行者联盟」 当有人来办理业务时,「银行者联盟」需要确定这个人去哪个银行 当此人去到指定银行办理业务后,该银行上锁,其他人不能同时执行修改操作,直 到此人离开后解锁. ConcurrentHashMap源码解析 ConcurrentHashMap 同样也分为 1.7 、1.8 版,两者在实现上略有不同。 先来看看 1.7 的实现,下面是结构图: 如图所示,是由 Segment 数组、HashEntry 组成,和 HashMap 一样,仍然是数组 加链表。主要是通过分段锁实现的。 关于分段锁 段Segment继承了重入锁ReentrantLock,有了锁的功能,每个锁控制的是一段, 当每个Segment越来越大时,锁的粒度就变得有些大了。 分段锁的优势在于保证在操作不同段 map 的时候可以并发执行,操作同段 map 的时候,进行锁的竞争和等待。这相对于直接对整个map同步 synchronized是有优势的。 缺点在于分成很多段时会比较浪费内存空间(不连续,碎片化); 操作map时竞争 同一个分段锁的概率非常小时,分段锁反而会造成更新等操作的长时间等待; 当 某个段很大时,分段锁的性能会下降。 1.7 已经解决了并发问题,并且能支持 N 个 Segment 这么多次数的并发,但依然存 在 HashMap 在 1.7 版本中的问题。 那就是查询遍历链表效率太低。 因此 1.8 做了一些数据结构上的调整。 首先来看下底层的组成结构: 其实和 1.8 HashMap 结构类似,当链表节点数超过指定阈值的话,也是会转换成红 黑树的,大体结构也是一样的。 那么 JDK 1.8 ConcurrentHashMap 到底是如何实现线程安全的? 答案:其中抛弃了原有的Segment 分段锁,而采用了 CAS + synchronized 来保证 并发安全性。(cas:比较并替换) **① 基本组成 ** 抛弃了 JDK 1.7 中原有的 Segment 分段锁,而采用了 CAS + synchronized 来 保证并发安全性。 将JDK 1.7 中存放数据的 HashEntry 改为 Node,但作用是相同的。、 我们来看看 ConcurrentHashMap 的几个重要属性. 重要组成元素 Node:链表中的元素为 Node 对象。他是链表上的一个节点,内部存储了 key、 value 值,以及他的下一 个节点的引用。这样一系列的 Node 就串成一串,组成一 个链表。 ForwardingNode:当进行扩容时,要把链表迁移到新的哈希表,在做这个操作 时,会在把数组中的头节点替换为 ForwardingNode 对象。ForwardingNode 中不 保存 key 和 value,只保存了扩容后哈希表 (nextTable)的引用。此时查找相应 node 时,需要去 nextTable 中查找。 TreeBin:当链表转为红黑树后,数组中保存的引用为 TreeBin,TreeBin 内部不保 存 key/value,他保存了 TreeNode 的 list 以及红黑树 root。 TreeNode:红黑树的节点。 **② put 方法过程 ** 存储结构定义了容器的 “形状”,那容器内的东西按照什么规则来放呢?换句话讲, 某个 key 是按 照什么逻辑放入容器的对应位置呢? 我们假设要存入的 key 为对象 x,这个过程如下 : 1、通过对象 x 的 hashCode () 方法获取其 hashCode; 2、将 hashCode 映射到数组的某个位置上; 3、把该元素存储到该位置的链表中。 put 方法用来把一个键值对存储到 map 中。代码如下: 实际调用的是 putVal 方 法,第三个参数传入 false,控制 key 存在时覆盖原来的值。 请先看完代码注释,有个大致的了解,然后我们更加详细的学习一下: 判断存储的 key、value 是否为空,若为空,则抛出异常,否则,进入步骤 2。 计算 key 的 hash 值,随后进入自旋,该自旋可以确保成功插入数据,若 table 表为空或者长度为 0,则初始化 table 表,否则,进入步骤 3。 根据 key 的 hash 值取出 table 表中的结点元素,若取出的结点为空(该桶为 空),则使用 CAS 将 key、value、hash 值生成的结点放入桶中。否则,进入 步骤 4。 若该结点的的 hash 值为 MOVED(-1),则对该桶中的结点进行转移,否则, 进入步骤 5。 5 . 对桶中的第一个结点(即 table 表中的结点)进行加锁,对该桶进行遍历,桶中 的结点的 hash 值与 key 值与给定的 hash 值和 key 值相等,则根据标识选择是 否进行更新操作(用给定的 value 值替换该结点的 value 值),若遍历完桶仍 没有找到 hash 值与 key 值和指定的 hash 值与 key 值相等的结点,则直接新生 一个结点并赋值为之前后一个结点的下一个结点。进入步骤 6。 若 binCount 值达到红黑树转化的阈值,则将桶中的结构转化为红黑树存储, 后,增加 binCount 的值。 如果桶中的第一个元素的 hash 值大于 0,说明是链表结构,则对链表插入或者 更新。 如果桶中的第一个元素是 TreeBin,说明是红黑树结构,则按照红黑树的方式进 行插入或者更新。 在锁的保护下,插入或者更新完毕后,如果是链表结构,需要判断链表中元素 的数量是否超过 8(默认),一旦超过,就需要考虑进行数组扩容,或者是链表 转红黑树。 扩容 什么时候会扩容? 使用put()添加元素时会调用addCount(),内部检查sizeCtl看是否需要扩容。 tryPresize()被调用,此方法被调用有两个调用点: 链表转红黑树(put()时检查)时如果table容量小于64(MIN_TREEIFY_CAPACITY),则会 触发扩容。 调用putAll()之类一次性加入大量元素,会触发扩容。 addCount() addCount()与tryPresize()实现很相似,我们先以addCount()分析下扩容逻辑: **1.链表转红黑树 ** 首先我们要理解为什么 Map 需要扩容,这是因为我们采用哈希表存储数据,当固定 大小的哈希表存 储数据越来越多时,链表长度会越来越长,这会造成 put 和 get 的 性能下降。此时我们希望哈希表中多一些桶位,预防链表继续堆积的更长。 ConcurrentHashMap 有链表转红黑树的操作,以提高查找的速度,红黑树时间复 杂度为 O (logn),而链表是 O (n/2),因此只在 O (logn)<O (n/2) 时才会进行转换, 也就是以 8 作为分界点。 接下来我们分析 treeifyBin 方法代码,这个代码中会选择是把此时保存数据所在的 链表转为红黑树,还是对整个哈希表扩容。 treeifyBin 不一定就会进行红黑树转换,也可能是仅仅做数组扩容。 构造完TreeBin这个空节点之后,就开始构造红黑树,首先是第一个节点,左右 子节点设置为空,作为红黑树的root节点,设置为黑色,父节点为空。 然后在每次添加完一个节点之后,都会调用balanceInsertion方法来维持这是一 个红黑树的属性和平衡性。红黑树所有操作的复杂度都是O(logn),所以当元素量比 较大的时候,效率也很高。 **数组扩容 ** 我们大致了解了 ConcurrentHashMap 的存储结构,那么我们思考一个问题,当数 组中保存的链表越来越多,那么再存储进来的元素大概率会插入到现有的链表中, 而不是使用数组中剩下的空位。 这样会造成数组中保存的链表越来越长,由此导致 哈希表查找速度下降,从 O (1) 慢慢趋近于链表 的时间复杂度 O (n/2),这显然违背 了哈希表的初衷。 所以 ConcurrentHashMap 会做一个操作, 称为扩容。也就是把数组长度变大,增 加更多的空位出来,终目的就是预防链表过长,这样查找的时间复杂度才会趋向于 O (1)。扩容的操作并不会在数组没有空位时才进行,因为在桶位快满时, 新保存元 素更大的概率会命中已经使用的位置,那么可能后几个桶位很难被使用,而链表却 越来 越长了。ConcurrentHashMap 会在更合适的时机进行扩容,通常是在数组中 75% 的位置被使用 时。 其实以上内容和 HashMap 类似,ConcurrentHashMap 此外提供了线程安全的保 证,它主要是通 过 CAS 和 Synchronized 关键字来实现,我们在源码分析中再详细 来看。 我们做一下总结: 1、ConcurrentHashMap 采用数组 + 链表 + 红黑树的存储结构; 2、存入的 Key 值通过自己的 hashCode 映射到数组的相应位置; 3、ConcurrentHashMap 为保障查询效率,在特定的时候会对数据增加长度,这个 操作叫做扩容; 4、当链表长度增加到 8 时,可能会触发链表转为红黑树(数组长度如果小于 64, 优先扩容,具体 看后面源码分析)。 接下来,我们的源码分析就从 ConcurrentHashMap 的构成、保存元素、哈希算 法、扩容、查找数 据这几个方面来进行 扩容后数组容量为原来的 2 倍。 **数据迁移( 扩容时的线程安全) ** ConcurrentHashMap 的扩容时机和 HashMap 相同,都是在 put 方法的后一步 检查是否需要扩容,如果需要则进行扩容,但两者扩容的过程完全不同, ConcurrentHashMap 扩容的方法叫做 transfer,从 put 方法的 addCount 方法进 去,就能找到 transfer 方法,transfer 方法的主要思路是: 首先需要把老数组的值全部拷贝到扩容之后的新数组上,先从数组的队尾开始 拷贝; 拷贝数组的槽点时,先把原数组槽点锁住,保证原数组槽点不能操作,成功拷 贝到新数组时,把 原数组槽点赋值为转移节点; 这时如果有新数据正好需要 put 到此槽点时,发现槽点为转移节点,就会一直 等待,所以在扩容完成之前,该槽点对应的数据是不会发生变化的; 从数组的尾部拷贝到头部,每拷贝成功一次,就把原数组中的节点设置成转移 节点; 直到所有数组数据都拷贝到新数组时,直接把新数组整个赋值给数组容器,拷 贝完成 putTreeVal()与此方法遍历方式类似不再介绍。  ④ get 方法过程 ConcurrentHashMap 读的话,就比较简单,先获取数组的下标,然后通过判断数 组下标的 key 是 否和我们的 key 相等,相等的话直接返回,如果下标的槽点是链表 或红黑树的话,分别调用相应的 查找数据的方法,整体思路和 HashMap 很像,源 码如下: 计算 hash 值。 根据 hash 值找到数组对应位置: (n – 1) & h。 根据该位置处结点性质进行相应查找。 如果该位置为 null,那么直接返回 null。 如果该位置处的结点刚好就是需要的,返回该结点的值即可。 如果该位置结点的 hash 值小于 0,说明正在扩容,或者是红黑树。 如果以上 3 条都不满足,那就是链表,进行遍历比对即可。 ** 初始化数组 ** 数组初始化时,首先通过自旋来保证一定可以初始化成功,然后通过 CAS 设置 SIZECTL 变量的值,来保证同一时刻只能有一个线程对数组进行初始化,CAS 成功 之后,还会再次判断当前数组是否已经初始化完成,如果已经初始化完成,就不会 再次初始化,通过自旋 + CAS + 双重 check 等 手段保证了数组初始化时的线程安 全,源码如下: 里面有个关键的值 sizeCtl,这个值有多个含义。 1、-1 代表有线程正在创建 table; 2、-N 代表有 N-1 个线程正在复制 table; 3、在 table 被初始化前,代表 根据构造函数传入的值计算出的应被初始化的大小; 4、在 table 被初始化后,则被 设置为 table 大小 的 75%,代表 table 的容量(数组容量)。 initTable 中使用到 1 和 4,2 和 3 在其它方法中会有使用。下面我们可以先看下 ConcurrentHashMap 的构造方法,里面会使用上面的 3 最后来回顾总结下HashMap和ConcurrentHashMap对比 ConcurrentHashMap 和 HashMap 两者的相同之处: 1.数组、链表结构几乎相同,所以底层对数据结构的操作思路是相同的(只是思路 相同,底层实现 不同); 2.都实现了 Map 接口,继承了 AbstractMap 抽象类,所以大多数的方法也都是相 同的, HashMap 有的方法,ConcurrentHashMap 几乎都有,所以当我们需要从 HashMap 切换到 ConcurrentHashMap 时,无需关心两者之间的兼容问题 不同点: 1.红黑树结构略有不同,HashMap 的红黑树中的节点叫做 TreeNode,TreeNode 不仅仅有属 性,还维护着红黑树的结构,比如说查找,新增等等; ConcurrentHashMap 中红黑树被拆分成 两块,TreeNode 仅仅维护的属性和查找 功能,新增了 TreeBin,来维护红黑树结构,并负责根 节点的加锁和解锁; 2.新增 ForwardingNode (转移)节点,扩容的时候会使用到,通过使用该节点, 来保证扩容时的线程安全。
剑曼红尘 2020-03-25 11:21:44 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) 让你体验超大文件上传、下载,飞一般的感觉~~!! OSS 是什么?(曾经很多站长、开发者询问过 … &#x...
聚小编 2019-12-01 20:29:02 14239 浏览量 回答数 4

问题

企业级分布式应用服务 EDAS名词含义是什么?

Ali-TomcatAli-Tomcat 是 EDAS 中的服务运行时必须依赖的一个容器,主要集成了服务的发布、订阅、调用链追踪等一系列的核心功能,无论是开发环境还是运行时,均必须将应用程序发布在该...
猫饭先生 2019-12-01 21:03:04 1084 浏览量 回答数 0

问题

如何快速掌握性能知识体系,做好性能测试?

做开发测试的同学都知道,网站性能是影响用户访问的一个重要因素。如果你的网站打开速度很慢,那么你的访客很容易流失,这样会造成业务受损。所以做好性能测试,是开发测试人员必须考虑的问题。阿里...
云效平台 2019-12-01 21:40:27 4526 浏览量 回答数 0

问题

DRDS是什么?

分布式关系型数据库服务(Distributed Relational Database Service , 简称 DRDS )专注于解决单机关系型数据库扩展性问题,具备轻量(无状态)、灵活、稳定、高...
猫饭先生 2019-12-01 21:19:21 1421 浏览量 回答数 0

问题

为什么要分库分表(设计高并发系统的时候,数据库层面该如何设计)?【Java问答】41期

面试题 为什么要分库分表(设计高并发系统的时候,数据库层面该如何设计)?用过哪些分库分表中间件?不同的分库分表中间件都有什么优点和缺点?你们具体是如何对数...
剑曼红尘 2020-06-19 13:47:21 0 浏览量 回答数 0

回答

  定位(Positioning),是由著名的美国营销专家艾尔·列斯(AlRies)与杰克·特罗(Jack   Trout)于70年代早期提出来的,当时,他们在美国《广告时代》发表了名为《定位时代》系列文章,以后,他们又把这些观点和理论集中反映在他们的第一本著作《广告攻心战略》一书中,正如他们所言,这是一本关于传播沟通的教科书。1996年,杰克·特罗整理了25年来的工作经验,写出了《新定位》一书。也许是更加符合了时代的要求,但其核心思想却仍然源自于他们于1972年提出的定位论。定位理论的产生,源于人类各种信息传播渠道的拥挤和阻塞,可以归结为信息爆炸时代对商业运作的影响结果。科技进步和经济社会的发展,几乎把消费者推到了无所适从的境地。首先是媒体的爆炸:广播、电视、互联网,录音带、录像带、光盘使消费者目不暇接。其次是产品的爆炸:仅电视就有大屏幕的、小屏幕的,平面直角的、超平的、纯平的,从耐用消费品到日用品,都给人以眼花缭乱的感觉。再就是广告的爆炸:电视广告、广播广告、报刊广告、街头广告、楼门广告、电梯广告,真可谓无孔不入。因此,定位就显得非常必要。   按照艾尔·列斯与杰克·特罗的观点:定位,是从产品开始,可以是一件商品,一项服务,一家公司,一个机构,甚至于是一个人,也可能是你自己。定位并不是要你对产品做什么事情,定位是你对产品在未来的潜在顾客的脑海里确定一个合理的位置,也就是把产品定位在你未来潜在顾客的心目中。定位可以看成是对现有产品的一种创造性试。“改变的是名称、价格及包装,实际上对产品则完全没有改变,所有的改变,基本上是在作着修饰而已,其目的是在潜在顾客心中得到有利的地位”。   定位的前提   按照艾尔·列斯与杰克·特罗的理论,我们目前已成为一个传播过多的社会,而消费者只能接受有限的信息,消费者抵御这种“信息爆炸”的最有力武器就是最小努力法则--痛恨复杂,喜欢简单。现有产品在顾客心目中都有一定的位置,例如,人们认为可口可乐是世界上最大饮料生产商,格兰仕是中国最大的微波炉生产商,北京同仁医院是中国最著名的眼科医院等,这些产品和服务的提供者在与消费者长期的交易中所拥有的地位,是其他人很难取代的。也就是说,消费者对品牌的印象不会轻易改变。定位的基本原则不是去创造某种新奇的或与众不同的东西,而是去操纵人们心中原本的想法,去打开联想之结,目的是要在顾客心目中,占据有利的地位。唯其如此,方能在市场上赢得有利的竞争地位。   一般说来,企业在营销中的失策表现为两大类:一是在市场逐渐成熟后,如果企业不能及时构思新的定位,从而使其陷入困境。例如,在冰箱、电视机等已成为国内的成熟技术之时,再有一个厂家去宣传自己是第一个引进外国技术,就会让人笑掉大牙。而海尔、长虹等企业诉求“海尔,中国造”、“长虹,以振兴民族工业为已任”,则收到了极好的效果。二是随着企业不断扩张和进行多元化角逐,而使消费者对产品的印象愈来愈模糊。美国雪佛莱汽车公司就经历过这样的事情。过去,雪佛莱汽车是美国家庭汽车的代名词,但在雪佛莱将生产线扩大到涵盖卡车、跑车等车型后,消费者心中原有的“雪佛莱就是美国家庭房车”的印象焦点反而模糊了,而让福特站上了第一品牌的宝座。在我国,“三九胃泰”曾是著名的胃药生产商,而后,又扩张到啤酒的生产,这无疑是为厂家出了个大难题:饮酒对胃肠道是一个不良刺激,自己生产的产品又是治疗胃病,是酒好还是胃药好。这不正是“矛盾”这一古代寓言的现代翻版吗。然而,这也正是“定位”理论的用武之地。   定位的真谛就是“攻心为上”,消费者的心灵才是营销的终级战场。从广告传播的角度来看定位,它不是要琢磨产品,因为产品已是生出来的孩子,已经定型,不大容易改变,而容易改变的是消费者的“心”。   要抓住消费者的心,必须了解他们的思考模式,这是进行定位的前提。《新定位》一书列出了消费者的五大思考模式,以帮助企业占领消费者心目中的位置。   模式一:消费者只能接收有限的信息。在超载的信息中,消费者会按照个人的经验、喜好、兴趣甚至情绪,选择接受哪些信息,记忆哪些信息。因此,较能引起兴趣的产品种类和品牌,就拥有打入消费者记忆的先天优势。例如,我国的杭州娃哈哈集团,最初是以生产“娃哈哈”儿童营养液而一举成名。它的成功就是由于,产品定位准确,而广告定位更是让人过目不忘,因为它源于一首人人熟知的儿歌,很容易引进儿童与家长的共鸣。   模式二:消费者喜欢简单,讨厌复杂。在各种媒体广告的狂轰滥炸下,消费者最需要简单明了的信息。广告传播信息简化的诀窍,就是不要长篇大论,而是集中力量将一个重点清楚地打入消费者心中,突破人们痛恨复杂的心理屏障。在这一点上最令人称道是我国的一种驱虫药广告,只须服两片,治蛲虫是两片,治钩虫也是两片。人们也许记不住复杂的药品名称,但只需说“两片”,药店的售货员就知道你要的是什么药。反过来,如果厂家在广告中介绍它的产品如何如何先进,效果如何显著,其结果可想而知。   模式三:消费者缺乏安全感。由于缺乏安全感,消费者会买跟别人一样的东西,免除花冤枉钱或被朋友批评的危险。所以,人们在购买商品前(尤其是耐用消费品),都要经过缜密的商品调查。而广告定位传达给消费者简单而又易引进兴趣的信息,正好使自己的品牌易于在消费者中传播。如果一位消费者要买驱虫药,必然先向朋友打听,一说“两片”,既满足了消费者安全感的需要,也无须记一些专业名词。   模式四:消费者对品牌的印象不会轻易改变。虽然一般认为新品牌有新鲜感,较能引人注目,但是消费者真能记到脑子里的信息,还是耳熟能详的东西。比如,对可口可乐公司的员工而言,它是总部设在亚特兰大市的一个“公司”,一个“机构”,而在一般消费者心目中,可口可乐是一种甜美的、深色的、加了碳酸气的饮料,可口可乐是一个著名饮料品牌。如果,可口可乐公司那天心血来潮,去生产热门的香烟或者是啤酒,也许正是可口可乐的可叹可悲之时。   模式五:消费者的想法容易失去焦点。虽然盛行一时的多元化、扩张生产线增加了品牌多元性,但是却使消费者模糊了原有的品牌印象。美国舒洁公司在纸业的定位就是一例。舒洁原本是以生产舒洁卫生纸起家的,后来,它把自己的品牌拓展到舒洁纸面巾、舒洁纸餐巾以及其他纸产品,以至于在数十亿美元的市场中,拥有了最大的市场占有率。然而,正是这些盲目延伸的品牌,使消费者失去了对其注意的焦点,最终让宝洁公司乘虚而入。难怪一位营销专家以美国人幽默方式发问:舒洁餐巾纸,舒洁卫生纸,到底哪个牌子是为鼻子而设计的呢。   所以,企业在定位中一定要掌握好这些原则:消费者接受信息的容量是有限的,广告宣传“简单”就是美,一旦形成的定位很难在短时间内消除,盲目的品牌延伸会摧毁自己在消费者心目中的既有定位。所以,无论是产品定位,还是广告定位一定要慎之又慎。   定位的方法   在广告泛滥、信息爆炸,消费者必然要用尽心力筛选掉大部分垃圾。例如,尽管市场上饮料众多,人们只知道有可口可乐、娃哈哈、乐百氏等几种品牌,并且这些品牌在他们心目中还是有一定顺序的,不用说,可口可乐一定是第一,至于第二、第三就要看厂家的定位策略了。人们总是容易记住第一名,如谁都知道世界第一高峰是珠穆拉玛峰,但极少有人能说出第二大高峰,人们能很快说出体育比赛的冠军,亚军则不易给人留下印象。所以,在具体操作中营销人员要善于找出自己品牌所拥有的令人信服的某种重要属性或利益。通过一定的策略和方法,让自己的品牌给人们留下深刻的印象。这些方法一般有:   强化自己已有的定位。既然现有的产品和服务在消费者心目中都有一定的位置,如果这种定位对企业有利的话,就要反复向人们宣传这种定位,强化本企业的产品在消费者心目的形象,也就是自己的特色,而这种强化必须是实事求是的。如,在我国的冰箱生产厂家中,海尔反复强调自己的“高品质”,新飞则宣传自己是节能冰箱,而美菱把文章做在了“保鲜”上。   比附定位。使定位对象与竞争对象(已占有牢固位置)发生关联,并确立与竞争对象的定位相反的或可比的定位概念。如美国一家处于第二位的出租汽车公司,在广告中反复宣传:我们是第二,所以我们更加努力啊。这样,既强化了自己与第一的关系,又表明了自己处于弱者的位置,更易引起人们“同情弱者”的共鸣。   单一位置策略。处于领导地位者,要以另外的新品牌来压制竞争者。因为每一个品牌都在其潜在顾客心目中安置了独自所占据的一个特定处所。这是作为市场领导者所要采取的策略。既然自己是老大,“卧榻之侧,哪容他人酣睡”,因此,在各种场合宣传自己第一的形象自然就在情理之中。   寻找空隙策略。寻求消费者心目中的空隙,然后加以填补。其中有价格(高低),性别,年龄,一天中的时段,分销渠道,大量使用者的位置等各种空隙。如,万宝路在美国是著名的香烟品牌,而一个叫窈窕牌的香烟品牌,就是以女性抽烟者为突破口挑战万宝路而大获成功。   类别品牌定位。当一个强大的品牌名称成了产品类别名称的代表或代替物时,必须给公司一个真正成功的新产品以一个新的名称,而不能采用“搭便车”的做法,沿袭公司原有产品的名称。这像“跷跷板”原理,当一种上来时,另一种就下去。因为一个名称不能代表两个迥然不同的产品。宝洁公司的多品牌策略就大有可取之处。   再定位。也就是重新定位,意即打破事物(例如产品)在消费者心目中所保持的原有位置与结构,使事物按照新的观念在消费者心目中重新排位,调理关系,以创造一个有利于自己的新的秩序。这意味着必须先把旧的观念或产品搬出消费者的记忆,才能把另一个新的定位装进去。海尔在最初是以宣传自己冰箱的品质优良作为定位,而在产品延伸之后,很快就突出了“中国造”、“向国际营销商授权”等新的定位。   需要指出的是,由于艾尔·列斯与杰克·特罗都是广告人出身,他们的定位理论往往局限于一种广告传播策略,强调让产品占领消费者心目中的空隙。目前,定位理论对营销的影响远远超过了原先把它作为一种传播技巧的范畴,而演变为营销策略的一个基本步骤。这反映在营销大师科特勒对定位下的定义中。他认为,定位是对公司的提供物(原文是offer)和形象的策划行为,目的是使它在目标消费者的心目中占据一个独特的有价值的位置。因此,“营销人员必须从零开始,使产品特色确实符合所选择的目标市场。”科特勒把艾尔·列斯与杰克·特罗的定位理论归结为“对产品的心理定位和再定位”。显然,除此之外,还有对潜在产品的定位。这就给定位理论留下了更为广阔的发展空间。
寒凝雪 2019-12-02 01:17:15 0 浏览量 回答数 0

回答

前言概述 本文介绍了使用函数计算部署深度学习 AI 推理的最佳实践, 其中包括使用 FUN 工具一键部署安装第三方依赖、一键部署、本地调试以及压测评估, 全方位展现函数计算的开发敏捷特性、自动弹性伸缩能力、免运维和完善的监控设施。 1.1 DEMO 概述 image 通过上传一个猫或者狗的照片, 识别出这个照片里面的动物是猫还是狗 DEMO 示例效果入口: http://sz.mofangdegisn.cn DEMO 示例工程地址: https://github.com/awesome-fc/cat-dog-classify 开通服务 免费开通函数计算, 按量付费,函数计算有很大的免费额度。 免费开通文件存储服务NAS, 按量付费 1.2 解决方案 image 如上图所示, 当多个用户通过对外提供的 url 访问推理服务时候,每秒的请求几百上千都没有关系, 函数计算平台会自动伸缩, 提供足够的执行实例来响应用户的请求, 同时函数计算提供了完善的监控设施来监控您的函数运行情况。 1.3. Serverless 方案与传统自建服务方案对比 1.3.1 卓越的工程效率 自建服务 函数计算 Serverless 基础设施 需要用户采购和管理 无 开发效率 除了必要的业务逻辑开发,需要自己建立相同线上运行环境, 包括相关软件的安装、服务配置、安全更新等一系列问题 只需要专注业务逻辑的开发, 配合 FUN 工具一键资源编排和部署 学习上手成本 可能使用 K8S 或弹性伸缩( ESS ),需要了解更多的产品、名词和参数的意义 会编写对应的语言的函数代码即可 1.3.2 弹性伸缩免运维 自建服务 函数计算 Serverless 弹性高可用 需要自建负载均衡 (SLB),弹性伸缩,扩容缩容速度较 FC 慢 FC系统固有毫秒级别弹性伸缩,快速实现底层扩容以应对峰值压力,免运维 监控报警查询 ECS 级别的 metrics 提供更细粒度的函数执行情况,每次访问函数执行的 latency 和日志等, 更加完善的报警监控机制 1.3.3 更低的成本 函数计算 (FC) 固有自动伸缩和负载均衡功能,用户不需要购买负载均衡 (SLB) 和弹性伸缩。 具有明显波峰波谷的用户访问场景(比如只有部分时间段有请求,其他时间甚至没有请求),选择按需付费,只需为实际使用的计算资源付费。 对于明显波峰波谷或者稀疏调用具有低成本优势, 同时还保持了弹性能力,以后业务规模做大以后并没有技术切换成本,同时财务成本增长配合预付费也能保持平滑。 部分请求持续平稳的场景下,可以配合预付费解决按需付费较高单价问题。函数计算成本优化最佳实践文档。 假设有一个在线计算服务,由于是CPU 密集型计算, 因此在这里我们将平均 CPU 利用率作为核心参考指标对成本,以一个月为周期,10台 C5 ECS 的总计算力为例,总的计算量约为 30% 场景下, 各解决方案 CPU 资源利用率使用情况示意图大致如下: image 由上图预估出如下计费模型: 函数计算预付费 3CU 一个月: 246.27 元, 计算能力等价于 ECS 计算型 C5 ECS 计算型 C5 (2vCPU,4GB)+云盘: 包月219 元,按量: 446.4 元 包月10 Mbps 的 SLB: 526.52 元(这里做了一定的流量假设), 弹性伸缩免费 饱和使用下,函数计算按量付费的一台机器成本约为按量付费 C5 ECS 的2 倍 平均CPU使用率 计算费用 SLB 总计 函数计算组合付费 >=80% 738+X(246.273+X) 无 <= 738+X 按峰值预留ECS <=30% 2190(10219) 526.52 >=2716.52 弹性伸缩延迟敏感 <=50% 1314(102193/5) 526.52 >= 1840.52 弹性伸缩成本敏感 <=70% 938.57 (102193/7) 526.52 >= 1465.09 注: 这里假设函数逻辑没有公网下行流量费用, 即使有也是一致的, 这里成本比较暂不参与 延时敏感,当 CPU 利用率大于等于 50% 就需要开始进行扩容,不然更来不及应对峰值 成本敏感,当 CPU 利用率大约 80% 即开始进行扩容, 能容受一定几率的超时或者5XX 上表中, 其中函数计算组合付费中的 X 为按需付费的成本价,假设按需付费的计算量占整个计算量的 10%,假设 CPU 利用率为100%, 对应上表,那么需要 3 台 ECS 的计算能力即可。因此 FC 按量付费的成本 X = 3 ️ 446.4 ️ 10% ️ 2 = 267.84 ( FC 按量付费是按量 ECS 的2倍),这个时候函数计算组合付费总计 1005.8 元。 在这个模型预估里面, 只要 FC 按量付费占整个计算量小于 20%, 即使不考虑 SLB, 单纯考虑计算成本, 都是有一定优势的。 1.3.4. 小结 基于函数计算进行 AI 推理等 CPU 密集型的主要优势: 上手简单, 只专注业务逻辑开发, 极大提高工程开发效率。 自建方案有太多学习和配置成本,如针对不同场景,ESS 需要做各种不同的参数配置 系统环境的维护升级等 免运维,函数执行级别粒度的监控和告警。 毫秒级弹性扩容,保证弹性高可用,同时能覆盖延迟敏感和成本敏感类型。 在 CPU 密集型的计算场景下, 通过设置合理的组合计费模式, 在如下场景中具有成本优势: 请求访问具有明显波峰波谷, 其他时间甚至没有请求 有一定稳定的负载请求, 但是有部分时间段请求量突变剧烈 打包代码ZIP包和部署函数 FUN 操作简明视频教程 开通服务 免费开通函数计算, 按量付费,函数计算有很大的免费额度。 免费开通文件存储服务NAS, 按量付费 2.1 安装第三方包到本地并上传到NAS 2.1.1 安装最新的Fun 安装版本为8.x 最新版或者10.x 、12.x nodejs 安装 funcraf 2.1.2 Clone 工程 & Fun 一键安装第三方库到本地 git clone https://github.com/awesome-fc/cat-dog-classify.git 复制 .env_example 文件为 .env, 并且修改 .env 中的信息为自己的信息 执行 fun install -v, fun 会根据 Funfile 中定义的逻辑安装相关的依赖包 image root@66fb3ad27a4c: ls .fun/nas/auto-default/classify model python root@66fb3ad27a4c: du -sm .fun 697 .fun 根据 Funfile 的定义: 将第三方库下载到 .fun/nas/auto-default/classify/python 目录下 本地 model 目录移到 .fun/nas/auto-default/model 目录下 安装完成后,从这里我们看出, 函数计算引用的代码包解压之后已经达到了 670 M, 远超过 50M 代码包限制, 解决方案是 NAS 详情可以参考: 挂载NAS访问,幸运的是 FUN 工具一键解决了 nas 的配置和文件上传问题。 2.1.3. 将下载的依赖的第三方代码包上传到 NAS fun nas init fun nas info fun nas sync fun nas ls nas://classify:/mnt/auto/ 依次执行这些命令,就将本地中的 .fun/nas/auto-default 中的第三方代码包和模型文件传到 NAS 中, 依次看下这几个命令的做了什么事情: fun nas init: 初始化 NAS, 基于您的 .env 中的信息获取(已有满足条件的nas)或创建一个同region可用的nas fun nas info: 可以查看本地 NAS 的目录位置, 对于此工程是 $(pwd)/.fun/nas/auto-default/classify fun nas sync: 将本地 NAS 中的内容(.fun/nas/auto-default/classify)上传到 NAS 中的 classify 目录 fun nas ls nas:///mnt/auto/: 查看我们是否已经正确将文件上传到了 NAS 登录 NAS 控制台 https://nas.console.aliyun.com 和 VPC 控制台 https://vpc.console.aliyun.com可以观察到在指定的 region 上有 NAS 和相应的 vpc 创建成功 2.2 本地调试函数 在 template.yml 中, 指定了这个函数是 http 类型的函数, 所以根据 fun 的提示: Tips for next step Invoke Event Function: fun local invokeInvoke Http Function: fun local startBuild Http Function: fun buildDeploy Resources: fun deploy 执行 fun local start, 本地就会启动一个 http server 来模拟函数的执行, 然后我们 client 端可以使用 postman, curl 或者浏览器, 比如对于本例: image image 2.3 部署函数到FC平台 本地调试OK 后,我们接下来将函数部署到云平台: 修改 template.yml LogConfig 中的 Project, 任意取一个不会重复的名字即可,有两处地方需要更改,然后执行 fun deploy 注意: template.yml 注释的部分为自定义域名的配置, 如果想在 fun deploy 中完成这个部署工作: 先去域名解析, 比如在示例中, 将域名 sz.mofangdegisn.cn 解析到 123456.cn-hangzhou.fc.aliyuncs.com, 对应的域名、accountId 和 region 修改成自己的 去掉 template.yml 中的注释, 修改成自己的域名 执行 fun deploy 这个时候如果没有自定义域名, 直接通过浏览器访问http trigger 的url, 比如 https://123456.cn-shenzhen.fc.aliyuncs.com/2016-08-15/proxy/classify/cat-dog/ 会被强制下载. 原因:https://help.aliyun.com/knowledge_detail/56103.html#HTTP-Trigger-compulsory-header image 登录控制台https://fc.console.aliyun.com,可以看到service 和函数已经创建成功,并且 service 也已经正确配置。 image 在这里,我们发现第一次打开页面访问函数的时候,执行环境实例冷启动时间非常长, 如果是一个在线AI推理服务,对响应时间非常敏感,冷启动引起的毛刺对于这种类型的服务是不可接受的,接下来,本文讲解如何利用函数计算的预留模式来消除冷启动带来的负面影响。 使用预留模式消除冷启动毛刺 函数计算具有动态伸缩的特性, 根据并发请求量,自动弹性扩容出执行环境来执行环境,在这个典型的深度学习示例中,import keras 消耗的时间很长 , 在我们设置的 1 G 规格的函数中, 并发访问的时候耗时10s左右, 有时甚至20s+ start = time.time() from keras.models import model_from_json print("import keras time = ", time.time()-start) 3.1 函数计算设置预留 预留操作简明视频教程 在 FC 控制台,发布版本,并且基于该版本创建别名 prod,并且基于别名 prod 设置预留, 操作过程请参考:https://help.aliyun.com/document_detail/138103.html 将该函数的 http trigger 和自定义域名的设置执行 prod 版本 image image 一次压测结果 imageimage 从上面图中我们可以看出,当函数执行的请求到来时,优先被调度到预留的实例中被执行, 这个时候是没有冷启动的,所以请求是没有毛刺的, 后面随着测试的压力不断增大(峰值TPS 达到 1184), 预留的实例不能满足调用函数的请求, 这个时候函数计算就自动进行按需扩容实例供函数执行,此时的调用就有冷启动的过程, 从上面我们可以看出,函数的最大 latency 时间甚至达到了 32s,如果这个web AP是延时敏感的,这个 latency 是不可接受的。 总结 函数计算具有快速自动伸缩扩容能力 预留模式很好地解决了冷启动中的毛刺问题 开发简单易上手,只需要关注具体的代码逻辑, Fun 工具助您一键式部署运用 函数计算具有很好监控设施, 您可以可视化观察您函数运行情况, 执行时间、内存等信息
1934890530796658 2020-03-27 18:21:48 0 浏览量 回答数 0

问题

阿里云的产品都是干嘛的

首先给大家推荐一个好链接,大家看了就知道:https://dwz.cn/dR4mHFaw 最近正好对这些产品做过总结,我来介绍一下阿里云主要的产品及功能: ECS (Elastic C...
游客bnlxddh3fwntw 2020-04-24 21:38:46 292 浏览量 回答数 2

回答

一、EOS 资源都包括哪些 EOS 的资源分为以下三种: RAM (内存) Network BandWidth (网络带宽) CPU BandWidth (CPU 带宽) 根据获取机制的不同, 将他们分为两大类, 一般我们将 Network BandWidth 和 CPU BandWidth 划分为一类, 统称为带宽类。RAM 则单独划分出来, 为什么这样分类呢? 下面我将详细进行讲解。 二、赎回带宽操作 Network BandWidth 简称 NET (网络带宽) 和 CPU BandWidth 简称 CPU (CPU 带宽) 是通过抵押 EOS 的方式获得的, 如果你想释放 NET 和 CPU 可以通过赎回操作赎回抵押的 EOS 代币, 但是需要等待 72 小时, 也就是三天后才能到账。 NET 和 CPU 用来保证用户使用 EOS 网络转账等基本功能, 例如你每次使用转账功能的时候, 都会消耗 NET 和 CPU 资源, 并且单位时间内转账的次数越多, 消耗的 NET 和 CPU 越多, 但是 NET 和 CPU 可以随着时间的推移, 自动释放。 值得注意的是, 目前在 EOS 系统中, 赎回 NET 和 CPU 的方法和赎回投票抵押的方法是一致的, 也就是说, 当你想赎回自己投票超级节点的抵押金的时候, 也是相当于赎回 NET 和 CPU. 三、特别的 RAM RAM 必须通过 EOS 购买的方式获得的, 而 RAM 的购买价格是随着市场价格上下浮动的, 关于 RAM 的价格, 可以通过 https://www.eosrp.io 查看。关于 RAM 的价格算法, 我会在下边的Bancor 算法中详细提到。 那么购买 RAM 有什么用处呢? 截止到我写这篇文章, 之前 EOS 全网一共有 64 GB 的 RAM 内存, 但是前一段时间, EOS RAM 扩容方案通过, 在当前的 64 GB 基础上每生产一个区块,RAM 增 1 KB . 在 EOS 系统中, 每个账户都需要 RAM 来存储数据, 比如你在 EOS 中创建账户、转账、购买资源、抵押、赎回、投票等操作的时候, 都有可能消耗 RAM, 换句话说如果你的 RAM 消耗殆尽, 那么有很多基本操作是无法实现的。 当然, 我们在购买 RAM 的时候, 还需要消耗当前购买所需 EOS 的 0.5% (千分之五) 的手续费, 同样卖 RAM 资源的时候, 也需要消耗 0.5% (千分之五) 的手续费, 这笔手续费被存在 eosio.ramfee 中, 由 BP 节点进行管理。 四、Bancor 算法 Bancor 算法最早诞生于 1940 年 - 1942 年, 由凯恩斯和舒马赫提出, 但是实际应用是在 Bancor Network 项目。它定义了两类 token: 一种是通常会流通使用的 connector token(即储备金,例如:BTC、ETH、EOS等),而另一种是作为"超平台"中间媒介的 Smart Token.为了使得兑换价格满足供需关系,设计的公式中的价格为 connector 的可流通余量(balance)除以按照一定系数的 Smart Token 供应量:attachments-2018-08-sLdaUe4e5b6519fd51916.jpg 其中,CW (Connector Weight) 表示设计出来的 Smart Token 的总价值与实际在使用中的 connector 余量间的关系,设计好后为一个固定参数:attachments-2018-08-1fyKxHxM5b651a08b5b7c.jpg 总体上来说,就是 Smart Token 的供应量越少或者 connector 的余量越多,那么使用 connector 来兑换 Smart Token 的价格就越高。 虽然很不严谨,但这也足以理解为什么 EOS 的 RAM 越少,价格越高了。[1] EOS 投票机制 EOS 采用 DPoS 共识机制 ,该机制通过社区投票选举 21 个超级节点来维护 EOS 网络,为 EOS 网络提供算力、带宽以及存储支持。 从 6 月份 EOS 主网上线后,用户在钱包内完成投票操作,投票给自己认可的超级节点。一个 EOS 可以抵押成一票,一票最多可以同时投 30 个候选节点,每个候选节点最多投 1 票,用户可以随时改变想法投给其他候选节点,可以随时申请赎回抵押的 EOS,申请赎回后 72 小时后到账。这点和 NET 和 CPU 赎回是一样的, 之前也有提到。 EOS 超级节点的投票是不断变化的, 因为一共有 21 个节点, 每个节点一次负责出 6 个块, 每个块 0.5 秒, 所以每过 63 秒, 就需要重新统计所有节点的得票数, 得票排在前 21 位的, 重新获得 BP 权利。 关于 BP 获得投票的来源详情, 可以科学上网后查看该网站: http://eos-bp-votes.dapptools.info/s/api/block-producer-votes-stack-html/1/80 最后 EOS 作为当前最热门的公链项目, 给予了部分区块链从业者很大的期望。Code is not law, 让 BM 将人治的思想灌入其中, 无论是信仰上的冲击, 亦或者技术上的革命, 作为普通用户的我们, 还是应该更加冷静的着眼于安全本身, 了解原理, 并带有自己的思考。同时我也希望 EOS 社区能对 EOS 投票机制加以改进, 让更多的 EOS 持有者参与到 EOS 投票中, 包括一些社区决策, 技术提案, 使 EOS 更加惠民。
问问小秘 2019-12-02 03:07:12 0 浏览量 回答数 0

回答

互联网时代,大家提倡敏捷迭代,总嫌传统方式太重,流程复杂,影响效率,什 么都希望短平快,在扁平化的组织中,经常是需求火速分发到一线研发,然后就靠个 人折腾去了,其实技术架构评审这同样是一个非常重要的环节。架构评审或技术方案 评审的价值在于集众人的力量大家一起来分析看看方案里是否有坑,方案上线后是否会遇到不可逾越的重大技术问题,提前尽可能把一些事情先考虑到提出质疑其实对项 目的健康发展有很大的好处。 基于架构评审,我们的目标核心是要满足以下几点: 1. 设计把关,确保方案合格,各方面都考虑到了,避免缺陷和遗漏,不求方案 多牛,至少不犯错。 2. 保证架构设计合理和基本一致,符合整体原则。 3. 维持对系统架构的全局认知,避免黑盒效应。 4. 通过评审发掘创新亮点,推广最佳实践。 5. 架构设计既要保证架构设计的合理性和可扩展性,又要避免过度设计。架构设计 不仅仅是考虑功能实现,还有很多非功能需求,以及持续运维所需要的工作,需要工 程实践经验,进行平衡和取舍。 架构评审需要以下几点: 1. 技术选型:为什么选用 A 组件不选用 B、C 组件,A 是开源的,开源协议是 啥?基于什么语言开发的,出了问题我们自身是否能够维护?性能方面有没 有压测过?这些所有问题作为技术选型我们都需要考虑清楚,才能做最终决定。 2. 高性能:产品对应的 TPS、QPS 和 RT 是多少?设计上会做到的 TPS、 QPS 和 RT 是多少?而实际上我们整体随着数据量的增大系统性能会不会出 现明显问题?随着业务量、数据量的上升,我们的系统的性能如何去进一步 提高?系统哪个环节会是最大的瓶颈?是否有抗突发性能压力的能力,大概 可以满足多少的 TPS 和 QPS,怎么去做来实现高性能,这些问题都需要我 们去思考。 3. 高可用:是否有单点的组件,非单点的组件如何做故障转移?是否考虑过多活 的方案?是否有数据丢失的可能性?数据丢失如何恢复?出现系统宕机情况, 对业务会造成哪些影响?有无其他补救方案?这些问题需要想清楚,有相应 的解决方案。 4. 可扩展性:A 和 B 的业务策略相差无几,后面会不会继续衍生出 C 的业务策 略,随着业务的发展哪些环节可以做扩展,如何做扩展?架构设计上需要考 虑到业务的可扩展性。 5. 可伸缩性:每个环节的服务是不是无状态的?是否都是可以快速横向扩展的? 扩容需要怎么做手动还是自动?扩展后是否可以提高响应速度?这所有的问 题都需要我们去思考清楚,并有对应的解决方案。 6. 弹性处理:消息重复消费、接口重复调用对应的服务是否保证幂等?是否考虑 了服务降级?哪些业务支持降级?支持自动降级还是手工降级?是否考虑了 服务的超时熔断、异常熔断、限流熔断?触发熔断后对客户的影响?服务是 否做了隔离,单一服务故障是否影响全局?这些问题统统需要我们想清楚对 应的解决方案,才会进一步保证架构设计的合理性。 7. 兼容性:上下游依赖是否梳理过,影响范围多大?怎么进行新老系统替换?新 老系统能否来回切换?数据存储是否兼容老的数据处理?如果对你的上下游 系统有影响,是否通知到上下游业务方?上下游依赖方进行升级的方案成本 如何最小化?这些问题需要有完美的解决方案,稍有不慎会导致故障。 8. 安全性:是否彻底避免 SQL 注入和 XSS ?是否有数据泄露的可能性?是否 做了风控策略?接口服务是否有防刷保护机制?数据、功能权限是否做了控制?小二后台系统是否做了日志审计?数据传输是否加密验签?应用代码中 是否有明文的 AK/SK、密码?这些安全细节问题需要我们统统考虑清楚,安 全问题任何时候都不能轻视。 9. 可测性:测试环境和线上的差异多大?是否可以在线上做压测?线上压测怎 么隔离测试数据?是否有测试白名单功能?是否支持部署多套隔离的测试环 境?测试黑盒白盒工作量的比例是怎么样的?新的方案是否非常方便测试, 在一定程度也需要考量。 10. 可运维性:系统是否有初始化或预热的环节?数据是否指数级别递增?业务 数据是否需要定期归档处理?随着时间的推移如果压力保持不变的话系统需 要怎么来巡检和维护?业务运维方面的设计也需要充分考虑到。 11. 监控与报警:对外部依赖的接口是否添加了监控与报警?应用层面系统内部 是否有暴露了一些指标作监控和报警?系统层面使用的中间件和存储是否有 监控报警?只有充分考虑到各个环节的监控、报警,任何问题会第一时间通 知到研发,阻止故障进一步扩散。 其实不同阶段的项目有不同的目标,我们不会在项目起步的时候做 99.99% 的 可用性支持百万 QPS 的架构,高效完成项目的业务目标也是架构考虑的因素之一。 而且随着项目的发展,随着公司中间件和容器的标准化,很多架构的工作被标准化替 代,业务代码需要考虑架构方面伸缩性运维性等等的需求越来越少,慢慢的这些工作 都能由架构和运维团队来接。一开始的时候我们可以花一点时间来考虑这些问题,但 是不是所有的问题都需要有最终的方案。
Lee_tianbai 2020-12-30 18:33:39 0 浏览量 回答数 0

回答

DevOps 这个概念最早是在 2007 年提出的,那时云计算基础设施的概念也才刚刚提出没多久,而随着互联网的逐渐普及,应用软件的需求爆发式增长,软件开发的理念也逐渐从瀑布模型(waterfall)转向敏捷开发(agile)。传统的软件交付模式(应用开发人员专注于软件开发、IT 运维人员负责将软件部署到服务器运行),再也无法满足互联网软件快速迭代的需求。于是,DevOps 作为一种打破研发和运维之间隔阂、加快软件交付流程、提高软件交付质量的文化理念和最佳实践 逐渐普及至今。 DevOps 的现状 DevOps 的流行得益于业界对于应用软件敏捷开发、高质量交付的诉求,所以为开发和运维开辟了一块“公共的空间”,让双方可以在这里紧密合作。那时软件研发依旧属于一个新兴行业,人们习惯于向成熟的制造业学习,制造业解决大规模生产的方式,就是构建流水线,通过流水线规范化每个步骤对接的内容,而流水线上的工人们则只需要各司其职,快速熟练的完成自己这部分生产内容。 所以,DevOps 借鉴了制造业的经验,开始构建持续集成 / 持续交付(CI/CD)的流水线,催生出了一系列自动化 / 半自动化工具(如 puppet、chef、ansible 等),结合编写脚本的可扩展能力,将研发和运维的大量操作规范化,从而达到彼此协作的目标。但是最终还是要有人投入到这些工具的构建中,于是就出现了 DevOps 团队。DevOps 团队构建的工具和平台,帮助研发更容易地接近生产环境,让研发在持续集成、持续交付的过程中可以一键部署、快速试错,从而很大程度提前暴露和避免了软件在实际运行过程中的问题。 从本质上讲,DevOps 是为运维服务的。 它把生产环境的运维流程通过自动化的工具提供出来了,屏蔽了基础设施细节,同时让软件本身的问题更容易暴露,从而把这些问题尽量提前交给研发去解决。这些,其实都是在帮助运维减轻负担。 这一套模式在一开始运转良好,但是问题也随着时间的推移慢慢暴露出来了。DevOps 本身不为企业带来直接的利润,也不增加产品的功能,它们是企业的成本中心,所以许多企业不愿意为 DevOps 投入太多的成本。久而久之,DevOps 的能力便无法与研发人员增长的需求所匹配,不愿意继续伴随着云和开源社区的发展向前演进,反而成为软件研发的瓶颈。试想一下,有多少大公司的技术人员,对自己公司里的“研发效能”工具表示满意呢? 云计算的普及 聪明的企业总能从自己的需求中发现业界共有的需求,AWS 便是这么诞生的,他们早在 2006 年便首次把软件部署需要的网络、计算、存储等基础设施当做服务提供给用户,允许任何人在不购买服务器等物理硬件的情况下构建互联网应用程序,规模化使得整体的成本比用户自建更低。而云计算 IaaS、PaaS、SaaS 的概念也正是在那一年开始逐渐清晰的。 云计算的初期,用户主要使用的是 IaaS 服务,如虚拟机、存储等,使用云计算服务的企业依旧需要运维来管理这一类基础设施,只是运维管理的对象从物理机切换到虚拟机而已,并没有太本质的区别。 而随着云计算的快速发展,云的能力不断补充、增强,渐渐将原先由运维提供的方方面面的能力都转换成为了云上的服务,这其中自然包含了管理软件完整生命周期的各类服务,从代码托管、持续集成、持续交付,到监控、报警、自动扩缩容等一系列的能力,均能在云上找到对应的服务。品类之多、数量之巨,令人瞠目结舌。 但是 DevOps 依然有着用武之地。云的对接难度实在太大了,涉及到的云服务又多,不同云厂商提供的服务还不统一,为了使用云上的产品不得不投入大量的时间学习,而为了防止云厂商的绑定又不得不做多厂商的适配,DevOps 依旧需要像过去一样为开发屏蔽实际环境的复杂性,只不过这次他们要负责管理的基础设施变成了云资源。 改变一切的 Kubernetes Kubernetes 的本质是现代应用基础设施,它关注如何将应用与“云”天然地集成在一起,将“云”的最大价值发挥出来。Kubernetes 强调让基础设施能更好的配合应用、以更高效的方式为应用“输送”基础设施能力,而不是反之。在这个过程中,Kubernetes 、Docker、Operator 等在云原生生态中起到了关键作用的开源项目,正在在把应用管理与交付推上一个跟以前完全不一样的境况:Kubernetes 的使用者只通过声明式的方式描述自己应用的终态是什么,然后一切就结束了。Kubernetes 会处理后面的所有事情。 这也是为什么 Kubernetes 非常强调声明式 API。通过这种方式,Kubernetes 本身接入的基础设施能力越强,Kubernetes 的使用者能够声明的终态就越丰富,他的职责也就约单纯。现在,我们不仅能够通过 Kubernetes 声明应用的运行终态,比如;“这个应用需要 10 个实例”,我们还能够声明应用的很多运维终态,比如:“这个应用使用金丝雀发布策略进行升级”,以及 “当它的 CPU 使用量大于 50% 时,请自动扩展 2 个实例出来”。 这就让传统的 DevOps 工具和团队受到了挑战:如果一个业务研发自己只需要通过声明式 API 声明他的应用的所有终态甚至包括完整的 SLA,后面的一切就都会有 Kubernetes 来自动的搞定,那么他还有什么理由去对接和学习各式各样的 DevOps 流水线呢? 换句话说,长久以来,DevOps 实际上是在充当研发与基础设施之间的那一层“胶水”。而现在,Kubernetes 通过它极具生命力的声明式 API 和无限接入的应用基础设施能力,正在完美的扮演这个“胶水层”的作用。这也提醒了我们,上一个正在被 Kubernetes 体系强烈挑战的“胶水层”,其实叫做“传统中间件”:它正遭受到 Service Mesh 的巨大冲击。 DevOps 会消失吗? 近几年,Kubernetes 项目经常被描述成 DevOps 的“最佳拍档”。类似的观点认为, Kubernetes 跟 Docker 一样,解决的是软件运行时的问题。这意味着 Kubernetes 更像一种“时髦”的 IaaS,只不过运行时从虚拟机变成了容器。所以,只要能够将现有 DevOps 思想和流程对接到 Kubernetes 上来,就可以享受到容器技术带来的轻量级与弹性。这对于提倡“敏捷”的 DevOps 来说,显然是最好的组合。 不过,至少目前看来,Kubernetes 的发展路径并不是一个类 IaaS 的角色。它虽然关注接入底层的基础设施能力,但它本身却又不是基础设施能力的提供方。而且,相比于软件运行时,Kubernetes 似乎更关心软件的生命周期和状态流转。不仅如此,它还提供了一种叫做“控制器模型”的机制来将软件的实际状态与期望状态不断逼近,这显然都已经超出了一个“软件运行时”的范畴。 Kubernetes 项目对应用本身的“额外关注”,让它与一个类 IaaS 基础设施有着明显的区别,也让它“胶水”的定位更加明显。而如果 Kubernetes 的能力足够强大,那么作为研发与基础设施之间现有的“胶水层”, DevOps 是否还有必要存在?在所谓的云原生时代,应用研发与交付是不是真的会走向“一次声明”就可以“撒手不管”,从而让 DevOps 彻底消失呢? 不过,至少目前看来,Kubernetes 项目距离这个愿景,还有不少困难需要克服。 “Platform for Platform” API 的局限性 Kubernetes 是一个典型的 “Platform for Platform”项目,所以它的 API,距离纯研发视角还是非常遥远的。就比如一个 Deployment 对象,就既包括了研发侧关心的镜像,也包括了基础设施侧的资源配置,甚至是容器安全配置。此外, Kubernetes API 并没有提供出对“运维能力”的描述与定义方式,这也使得声明之后的“撒手不管”变得遥不可及。这也是为什么目前 DevOps 依然被需要的原因:Kubernetes 的大多数字段,还是必须经过研发和运维共同协作的流程来进行填充。 无法对更多的云资源进行描述 K8s 的原生 API 只包含了云资源的很少一部分,比如用 PV/PVC 表达存储,用 Ingress 表达负载均衡,但这对于一个完全声明式的应用描述来说是完全不够的。比如,研发希望在 K8s 上找到一个概念来表达数据库、VPC、消息队列等需求的时候,就会感到非常困惑。而现有的所有方案则完全依赖于云厂商的实现从而带来了新的 vendor lock-in 困惑。 Operator 体系缺乏互操作性 Kubernetes 的 Operator 机制是这个项目的能力能够无限增长的公开秘密。但令人遗憾的是,目前所有 Operator 之间的关系,就像是一个又一个的烟囱,互相之间没有任何交互与协作的可能。比如,我们把云上的 RDS 通过 CRD 和 Operator 扩展到了 K8s 声明式 API 的体系中,但是当第三方希望写一个定时备份 RDS 持久化文件的 CRD Operator 去配合的时候,却往往无从下手。这就又需要 DevOps 的体系介入来解决问题。 未来? 显然,现在的 Kubernetes 项目,依然需要借助 DevOps 体系来真正完成软件的高效迭代与交付工作。这是不可避免的:尽管 Kubernetes 声称自己是“以应用为中心”的基础设施,但它作为一个从 Google Borg 衍生出来的系统级项目,其本身的设计和工作层次还是更多的基础设施领域徘徊。但另一方面,我们绝不可否认的是,Kubernetes 在它的关键路径上,始终保持着对研发侧 “NoOps” 的追求。这种渴望,从它第一天提出“声明式应用管理”理论的时候就已经“昭然若揭”,而 CRD 和 Operator 体系的建立,更让这种应用级别的关心终于有了落地的机会。我们已经看到很多 DevOps 流程正在“下沉”为 Kubernetes 里的声明式对象与控制循环,比如 Tekton CD 项目。 如果 Kubernetes 的未来是 100% 的声明式应用管理,那么我们有理由相信 DevOps 最终会从技术领域消失然后彻底蜕变成一种文化。毕竟,那个时候的运维工程师,可能都会成为 Kubernetes Controller/Operator 的编写者或者设计者。而研发呢?他们可能根本不会知道原来 Kubernetes 这个东西曾经如此显赫的存在过。
有只黑白猫 2020-01-07 11:35:38 0 浏览量 回答数 0

问题

电商云客户案例分享与分析——(3)

上海丽人丽妆化妆品有限公司中国线上最大的化妆品经销商,通过为知名品牌在天猫开设品牌官方旗舰店,给消费者提供化妆品网购服务。目前丽人丽妆运营着兰蔻、雅漾、碧欧泉、兰芝、美宝莲、施华蔻等近40个品牌的天猫官方旗舰店。...
琴明 2019-12-01 21:14:59 6002 浏览量 回答数 0

回答

定位(Positioning),由美国著名营销专家艾·里斯(AlRies)与杰克·特劳特(Jack Trout)于70年代早期提出。   2001年,定位被美国营销学会评为有史以来对美国营销业影响最大的观念。   2007年,美国权威媒体评选“全球十大顶尖商业战略大师”,艾·里斯与彼得·德鲁克、杰克·韦尔奇等并列其中。   2009年,美国《财富》杂志(Fortune,2009年2月刊)推出“历史上百本最佳商业经典著作”前十位介绍,由艾·里斯与杰克·特劳特合著的《定位》名列首位。   当时,他们在美国《广告时代》发表了名为《定位时代》系列文章。只后,他们将这些观点和理论集中反映在他们合作的第一本著作《广告攻心战略》一书中。正如他们所言,这是一本关于传播沟通的教科书。   1996年,杰克·特劳特整理了25年来的工作经验,写出了《新定位》一书。也许是更加符合了时代的要求,但其核心思想却仍然源自于他们于1972年提出的定位论。定位理论的产生,源于人类各种信息传播渠道的拥挤和阻塞,可以归结为信息爆炸时代对商业运作的影响结果。科技进步和经济社会的发展,几乎把消费者推到了无所适从的境地。首先是媒体的爆炸:广播、电视、互联网,录音带、录像带、光盘使消费者目不暇接。其次是产品的爆炸:仅电视就有大屏幕的、小屏幕的,平面直角的、超平的、纯平的,从耐用消费品到日用品,都给人以眼花缭乱的感觉。再就是广告的爆炸:电视广告、广播广告、报刊广告、街头广告、楼门广告、电梯广告,真可谓无孔不入。因此,定位就显得非常必要。   定位是对产品在未来的潜在顾客的脑海里确定一个合理的位置。定位的基本原则不是去创造某种新奇的或与众不同的东西,而是去操纵人们心中原本的想法,去打开联想之结。定位的真谛就是“攻心为上”,消费者的心灵才是营销的终级战场。消费者有五大思考模式:消费者只能接收有限的信息、消费者喜欢简单,讨厌复杂、消费者缺乏安全感、消费者对品牌的印象不会轻易改变、消费者的想法容易失去焦点。掌握这些特点有利于以帮助企业占领消费者心目中的位置。而定位的方法有多种,如强化自己已有的定位、比附定位、单一位置策略、寻找空隙策略、类别品牌定位、再定位等。   按照艾·里斯与杰克·特劳特的观点:定位,是从产品开始,可以是一件商品,一项服务,一家公司,一个机构,甚至于是一个人,也可能是你自己。定位并不是要你对产品做什么事情,定位是你对产品在未来的潜在顾客的脑海里确定一个合理的位置,也就是把产品定位在你未来潜在顾客的心目中。定位可以看成是对现有产品的一种创造性试验。“改变的是名称、价格及包装,实际上对产品则完全没有改变,所有的改变,基本上是在作着修饰而已,其目的是在潜在顾客心中得到有利的地位”。   所谓定位,就是令你的企业和产品与众不同,形成核心竞争力;对受众而言,即鲜明地建立品牌。   ——杰克·特劳特   所谓定位,就是让品牌在消费者的心智中占据最有利的位置,使品牌成为某个类别或某种特性的代表品牌。这样当消费者产生相关需求时,便会将定位品牌作为首选,也就是说这个品牌占据了这个定位。   —— 特劳特(中国)品牌战略咨询有限公司总裁 邓德隆 编辑本段定位的前提   按照艾·里斯与杰克·特劳特的理论,我们目前已成为一个传播过多的社会,而消费者只能接受有限的信息,消费者抵御这种“信息爆炸”的最有力武器就是最小努力法则--痛恨复杂,喜欢简单。现有产品在顾客心目中都有一定的位置,例如,人们认为可口可乐是世界上最大饮料生产商,格兰仕是中国最大的微波炉生产商,北京同仁医院是中国最著名的眼科医院等,这些产品和服务的提供者在与消费者长期的交易中所拥有的地位,是其他人很难取代的。也就是说,消费者对品牌的印象不会轻易改变。定位的基本原则不是去创造某种新奇的或与众不同的东西,而是去操纵人们心中原本的想法,去打开联想之结,目的是要在顾客心目中,占据有利的地位。唯其如此,方能在市场上赢得有利的竞争地位。   一般说来,企业在营销中的失策表现为两大类:   一是在市场逐渐成熟后,如果企业不能及时构思新的定位,从而使其陷入困境。例如,在冰箱、电视机等已成为国内的成熟技术之时,再有一个厂家去宣传自己是第一个引进外国技术,就会让人笑掉大牙。而海尔、长虹等企业诉求“海尔,中国造”、“长虹,以振兴民族工业为已任”,则收到了极好的效果。   二是随着企业不断扩张和进行多元化角逐,而使消费者对产品的印象愈来愈模糊。美国雪佛莱汽车公司就经历过这样的事情。过去,雪佛莱汽车是美国家庭汽车的代名词,但在雪佛莱将生产线扩大到涵盖卡车、跑车等车型后,消费者心中原有的“雪佛莱就是美国家庭房车”的印象焦点反而模糊了,而让福特站上了第一品牌的宝座。在我国,“三九胃泰”曾是著名的胃药生产商,而后,又扩张到啤酒的生产,这无疑是为厂家出了个大难题:饮酒对胃肠道是一个不良刺激,自己生产的产品又是治疗胃病,是酒好还是胃药好。这不正是“矛盾”这一古代寓言的现代翻版吗。然而,这也正是“定位”理论的用武之地。   定位的真谛就是“攻心为上”,消费者的心灵才是营销的终级战场。从广告传播的角度来看定位,它不是要琢磨产品,因为产品已是生出来的孩子,已经定型,不大容易改变,而容易改变的是消费者的“心”。 编辑本段消费者五大思考模式   要抓住消费者的心,必须了解他们的思考模式,这是进行定位的前提。《新定位》一书列出了消费者的五大思考模式,以帮助企业占领消费者心目中的位置。 模式一:消费者只能接收有限的信息。   在超载的信息中,消费者会按照个人的经验、喜好、兴趣甚至情绪,选择接受哪些信息,记忆哪些信息。因此,较能引起兴趣的产品种类和品牌,就拥有打入消费者记忆的先天优势。例如,我国的杭州娃哈哈集团,最初是以生产“娃哈哈”儿童营养液而一举成名。它的成功就是由于,产品定位准确,而广告定位更是让人过目不忘,因为它源于一首人人熟知的儿歌,很容易引进儿童与家长的共鸣。 模式二:消费者喜欢简单,讨厌复杂。   在各种媒体广告的狂轰滥炸下,消费者最需要简单明了的信息。广告传播信息简化的诀窍,就是不要长篇大论,而是集中力量将一个重点清楚地打入消费者心中,突破人们痛恨复杂的心理屏障。在这一点上最令人称道是我国的一种驱虫药广告,只须服两片,治蛲虫是两片,治钩虫也是两片。人们也许记不住复杂的药品名称,但只需说“两片”,药店的售货员就知道你要的是什么药。反过来,如果厂家在广告中介绍它的产品如何如何先进,效果如何显著,其结果可想而知。 模式三:消费者缺乏安全感。   由于缺乏安全感,消费者会买跟别人一样的东西,免除花冤枉钱或被朋友批评的危险。所以,人们在购买商品前(尤其是耐用消费品),都要经过缜密的商品调查。而广告定位传达给消费者简单而又易引进兴趣的信息,正好使自己的品牌易于在消费者中传播。如果一位消费者要买驱虫药,必然先向朋友打听,一说“两片”,既满足了消费者安全感的需要,也无须记一些专业名词。   模式四: 消费者对品牌的印象不会轻易改变 。 虽然一般认为新品牌有新鲜感,较能引人注目,但是消费者真能记到脑子里的信息,还是耳熟能详的东西。比如,对可口可乐公司的员工而言,它是总部设在亚特兰大市的一个“公司”,一个“机构”,而在一般消费者心目中,可口可乐是一种甜美的、深色的、加了碳酸气的饮料,可口可乐是一个著名饮料品牌。如果,可口可乐公司哪天心血来潮,去生产热门的香烟或者是啤酒,也许正是可口可乐的可叹可悲之时。 模式五:消费者的想法容易失去焦点。   虽然盛行一时的多元化、扩张生产线增加了品牌多元性,但是却使消费者模糊了原有的品牌印象。美国舒洁公司在纸业的定位就是一例。舒洁原本是以生产舒洁卫生纸起家的,后来,它把自己的品牌拓展到舒洁纸面巾、舒洁纸餐巾以及其他纸产品,以至于在数十亿美元的市场中,拥有了最大的市场占有率。然而,正是这些盲目延伸的品牌,使消费者失去了对其注意的焦点,最终让宝洁公司乘虚而入。难怪一位营销专家以美国人幽默方式发问:舒洁餐巾纸,舒洁卫生纸,到底哪个牌子是为鼻子而设计的呢。   所以,企业在定位中一定要掌握好这些原则:消费者接受信息的容量是有限的,广告宣传“简单”就是美,一旦形成的定位很难在短时间内消除,盲目的品牌延伸会摧毁自己在消费者心目中的既有定位。所以,无论是产品定位,还是广告定位一定要慎之又慎。 编辑本段定位方法   在广告泛滥、信息爆炸,消费者必然要用尽心力筛选掉大部分垃圾。例如,尽管市场上饮料众多,人们只知道有可口可乐、娃哈哈、乐百氏等几种品牌,并且这些品牌在他们心目中还是有一定顺序的,不用说,可口可乐一定是第一,至于第二、第三就要看厂家的定位策略了。   人们总是容易记住第一名,如谁都知道世界第一高峰是珠穆拉玛峰,但极少有人能说出第二大高峰,人们能很快说出体育比赛的冠军,亚军则不易给人留下印象。所以,在具体操作中营销人员要善于找出自己品牌所拥有的令人信服的某种重要属性或利益。通过一定的策略和方法,让自己的品牌给人们留下深刻的印象。这些方法一般有: 强化自己已有的定位   既然现有的产品和服务在消费者心目中都有一定的位置,如果这种定位对企业有利的话,就要反复向人们宣传这种定位,强化本企业的产品在消费者心目的形象,也就是自己的特色,而这种强化必须是实事求是的。如,在我国的冰箱生产厂家中,海尔反复强调自己的“高品质”,新飞则宣传自己是节能冰箱,而美菱把文章做在了“保鲜”上。 比附定位   使定位对象与竞争对象(已占有牢固位置)发生关联,并确立与竞争对象的定位相反的或可比的定位概念。如美国一家处于第二位的出租汽车公司,在广告中反复宣传:我们是第二,所以我们更加努力啊。这样,既强化了自己与第一的关系,又表明了自己处于弱者的位置,更易引起人们“同情弱者”的共鸣。 第一定位   处于领导地位者,要以另外的新品牌来压制竞争者。因为每一个品牌都在其潜在顾客心目中安置了独自所占据的一个特定处所。这是作为市场领导者所要采取的策略。既然自己是老大,“卧榻之侧,岂容他人酣睡”,因此,在各种场合宣传自己第一的形象自然就在情理之中。 市场空白   寻求消费者心目中的空隙,然后加以填补。其中有价格(高低),性别,年龄,一天中的时段,分销渠道,大量使用者的位置等各种空隙。如,万宝路在美国是著名的香烟品牌,而一个叫窈窕牌的香烟品牌,就是以女性抽烟者为突破口挑战万宝路而大获成功。 品类   当一个强大的品牌名称成了产品类别名称的代表或代替物时,必须给公司一个真正成功的新产品以一个新的名称,而不能采用“搭便车”的做法,沿袭公司原有产品的名称。这像“跷跷板”原理,当一种上来时,另一种就下去。因为一个名称不能代表两个迥然不同的产品。宝洁公司的多品牌策略就大有可取之处。 再定位   也就是重新定位,意即打破事物(例如产品)在消费者心目中所保持的原有位置与结构,使事物按照新的观念在消费者心目中重新排位,调理关系,以创造一个有利于自己的新的秩序。这意味着必须先把旧的观念或产品搬出消费者的记忆,才能把另一个新的定位装进去。海尔在最初是以宣传自己冰箱的品质优良作为定位,而在产品延伸之后,很快就突出了“中国造”、“向国际营销商授权”等新的定位。   需要指出的是,由于艾·里斯与杰克·特劳特都是广告人出身,他们的定位理论往往局限于一种广告传播策略,强调让产品占领消费者心目中的空隙。目前,定位理论对营销的影响远远超过了原先把它作为一种传播技巧的范畴,而演变为营销策略的一个基本步骤。这反映在营销大师科特勒对定位下的定义中。他认为,定位是对公司的提供物(原文是offer)和形象的策划行为,目的是使它在目标消费者的心目中占据一个独特的有价值的位置。因此,“营销人员必须从零开始,使产品特色确实符合所选择的目标市场。”科特勒把艾尔·列斯与杰克·特罗的定位理论归结为“对产品的心理定位和再定位”。显然,除此之外,还有对潜在产品的定位。这就给定位理论留下了更为广阔的发展空间。 编辑本段定位理论在中国的发展   定位的一个中心、两个基本点   定位理论传入中国后,定位理论和中国实践相结合,取得中部定位第一人、著名品牌定位专家鲁建华首次提出:定位理论的核心是一个中心、两个基本点,以打造品牌为中心,以竞争导向和进入顾客心智为基本点。 以打造品牌为中心    从根本的角度思考,营销的过程就是创造顾客、打造品牌的过程,营销就是打造品牌;从更广义的角度讲,创建伟大企业的过程其实就是创造顾客、打造品牌的过程,做企业就是做品牌,企业运营的本质就是打造品牌。   定位理论所有的概念、观点、体系都服务于打造品牌这个目的,是围绕打造品牌而展开的。离开打造品牌这个中心,谈论定位理论,必然会误入歧途,不得要领。 以竞争导向为基本点   顾客重要还是竞争重要。传统的营销理论认为,顾客更重要,没有顾客就不会有竞争,营销就是满足顾客的需要和需求。“顾客是上帝”观念至高无上,广为流传。至今顾客导向的观念仍然深入人心。   从纯理论的角度讲,顾客确实比竞争重要;但从实战的角度看,解决竞争才是最重要的。从满足、服务顾客的角度看营销,营销必然走向趋同,没有差异,最终只有沦落到打价格战的深渊;而从竞争角度看营销,营销就会有活力,营销必然走向创造顾客、创造需求的新境界,不断引领企业开创新的未来。   竞争导向要求营销者首先考虑的问题是如何让自己的品牌与竞争品牌区分开来,实现差异化,把生意从竞争对手那里转换过来。这是定位思考的起点。   营销就是战争,商场就是战场。定位就是在与竞争对手正式开战之前进入和占据一个最有利的位置。定位是建立在竞争之上,随着竞争的发展而发展的。   竞争导向的观念是定位理论的第一个基本点。 以进入顾客心智为基本点   营销中没有事实,只有认知。   这是商业中最隐秘、最基本的真理,三个方面的原因导致了这一点:   一是从事实到认知有一个过程,你不能跨越这个过程。这个过程就是事实要经过大脑的过滤、解读,最终体现事实的认知。   二是人们已经形成既有的认知和观念,他们认为自己的这些既有认知、观念就是事实。而这些既有的认知、观念会影响人们对新事物的认知。这表现在两个方面:其一,心智中既有的认知、观念会让人们有选择地接收信息,你“看到”、“听到”、“尝到”的事物往往是你“希望看到”、“希望听到”、“希望尝到”的事物;其二,心智中既有的认知、观念有时会误导你,比如在一个装满自来水的瓶子上贴上某纯净水品牌的商标,你对这个品牌既有的认知(纯净水)会影响到你对事实(自来水)的判断。   三是顾客的认知逻辑与企业的认知逻辑往往相反。虽然他们都认为质量更好的产品一定会胜出,企业判断质量的标准是产品的技术指标、最好的检测仪器(他们很自然地认为自己的产品质量更好),而顾客判断质量的标准是哪一种产品得到更多顾客青睐哪一种产品的质量就更好,顾客没有能力也没有精力去理会那些所谓的技术指标。这就是心智认知规律所揭示的事实。   其实所有的广告都是要影响你的认知,如果没有影响你,广告就是失败的;影响了你,那它就是成功的。离开认知,就没有办法谈营销。   营销之战不是事实之战,不是产品之战,不是市场之战,而是认知之战。商战的地点不是事实,不是产品,不是市场,而是心智。   商战的目的其实就是设法进入心智认知并占据一席之地。定位就是选择、占据心智认知上最有利的位置,通过商战实现这一目的。商战在顾客的心智中进行,心智是你获胜的地方,也是你落败的地方,心智决定成败。商战中没有事实,只有认知,认知即事实,认知决定成败。   坚持占据顾客心智是定位理论的第二个基本点。 辩证关系   心智是竞争的内容,竞争是进入心智的手段。竞争在心智中展开,心智是竞争的战场。心智为竞争开辟了全新的内容、提供了一个差异化的竞争角度,竞争是进入、占据心智的必由之路。心智认知规律决定竞争规律,竞争发现和提升了心智认知的价值和作用。竞争导向与占据心智这两个基本点有机结合,相互运动,共同服务于打造品牌。这就是定位理论的核心─一个中心、两个基本点的辩证关系。
青衫无名 2019-12-02 01:17:12 0 浏览量 回答数 0

问题

【archsummit 回顾】阿里云章文嵩:构建大型云计算平台分布式技术的实践

演讲人:章文嵩博士,阿里集团的高级研究员与副总裁,主要负责基础核心软件研发和云计算产品研发、推进网络软硬件方面的性能优化、搭建下一代高可扩展低碳低成本电子商务基础设施。他也是开放源码及 Linux内...
云课堂 2019-12-01 21:03:36 14448 浏览量 回答数 9

回答

转自:阿飞的博客 一、数据库技术选型的思考维度 我们做选型的时候首先要问: 谁选型?是负责采购的同学、 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

回答

微服务 (MicroServices) 架构是当前互联网业界的一个技术热点,圈里有不少同行朋友当前有计划在各自公司开展微服务化体系建设,他们都有相同的疑问:一个微服务架构有哪些技术关注点 (technical concerns)?需要哪些基础框架或组件来支持微服务架构?这些框架或组件该如何选型?笔者之前在两家大型互联网公司参与和主导过大型服务化体系和框架建设,同时在这块也投入了很多时间去学习和研究,有一些经验和学习心得,可以和大家一起分享。 服务注册、发现、负载均衡和健康检查和单块 (Monolithic) 架构不同,微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构,服务之间通过轻量机制进行通信,这时候必然引入一个服务注册发现问题,也就是说服务提供方要注册通告服务地址,服务的调用方要能发现目标服务,同时服务提供方一般以集群方式提供服务,也就引入了负载均衡和健康检查问题。根据负载均衡 LB 所在位置的不同,目前主要的服务注册、发现和负载均衡方案有三种: 第一种是集中式 LB 方案,如下图 Fig 1,在服务消费者和服务提供者之间有一个独立的 LB,LB 通常是专门的硬件设备如 F5,或者基于软件如 LVS,HAproxy 等实现。LB 上有所有服务的地址映射表,通常由运维配置注册,当服务消费方调用某个目标服务时,它向 LB 发起请求,由 LB 以某种策略(比如 Round-Robin)做负载均衡后将请求转发到目标服务。LB 一般具备健康检查能力,能自动摘除不健康的服务实例。服务消费方如何发现 LB 呢?通常的做法是通过 DNS,运维人员为服务配置一个 DNS 域名,这个域名指向 LB。 Fig 1, 集中式 LB 方案 集中式 LB 方案实现简单,在 LB 上也容易做集中式的访问控制,这一方案目前还是业界主流。集中式 LB 的主要问题是单点问题,所有服务调用流量都经过 LB,当服务数量和调用量大的时候,LB 容易成为瓶颈,且一旦 LB 发生故障对整个系统的影响是灾难性的。另外,LB 在服务消费方和服务提供方之间增加了一跳 (hop),有一定性能开销。 第二种是进程内 LB 方案,针对集中式 LB 的不足,进程内 LB 方案将 LB 的功能以库的形式集成到服务消费方进程里头,该方案也被称为软负载 (Soft Load Balancing) 或者客户端负载方案,下图 Fig 2 展示了这种方案的工作原理。这一方案需要一个服务注册表 (Service Registry) 配合支持服务自注册和自发现,服务提供方启动时,首先将服务地址注册到服务注册表(同时定期报心跳到服务注册表以表明服务的存活状态,相当于健康检查),服务消费方要访问某个服务时,它通过内置的 LB 组件向服务注册表查询(同时缓存并定期刷新)目标服务地址列表,然后以某种负载均衡策略选择一个目标服务地址,最后向目标服务发起请求。这一方案对服务注册表的可用性 (Availability) 要求很高,一般采用能满足高可用分布式一致的组件(例如 Zookeeper, Consul, Etcd 等)来实现。 Fig 2, 进程内 LB 方案 进程内 LB 方案是一种分布式方案,LB 和服务发现能力被分散到每一个服务消费者的进程内部,同时服务消费方和服务提供方之间是直接调用,没有额外开销,性能比较好。但是,该方案以客户库 (Client Library) 的方式集成到服务调用方进程里头,如果企业内有多种不同的语言栈,就要配合开发多种不同的客户端,有一定的研发和维护成本。另外,一旦客户端跟随服务调用方发布到生产环境中,后续如果要对客户库进行升级,势必要求服务调用方修改代码并重新发布,所以该方案的升级推广有不小的阻力。 进程内 LB 的案例是 Netflix 的开源服务框架,对应的组件分别是:Eureka 服务注册表,Karyon 服务端框架支持服务自注册和健康检查,Ribbon 客户端框架支持服务自发现和软路由。另外,阿里开源的服务框架 Dubbo 也是采用类似机制。 第三种是主机独立 LB 进程方案,该方案是针对第二种方案的不足而提出的一种折中方案,原理和第二种方案基本类似,不同之处是,他将 LB 和服务发现功能从进程内移出来,变成主机上的一个独立进程,主机上的一个或者多个服务要访问目标服务时,他们都通过同一主机上的独立 LB 进程做服务发现和负载均衡,见下图 Fig 3。 Fig 3 主机独立 LB 进程方案 该方案也是一种分布式方案,没有单点问题,一个 LB 进程挂了只影响该主机上的服务调用方,服务调用方和 LB 之间是进程内调用,性能好,同时,该方案还简化了服务调用方,不需要为不同语言开发客户库,LB 的升级不需要服务调用方改代码。该方案的不足是部署较复杂,环节多,出错调试排查问题不方便。 该方案的典型案例是 Airbnb 的 SmartStack 服务发现框架,对应组件分别是:Zookeeper 作为服务注册表,Nerve 独立进程负责服务注册和健康检查,Synapse/HAproxy 独立进程负责服务发现和负载均衡。Google 最新推出的基于容器的 PaaS 平台 Kubernetes,其内部服务发现采用类似的机制。 服务前端路由微服务除了内部相互之间调用和通信之外,最终要以某种方式暴露出去,才能让外界系统(例如客户的浏览器、移动设备等等)访问到,这就涉及服务的前端路由,对应的组件是服务网关 (Service Gateway),见图 Fig 4,网关是连接企业内部和外部系统的一道门,有如下关键作用: 服务反向路由,网关要负责将外部请求反向路由到内部具体的微服务,这样虽然企业内部是复杂的分布式微服务结构,但是外部系统从网关上看到的就像是一个统一的完整服务,网关屏蔽了后台服务的复杂性,同时也屏蔽了后台服务的升级和变化。安全认证和防爬虫,所有外部请求必须经过网关,网关可以集中对访问进行安全控制,比如用户认证和授权,同时还可以分析访问模式实现防爬虫功能,网关是连接企业内外系统的安全之门。限流和容错,在流量高峰期,网关可以限制流量,保护后台系统不被大流量冲垮,在内部系统出现故障时,网关可以集中做容错,保持外部良好的用户体验。监控,网关可以集中监控访问量,调用延迟,错误计数和访问模式,为后端的性能优化或者扩容提供数据支持。日志,网关可以收集所有的访问日志,进入后台系统做进一步分析。 Fig 4, 服务网关 除以上基本能力外,网关还可以实现线上引流,线上压测,线上调试 (Surgical debugging),金丝雀测试 (Canary Testing),数据中心双活 (Active-Active HA) 等高级功能。 网关通常工作在 7 层,有一定的计算逻辑,一般以集群方式部署,前置 LB 进行负载均衡。 开源的网关组件有 Netflix 的 Zuul,特点是动态可热部署的过滤器 (filter) 机制,其它如 HAproxy,Nginx 等都可以扩展作为网关使用。 在介绍过服务注册表和网关等组件之后,我们可以通过一个简化的微服务架构图 (Fig 5) 来更加直观地展示整个微服务体系内的服务注册发现和路由机制,该图假定采用进程内 LB 服务发现和负载均衡机制。在下图 Fig 5 的微服务架构中,服务简化为两层,后端通用服务(也称中间层服务 Middle Tier Service)和前端服务(也称边缘服务 Edge Service,前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备,如 PC,Pad 或者 Phone)。后端服务启动时会将地址信息注册到服务注册表,前端服务通过查询服务注册表就可以发现然后调用后端服务;前端服务启动时也会将地址信息注册到服务注册表,这样网关通过查询服务注册表就可以将请求路由到目标前端服务,这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串联起来了。如果以面向对象设计模式的视角来看,网关类似 Proxy 代理或者 Façade 门面模式,而服务注册表和服务自注册自发现类似 IoC 依赖注入模式,微服务可以理解为基于网关代理和注册表 IoC 构建的分布式系统。 Fig 5, 简化的微服务架构图 服务容错当企业微服务化以后,服务之间会有错综复杂的依赖关系,例如,一个前端请求一般会依赖于多个后端服务,技术上称为 1 -> N 扇出 (见图 Fig 6)。在实际生产环境中,服务往往不是百分百可靠,服务可能会出错或者产生延迟,如果一个应用不能对其依赖的故障进行容错和隔离,那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中,某个单一后端一旦发生延迟,可能在数秒内导致所有应用资源 (线程,队列等) 被耗尽,造成所谓的雪崩效应 (Cascading Failure,见图 Fig 7),严重时可致整个网站瘫痪。 Fig 6, 服务依赖 Fig 7, 高峰期单个服务延迟致雪崩效应 经过多年的探索和实践,业界在分布式服务容错一块探索出了一套有效的容错模式和最佳实践,主要包括: Fig 8, 弹性电路保护状态图 电路熔断器模式 (Circuit Breaker Patten), 该模式的原理类似于家里的电路熔断器,如果家里的电路发生短路,熔断器能够主动熔断电路,以避免灾难性损失。在分布式系统中应用电路熔断器模式后,当目标服务慢或者大量超时,调用方能够主动熔断,以防止服务被进一步拖垮;如果情况又好转了,电路又能自动恢复,这就是所谓的弹性容错,系统有自恢复能力。下图 Fig 8 是一个典型的具备弹性恢复能力的电路保护器状态图,正常状态下,电路处于关闭状态 (Closed),如果调用持续出错或者超时,电路被打开进入熔断状态 (Open),后续一段时间内的所有调用都会被拒绝 (Fail Fast),一段时间以后,保护器会尝试进入半熔断状态 (Half-Open),允许少量请求进来尝试,如果调用仍然失败,则回到熔断状态,如果调用成功,则回到电路闭合状态。舱壁隔离模式 (Bulkhead Isolation Pattern),顾名思义,该模式像舱壁一样对资源或失败单元进行隔离,如果一个船舱破了进水,只损失一个船舱,其它船舱可以不受影响 。线程隔离 (Thread Isolation) 就是舱壁隔离模式的一个例子,假定一个应用程序 A 调用了 Svc1/Svc2/Svc3 三个服务,且部署 A 的容器一共有 120 个工作线程,采用线程隔离机制,可以给对 Svc1/Svc2/Svc3 的调用各分配 40 个线程,当 Svc2 慢了,给 Svc2 分配的 40 个线程因慢而阻塞并最终耗尽,线程隔离可以保证给 Svc1/Svc3 分配的 80 个线程可以不受影响,如果没有这种隔离机制,当 Svc2 慢的时候,120 个工作线程会很快全部被对 Svc2 的调用吃光,整个应用程序会全部慢下来。限流 (Rate Limiting/Load Shedder),服务总有容量限制,没有限流机制的服务很容易在突发流量 (秒杀,双十一) 时被冲垮。限流通常指对服务限定并发访问量,比如单位时间只允许 100 个并发调用,对超过这个限制的请求要拒绝并回退。回退 (fallback),在熔断或者限流发生的时候,应用程序的后续处理逻辑是什么?回退是系统的弹性恢复能力,常见的处理策略有,直接抛出异常,也称快速失败 (Fail Fast),也可以返回空值或缺省值,还可以返回备份数据,如果主服务熔断了,可以从备份服务获取数据。Netflix 将上述容错模式和最佳实践集成到一个称为 Hystrix 的开源组件中,凡是需要容错的依赖点 (服务,缓存,数据库访问等),开发人员只需要将调用封装在 Hystrix Command 里头,则相关调用就自动置于 Hystrix 的弹性容错保护之下。Hystrix 组件已经在 Netflix 经过多年运维验证,是 Netflix 微服务平台稳定性和弹性的基石,正逐渐被社区接受为标准容错组件。 服务框架微服务化以后,为了让业务开发人员专注于业务逻辑实现,避免冗余和重复劳动,规范研发提升效率,必然要将一些公共关注点推到框架层面。服务框架 (Fig 9) 主要封装公共关注点逻辑,包括: Fig 9, 服务框架 服务注册、发现、负载均衡和健康检查,假定采用进程内 LB 方案,那么服务自注册一般统一做在服务器端框架中,健康检查逻辑由具体业务服务定制,框架层提供调用健康检查逻辑的机制,服务发现和负载均衡则集成在服务客户端框架中。监控日志,框架一方面要记录重要的框架层日志、metrics 和调用链数据,还要将日志、metrics 等接口暴露出来,让业务层能根据需要记录业务日志数据。在运行环境中,所有日志数据一般集中落地到企业后台日志系统,做进一步分析和处理。REST/RPC 和序列化,框架层要支持将业务逻辑以 HTTP/REST 或者 RPC 方式暴露出来,HTTP/REST 是当前主流 API 暴露方式,在性能要求高的场合则可采用 Binary/RPC 方式。针对当前多样化的设备类型 (浏览器、普通 PC、无线设备等),框架层要支持可定制的序列化机制,例如,对浏览器,框架支持输出 Ajax 友好的 JSON 消息格式,而对无线设备上的 Native App,框架支持输出性能高的 Binary 消息格式。配置,除了支持普通配置文件方式的配置,框架层还可集成动态运行时配置,能够在运行时针对不同环境动态调整服务的参数和配置。限流和容错,框架集成限流容错组件,能够在运行时自动限流和容错,保护服务,如果进一步和动态配置相结合,还可以实现动态限流和熔断。管理接口,框架集成管理接口,一方面可以在线查看框架和服务内部状态,同时还可以动态调整内部状态,对调试、监控和管理能提供快速反馈。Spring Boot 微框架的 Actuator 模块就是一个强大的管理接口。统一错误处理,对于框架层和服务的内部异常,如果框架层能够统一处理并记录日志,对服务监控和快速问题定位有很大帮助。安全,安全和访问控制逻辑可以在框架层统一进行封装,可做成插件形式,具体业务服务根据需要加载相关安全插件。文档自动生成,文档的书写和同步一直是一个痛点,框架层如果能支持文档的自动生成和同步,会给使用 API 的开发和测试人员带来极大便利。Swagger 是一种流行 Restful API 的文档方案。当前业界比较成熟的微服务框架有 Netflix 的 Karyon/Ribbon,Spring 的 Spring Boot/Cloud,阿里的 Dubbo 等。 运行期配置管理服务一般有很多依赖配置,例如访问数据库有连接字符串配置,连接池大小和连接超时配置,这些配置在不同环境 (开发 / 测试 / 生产) 一般不同,比如生产环境需要配连接池,而开发测试环境可能不配,另外有些参数配置在运行期可能还要动态调整,例如,运行时根据流量状况动态调整限流和熔断阀值。目前比较常见的做法是搭建一个运行时配置中心支持微服务的动态配置,简化架构如下图 (Fig 10): Fig 10, 服务配置中心 动态配置存放在集中的配置服务器上,用户通过管理界面配置和调整服务配置,具体服务通过定期拉 (Scheduled Pull) 的方式或者服务器推 (Server-side Push) 的方式更新动态配置,拉方式比较可靠,但会有延迟同时有无效网络开销 (假设配置不常更新),服务器推方式能及时更新配置,但是实现较复杂,一般在服务和配置服务器之间要建立长连接。配置中心还要解决配置的版本控制和审计问题,对于大规模服务化环境,配置中心还要考虑分布式和高可用问题。 配置中心比较成熟的开源方案有百度的 Disconf,360 的 QConf,Spring 的 Cloud Config 和阿里的 Diamond 等。 Netflix 的微服务框架Netflix 是一家成功实践微服务架构的互联网公司,几年前,Netflix 就把它的几乎整个微服务框架栈开源贡献给了社区,这些框架和组件包括: Eureka: 服务注册发现框架Zuul: 服务网关Karyon: 服务端框架Ribbon: 客户端框架Hystrix: 服务容错组件Archaius: 服务配置组件Servo: Metrics 组件Blitz4j: 日志组件下图 Fig 11 展示了基于这些组件构建的一个微服务框架体系,来自 recipes-rss。 Fig 11, 基于 Netflix 开源组件的微服务框架 Netflix 的开源框架组件已经在 Netflix 的大规模分布式微服务环境中经过多年的生产实战验证,正逐步被社区接受为构造微服务框架的标准组件。Pivotal 去年推出的 Spring Cloud 开源产品,主要是基于对 Netflix 开源组件的进一步封装,方便 Spring 开发人员构建微服务基础框架。对于一些打算构建微服务框架体系的公司来说,充分利用或参考借鉴 Netflix 的开源微服务组件 (或 Spring Cloud),在此基础上进行必要的企业定制,无疑是通向微服务架构的捷径。 原文地址:https://www.infoq.cn/article/basis-frameworkto-implement-micro-service#anch130564%20%EF%BC%8C
auto_answer 2019-12-02 01:55:22 0 浏览量 回答数 0

回答

Re阿里云香港节点不稳定,百度蜘蛛无法访问 Baiduspider在24小时内,尝试连接您的网站发生错误率为50% 您可以在 抓取异常工具中查看详情 检测时间:2014-05-27 03:00:00 常见问题及推荐办法 可能是您的网站运行不正常,请检查网站的web服务器(如apache、iis)是否安装且正常运行,并使用浏览器检查主要页面能否正常访问 可能是您的网站和主机的防火墙阻止了Baiduspider,请检查您网站和主机的防火墙 您的网站可能服务器压力过大,超负荷运转。可能系统存在问题导致处理能力过慢,请检查网站的状况;或者请为您的服务器增加更多的资源 您可以使用抓取异常工具查看错误率高的一天的网站日志,在日志中找到错误并修复错误 ------------------------- Re阿里云香港节点不稳定,百度蜘蛛无法访问 Baiduspider通过电信无法访问您的网站 您可以在 抓取异常工具中查看详情 检测时间:2014-05-24 03:00:00 常见问题及推荐办法 可能是网络服务运营商存在问题,请与网络服务运营商进行联系,或者购买拥有双线服务的空间或者购买cdn服务 如果您已对电信网络进行了修复 请通知百度对您网站进行 ------------------------- Re阿里云香港节点不稳定,百度蜘蛛无法访问 Baiduspider通过联通无法访问您的网站 您可以在 抓取异常工具中查看详情 检测时间:2014-05-24 03:00:00 常见问题及推荐办法 可能是网络服务运营商存在问题,请与网络服务运营商进行联系,或者购买拥有双线服务的空间或者购买cdn服务 如果您已对联通网络进行了修复 请通知百度对您网站进行 ------------------------- Re阿里云香港节点不稳定,百度蜘蛛无法访问 什么情况,优化的站点,排名都被搞没了。赶紧引起重视,这机器用个毛啊。, ------------------------- Re阿里云香港节点不稳定,百度蜘蛛无法访问 你们赶紧尽快处理吧,一个月我肯定等不了了,一个月蜘蛛访问不了,我站早被百度K光了,我才上几天时间,转过去的好几个站都被百度降权,SITE不到首页了。我不要求你们速度提升,或者其他,但是你们要保证百度蜘蛛正常抓取啊  阿里云的哥哥们,就这么一点点要求。 让百度蜘蛛正常抓取网站,这个要不了一个月时间吧,你们扩容还有其他操作可以缓缓,先解决百度蜘蛛正常抓取网站吧,不然老是连通率0,每天都被百度站长工具报警,你让我情何以堪。。。。 ------------------------- Re阿里云香港节点不稳定,百度蜘蛛无法访问 还没好,。。。 Baiduspider在24小时内,尝试连接您的网站发生错误率为50% 您可以在 抓取异常工具中查看详情 检测时间:2014-06-04 11:00:00 常见问题及推荐办法 可能是您的网站运行不正常,请检查网站的web服务器(如apache、iis)是否安装且正常运行,并使用浏览器检查主要页面能否正常访问 可能是您的网站和主机的防火墙阻止了Baiduspider,请检查您网站和主机的防火墙 您的网站可能服务器压力过大,超负荷运转。可能系统存在问题导致处理能力过慢,请检查网站的状况;或者请为您的服务器增加更多的资源 您可以使用抓取异常工具查看错误率高的一天的网站日志,在日志中找到错误并修复错误 ------------------------- Re阿里云香港节点不稳定,百度蜘蛛无法访问 ------------------------- Re阿里云香港节点不稳定,百度蜘蛛无法访问 搞么飞机啊。。。,什么时候香港的能正常抓取。你们。 ------------------------- Re阿里云香港节点不稳定,百度蜘蛛无法访问 ------------------------- Re阿里云香港节点不稳定,百度蜘蛛无法访问 我说你们现在升级好了没?上面的新站点一月了都不收录,新站啊,新域名新站。不是一个,是几十个,什么情况你们,屏蔽了百度蜘蛛就直接说,我服务器退掉,搞到现在一个月了,你知道我们损失多大吗????
影子中国 2019-12-01 23:13:44 0 浏览量 回答数 0

问题

入侵防御系统怎样主宰网络安全市场金牌

当前的入侵防御系统在性能、功能多样性、易用性,以及服务方面都与用户需求有着不小的差距。未来的入侵防御系统只有在这几个方面都取得技术突破性进展,才有资格站上最高领奖台。在没有第三方机构提出未来入侵防御系统模型之前&...
elinks 2019-12-01 21:15:22 9640 浏览量 回答数 0

回答

与普通的IDC(Integrated Data Center)机房或服务器厂商相比,阿里云提供的云服务器ECS具有高可用性、安全性和弹性的优势。 高可用性 相较于普通的IDC机房以及服务器厂商,阿里云使用更严格的IDC标准、服务器准入标准以及运维标准,保证云计算基础框架的高可用性、数据的可靠性以及云服务器的高可用性。 阿里云提供的每个地域都存在多可用区。当您需要更高的可用性时,可以利用多可用区部署方案搭建主备服务或者双活服务。对于面向金融领域的两地三中心的解决方案,您也可以通过多地域和多可用区搭建出更高的可用性服务。其中包括容灾、备份等服务,阿里云都有非常成熟的解决方案。 阿里云的产品体系框架中的云服务之间可以实现平滑切换。更多有关两地三中心、电子商务、视频服务等解决方案,请参见阿里云行业解决方案。 此外,阿里云为您提供了如下三项支持: 提升可用性的产品和服务。包括云服务器ECS、负载均衡SLB、关系型数据库RDS以及数据迁移服务DTS等。 行业合作伙伴以及生态合作伙伴。帮助您完成更稳定的架构,并且保证服务的持续性。 多种多样的培训服务。让您从业务端到底层服务端,在整条链路上实现高可用。 安全性 阿里云通过了多种国际安全标准认证,包括ISO27001、MTCS等。安全合规性对于用户数据的私密性、用户信息的私密性以及用户隐私的保护力度都有非常严格的要求。 在网络建设方面,推荐您使用阿里云专有网络VPC。专有网络提供了稳定、安全、快速交付、自主可控的网络环境。对于传统行业以及未接触到云计算的行业和企业而言,借助专有网络混合云的能力和混合云的架构,将享受云计算所带来的技术红利。详情请参见阿里云专有网络VPC。 丰富的网络产品体系 您只需进行简单配置,就可在当前的业务环境下,与全球所有机房进行串接,从而提高了业务的灵活性、稳定性以及业务的可发展性。 与自建的IDC机房互连 阿里云专有网络可以建立高速通道到您原有的IDC机房,形成混合云的架构。阿里云提供了多种混合云解决方案和丰富的网络产品,形成强大的网络功能,让您的业务更加灵活。 专有网络的稳定性 业务搭建在专有网络上,而网络的基础设施将会不停进化,使您每天都拥有更新的网络架构以及更新的网络功能,让您的业务永远保持在一个稳定的状态。 专有网络的安全性 面对互联网上不断的攻击流量,专有网络天然具备流量隔离以及攻击隔离的功能。业务搭建在专有网络上后,专有网络会为业务筑起第一道防线。 视频介绍请参见云计算的安全性。 弹性 云计算最大的优势在于弹性与灵活性。阿里云拥有在数分钟内创建出一家中型互联网公司所需要的IT资源的能力,保证了大部分企业在云上所构建的业务都能够承受巨大的业务量压力。 阿里云的弹性体现在计算的弹性、存储的弹性、网络的弹性以及您对于业务架构重新规划的弹性。您可以使用任意方式去组合业务,阿里云都能够满足您的需求。 计算弹性 纵向的弹性。 即单台云服务器ECS的配置变更。普通IDC模式下,很难做到对单台服务器进行变更配置。而对于阿里云,当您购买了云服务器ECS或者存储的容量后,可以根据业务量的增减自由变更配置。关于纵向弹性的具体步骤,请参见升降配。 横向的弹性。 对于游戏应用或直播平台出现的高峰期,若在普通的IDC模式下,您根本无法立即准备资源;而云计算却可以使用弹性的方式帮助您度过这样的高峰。当业务高峰消失时,您可以将多余的资源释放掉,以减少业务成本。利用横向的扩展和缩减,配合阿里云的弹性伸缩,完全可以做到定时定量的伸缩,或者按照业务的负载进行伸缩。关于横向弹性的具体应用,请参见什么是弹性伸缩。 存储弹性 当数据量增多时,对于普通的IDC方案,您只能不断增加服务器,而这样扩展的服务器数量是有限的。阿里云为您提供海量的存储,您可以按需购买,为存储提供最大保障。关于存储弹性的具体应用,请参见云盘扩容。 网络弹性 阿里云的专有网络VPC的网络配置与普通IDC机房配置可以是完全相同的,并且可以拥有更灵活的拓展性。在阿里云,您可以实现各个可用区(机房)之间的互联互通、安全域隔离以及灵活的网络配置和规划。关于网络弹性的具体应用,请参见专有网络。 视频介绍请参见云计算的弹性。 与普通IDC对比优势 云服务器ECS与普通IDC的优势对比如下表所示。 对比项 云服务器ECS 普通IDC 机房部署 阿里云自主研发的直流电服务器,绿色机房设计,PUE(Power Usage Effectiveness,电源利用效率)值低 传统交流电服务器设计,PUE值高 骨干机房,出口带宽大,独享带宽 机房质量参差不齐,用户选择困难,以共享带宽为主 BGP(Border Gateway Protocol,边界网关协议)多线机房,全国访问流畅均衡 以单线和双线为主 操作易用 内置主流的操作系统,Windows正版激活 需用户自备操作系统,自行安装 可在线更换操作系统 无法在线更换操作系统,需要用户重装 Web在线管理,简单方便 没有在线管理工具,维护困难 手机验证密码设置,安全方便 重置密码麻烦,且被破解的风险大 容灾备份 三副本数据设计,单份损坏可在短时间内快速恢复 用户自行搭建,使用普通存储设备,价格高昂 用户自定义快照 没有提供快照功能,无法做到自动故障恢复 硬件故障事故中可快速自动恢复 数据损坏需用户修复 安全可靠 有效阻止MAC欺骗和ARP攻击 很难阻止MAC欺骗和ARP攻击 有效防护DDoS攻击,可进行流量清洗和黑洞 清洗和黑洞设备需要另外购买,价格昂贵 端口入侵扫描、挂马扫描、漏洞扫描等附加服务 普遍存在漏洞挂马和端口扫描等问题 灵活扩展 开通云服务器非常灵活,可以在线升级配置 服务器交付周期长 带宽升降自由 带宽一次性购买,无法自由升降 在线使用负载均衡,轻松扩展应用 硬件负载均衡,价格昂贵,设置也非常麻烦 节约成本 使用成本门槛低 使用成本门槛高 无需一次性大投入 一次性投入巨大,闲置浪费严重 按需购买,弹性付费,灵活应对业务变化 无法按需购买,必须为业务峰值满配
1934890530796658 2020-03-24 14:02:59 0 浏览量 回答数 0

问题

HBase 优化实战

转载自:http://www.hbase.group/article/39 背景 Datastream一直以来在使用HBase分流日志,每天的数据量很大,日均大概在80亿条,10T...
pandacats 2019-12-20 21:12:25 0 浏览量 回答数 0

问题

【产品经理访谈】干货分享:ECS存储、镜像、磁盘的分享与答疑

大家好,9月25日阿里云论坛举办了《产品经理访谈》第一期——“ECS产品经理 存储、镜像、磁盘分享答疑” 。在活动中,我们邀请了云服务器ECS高级产品专家竹雾来为大家解答各种疑问。小番茄已整理好这些干货ÿ...
xiaofanqie 2019-12-01 21:06:42 23915 浏览量 回答数 17

回答

简介 ES是一个基于RESTful web接口并且构建在Apache Lucene之上的开源分布式搜索引擎。 同时ES还是一个分布式文档数据库,其中每个字段均可被索引,而且每个字段的数据均可被搜索,能够横向扩展至数以百计的服务器存储以及处理PB级的数据。 可以在极短的时间内存储、搜索和分析大量的数据。通常作为具有复杂搜索场景情况下的核心发动机。 ES就是为高可用和可扩展而生的。一方面可以通过升级硬件来完成系统扩展,称为垂直或向上扩展(Vertical Scale/Scaling Up)。 另一方面,增加更多的服务器来完成系统扩展,称为水平扩展或者向外扩展(Horizontal Scale/Scaling Out)。尽管ES能够利用更强劲的硬件,但是垂直扩展毕竟还是有它的极限。真正的可扩展性来自于水平扩展,通过向集群中添加更多的节点来分担负载,增加可靠性。ES天生就是分布式的,它知道如何管理多个节点来完成扩展和实现高可用性。意味应用不需要做任何的改动。 Gateway,代表ES索引的持久化存储方式。在Gateway中,ES默认先把索引存储在内存中,然后当内存满的时候,再持久化到Gateway里。当ES集群关闭或重启的时候,它就会从Gateway里去读取索引数据。比如LocalFileSystem和HDFS、AS3等。 DistributedLucene Directory,它是Lucene里的一些列索引文件组成的目录。它负责管理这些索引文件。包括数据的读取、写入,以及索引的添加和合并等。 River,代表是数据源。是以插件的形式存在于ES中。  Mapping,映射的意思,非常类似于静态语言中的数据类型。比如我们声明一个int类型的变量,那以后这个变量只能存储int类型的数据。比如我们声明一个double类型的mapping字段,则只能存储double类型的数据。 Mapping不仅是告诉ES,哪个字段是哪种类型。还能告诉ES如何来索引数据,以及数据是否被索引到等。 Search Moudle,搜索模块,支持搜索的一些常用操作 Index Moudle,索引模块,支持索引的一些常用操作 Disvcovery,主要是负责集群的master节点发现。比如某个节点突然离开或进来的情况,进行一个分片重新分片等。这里有个发现机制。 发现机制默认的实现方式是单播和多播的形式,即Zen,同时也支持点对点的实现。另外一种是以插件的形式,即EC2。 Scripting,即脚本语言。包括很多,这里不多赘述。如mvel、js、python等。    Transport,代表ES内部节点,代表跟集群的客户端交互。包括 Thrift、Memcached、Http等协议 RESTful Style API,通过RESTful方式来实现API编程。 3rd plugins,代表第三方插件。 Java(Netty),是开发框架。 JMX,是监控。 使用案例 1、将ES作为网站的主要后端系统 比如现在搭建一个博客系统,对于博客帖子的数据可以直接在ES上存储,并且使用ES来进行检索,统计。ES提供了持久化的存储、统计和很多其他数据存储的特性。 注意:但是像其他的NOSQL数据存储一样,ES是不支持事务的,如果要事务机制,还是考虑使用其他的数据库做真实库。 2、将ES添加到现有系统 有些时候不需要ES提供所有数据的存储功能,只是想在一个数据存储的基础之上使用ES。比如已经有一个复杂的系统在运行,但是现在想加一个搜索的功能,就可以使用该方案。 3、将ES作为现有解决方案的后端部分 因为ES是开源的系统,提供了直接的HTTP接口,并且现在有一个大型的生态系统在支持他。比如现在我们想部署大规模的日志框架、用于存储、搜索和分析海量的事件,考虑到现有的工具可以写入和读取ES,可以不需要进行任何开发,配置这些工具就可以去运作。 设计结构 1、逻辑设计 文档 文档是可以被索引的信息的基本单位,它包含几个重要的属性: 是自我包含的。一篇文档同时包含字段和他们的取值。 是层次型的。文档中还可以包含新的文档,一个字段的取值可以是简单的,例如location字段的取值可以是字符串,还可以包含其他字段和取值,比如可以同时包含城市和街道地址。 拥有灵活的结构。文档不依赖于预先定义的模式。也就是说并非所有的文档都需要拥有相同的字段,并不受限于同一个模式 {   "name":"meeting",   "location":"office",   "organizer":"yanping" } {   "name":"meeting",   "location":{     "name":"sheshouzuo",        "date":"2019-6-28"   },   "memebers":["leio","shiyi"] } 类型 类型是文档的逻辑容器,类似于表格是行的容器。在不同的类型中,最好放入不同的结构的文档。 字段 ES中,每个文档,其实是以json形式存储的。而一个文档可以被视为多个字段的集合。 映射 每个类型中字段的定义称为映射。例如,name字段映射为String。 索引 索引是映射类型的容器一个ES的索引非常像关系型世界中的数据库,是独立的大量文档集合。   关系型数据库与ES的结构上的对比 2、物理设计 节点 一个节点是一个ES的实例,在服务器上启动ES之后,就拥有了一个节点,如果在另一个服务器上启动ES,这就是另一个节点。甚至可以在一台服务器上启动多个ES进程,在一台服务器上拥有多个节点。多个节点可以加入同一个集群。 当ElasticSearch的节点启动后,它会利用多播(multicast)(或者单播,如果用户更改了配置)寻找集群中的其它节点,并与之建立连接。这个过程如下图所示: 节点主要有3种类型,第一种类型是client_node,主要是起到请求分发的作用,类似路由。第二种类型是master_node,是主的节点,所有的新增,删除,数据分片都是由主节点操作(elasticsearch底层是没有更新数据操作的,上层对外提供的更新实际上是删除了再新增),当然也能承担搜索操作。第三种类型是date_node,该类型的节点只能做搜索操作,具体会分配到哪个date_node,就是由client_node决定,而data_node的数据都是从master_node同步过来的 分片 一个索引可以存储超出单个结点硬件限制的大量数据。比如,一个具有10亿文档的索引占据1TB的磁盘空间,而任一节点都没有这样大的磁盘空间;或者单个节点处理搜索请求,响应太慢。   为了解决这个问题,ES提供了将索引划分成多份的能力,这些份就叫做分片。当你创建一个索引的时候,你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的“索引”,这个“索引”可以被放置到集群中的任何节点上。 分片之所以重要,主要有两方面的原因:   1、允许你水平分割/扩展你的内容容量 允许你在分片(潜在地,位于多个节点上)之上进行分布式的、并行的操作,进而提高性能/吞吐量 至于一个分片怎样分布,它的文档怎样聚合回搜索请求,是完全由ES管理的,对于作为用户的你来说,这些都是透明的。   2、在一个网络/云的环境里,失败随时都可能发生,在某个分片/节点不知怎么的就处于离线状态,或者由于任何原因消失了。这种情况下,有一个故障转移机制是非常有用并且是强烈推荐的。为此目的,ES允许你创建分片的一份或多份拷贝,这些拷贝叫做复制分片,或者直接叫复制。 复制之所以重要,主要有两方面的原因: (1)在分片/节点失败的情况下,提供了高可用性。因为这个原因,注意到复制分片从不与原/主要(original/primary)分片置于同一节点上是非常重要的。 (2)扩展你的搜索量/吞吐量,因为搜索可以在所有的复制上并行运行 总之,每个索引可以被分成多个分片。一个索引也可以被复制0次(意思是没有复制)或多次。一旦复制了,每个索引就有了主分片(作为复制源的原来的分片)和复制分片(主分片的拷贝)之别。分片和复制的数量可以在索引创建的时候指定。在索引创建之后,你可以在任何时候动态地改变复制数量,但是不能改变分片的数量。   默认情况下,ES中的每个索引被分片5个主分片和1个复制,这意味着,如果你的集群中至少有两个节点,你的索引将会有5个主分片和另外5个复制分片(1个完全拷贝),这样的话每个索引总共就有10个分片。一个索引的多个分片可以存放在集群中的一台主机上,也可以存放在多台主机上,这取决于你的集群机器数量。主分片和复制分片的具体位置是由ES内在的策略所决定的。 3、插件HEAD elasticsearch-head是一个界面化的集群操作和管理工具 ● node:即一个 Elasticsearch 的运行实例,使用多播或单播方式发现 cluster 并加入。 ● cluster:包含一个或多个拥有相同集群名称的 node,其中包含一个master node。 ● index:类比关系型数据库里的DB,是一个逻辑命名空间。 ● alias:可以给 index 添加零个或多个alias,通过 alias 使用index 和根据index name 访问index一样,但是,alias给我们提供了一种切换index的能力,比如重建了index,取名● customer_online_v2,这时,有了alias,我要访问新 index,只需要把 alias 添加到新 index 即可,并把alias从旧的 index 删除。不用修改代码。 ● type:类比关系数据库里的Table。其中,一个index可以定义多个type,但一般使用习惯仅配一个type。 ● mapping:类比关系型数据库中的 schema 概念,mapping 定义了 index 中的 type。mapping 可以显示的定义,也可以在 document 被索引时自动生成,如果有新的 field,Elasticsearch 会自动推测出 field 的type并加到mapping中。 ● document:类比关系数据库里的一行记录(record),document 是 Elasticsearch 里的一个 JSON 对象,包括零个或多个field。 ● field:类比关系数据库里的field,每个field 都有自己的字段类型。 ● shard:是一个Lucene 实例。Elasticsearch 基于 Lucene,shard 是一个 Lucene 实例,被 Elasticsearch 自动管理。之前提到,index 是一个逻辑命名空间,shard 是具体的物理概念,建索引、查询等都是具体的shard在工作。shard 包括primary shard 和 replica shard,写数据时,先写到primary shard,然后,同步到replica shard,查询时,primary 和 replica 充当相同的作用。replica shard 可以有多份,也可以没有,replica shard的存在有两个作用,一是容灾,如果primary shard 挂了,数据也不会丢失,集群仍然能正常工作;二是提高性能,因为replica 和 primary shard 都能处理查询。另外,如上图右侧红框所示,shard数和replica数都可以设置,但是,shard 数只能在建立index 时设置,后期不能更改,但是,replica 数可以随时更改。但是,由于 Elasticsearch 很友好的封装了这部分,在使用Elasticsearch 的过程中,我们一般仅需要关注 index 即可,不需关注shard。   shard、node、cluster 在物理上构成了 Elasticsearch 集群,field、type、index 在逻辑上构成一个index的基本概念,在使用 Elasticsearch 过程中,我们一般关注到逻辑概念就好,就像我们在使用MySQL 时,我们一般就关注DB Name、Table和schema即可,而不会关注DBA维护了几个MySQL实例、master 和 slave 等怎么部署的一样。 ES中的索引原理 (1)传统的关系型数据库 二叉树查找效率是logN,同时插入新的节点不必移动全部节点,所以用树型结构存储索引,能同时兼顾插入和查询的性能。因此在这个基础上,再结合磁盘的读取特性(顺序读/随机读),传统关系型数据库采用了B-Tree/B+Tree这样的数据结构做索引 (2)ES 采用倒排索引 那么,倒排索引是个什么样子呢? 首先,来搞清楚几个概念,为此,举个例子: 假设有个user索引,它有四个字段:分别是name,gender,age,address。画出来的话,大概是下面这个样子,跟关系型数据库一样 Term(单词):一段文本经过分析器分析以后就会输出一串单词,这一个一个的就叫做Term Term Dictionary(单词字典):顾名思义,它里面维护的是Term,可以理解为Term的集合 Term Index(单词索引):为了更快的找到某个单词,我们为单词建立索引 Posting List(倒排列表):倒排列表记录了出现过某个单词的所有文档的文档列表及单词在该文档中出现的位置信息,每条记录称为一个倒排项(Posting)。根据倒排列表,即可获知哪些文档包含某个单词。(PS:实际的倒排列表中并不只是存了文档ID这么简单,还有一些其它的信息,比如:词频(Term出现的次数)、偏移量(offset)等,可以想象成是Python中的元组,或者Java中的对象) (PS:如果类比现代汉语词典的话,那么Term就相当于词语,Term Dictionary相当于汉语词典本身,Term Index相当于词典的目录索引) 我们知道,每个文档都有一个ID,如果插入的时候没有指定的话,Elasticsearch会自动生成一个,因此ID字段就不多说了 上面的例子,Elasticsearch建立的索引大致如下: name字段: age字段: gender字段: address字段: Elasticsearch分别为每个字段都建立了一个倒排索引。比如,在上面“张三”、“北京市”、22 这些都是Term,而[1,3]就是Posting List。Posting list就是一个数组,存储了所有符合某个Term的文档ID。 只要知道文档ID,就能快速找到文档。可是,要怎样通过我们给定的关键词快速找到这个Term呢? 当然是建索引了,为Terms建立索引,最好的就是B-Tree索引(MySQL就是B树索引最好的例子)。 我们查找Term的过程跟在MyISAM中记录ID的过程大致是一样的 MyISAM中,索引和数据是分开,通过索引可以找到记录的地址,进而可以找到这条记录 在倒排索引中,通过Term索引可以找到Term在Term Dictionary中的位置,进而找到Posting List,有了倒排列表就可以根据ID找到文档了 (PS:可以这样理解,类比MyISAM的话,Term Index相当于索引文件,Term Dictionary相当于数据文件) (PS:其实,前面我们分了三步,我们可以把Term Index和Term Dictionary看成一步,就是找Term。因此,可以这样理解倒排索引:通过单词找到对应的倒排列表,根据倒排列表中的倒排项进而可以找到文档记录) 为了更进一步理解,用两张图来具现化这一过程: (至于里面涉及的更加高深的数据压缩技巧,以及多个field联合查询利用跳表的数据结构快速做运算来查询,这些大家有兴趣可以自己去了解)
问问小秘 2020-04-29 15:40:48 0 浏览量 回答数 0
阿里云企业服务平台 陈四清的老板信息查询 上海奇点人才服务相关的云产品 爱迪商标注册信息 安徽华轩堂药业的公司信息查询 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 天籁阁商标注册信息 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 北京芙蓉天下的公司信息查询