精华内容
下载资源
问答
  • 十分钟理解博弈论“纳什均衡” -- Nash Equilibrium

    万次阅读 多人点赞 2016-03-20 00:52:45
    所谓纳什均衡,指的是参与人的这样一种策略组合,在该策略组合上,任何参与人单独改变策略都...换句话说,如果在一策略组合上,当所有其他人都不改变策略时,没有人会改变自己的策略,则该策略组合就是一纳什均衡

    欢迎转载,转载请注明:本文出自Bin的专栏blog.csdn.net/xbinworld。
    技术交流QQ群:433250724,欢迎对算法、技术感兴趣的同学加入。


    纳什均衡(或者纳什平衡),Nash equilibrium ,又称为非合作博弈均衡,是博弈论的一个重要策略组合,以约翰·纳什命名。


    约翰·纳什,生于1928年6月13日。著名经济学家、博弈论创始人、《美丽心灵》男主角原型。前麻省理工学院助教,后任普林斯顿大学数学系教授,主要研究博弈论、微分几何学和偏微分方程。由于他与另外两位数学家(经济学家,约翰·C·海萨尼和莱因哈德·泽尔腾)在非合作博弈的均衡分析理论方面做出了开创性的贡献,对博弈论和经济学产生了重大影响,而获得1994年诺贝尔经济学奖。

    纳什的人生非常曲折,一度学术成果不被认可,甚至换上严重的精神分裂症,在爱的力量下在很多年后奇迹般地恢复,并最终获得诺内尔经济学奖。影片《美丽心灵》(A Beautiful Mind)是一部改编自同名传记而获得奥斯卡金像奖的电影,影片以约翰·纳什与他的妻子艾莉西亚(曾离婚,但2001年复婚)以及普林斯顿的朋友、同事的真实感人故事为题材,艺术地重现了这个爱心呵护天才的传奇故事。

    这里写图片描述
    年轻时的Nash,很帅噢


    纳什均衡定义

    经济学定义[3]
    所谓纳什均衡,指的是参与人的这样一种策略组合,在该策略组合上,任何参与人单独改变策略都不会得到好处。换句话说,如果在一个策略组合上,当所有其他人都不改变策略时,没有人会改变自己的策略,则该策略组合就是一个纳什均衡。

    数学定义
    纳什均衡的定义:在博弈G=﹛S1,…,Sn:u1,…,un﹜中,如果由各个博弈方的各一个策略组成的某个策略组合(s1*,…,sn*)中,任一博弈方i的策略si*,都是对其余博弈方策略的组合(s1*,…s*i-1,s*i+1,…,sn*)的最佳对策,也即ui(s1*,…s*i-1,si*,s*i+1,…,sn*)≥ui(s1*,…s*i-1,sij*,s*i+1,…,sn*)对任意sij∈Si都成立,则称(s1*,…,sn*)为G的一个纳什均衡。

    :经济学定义从字面上还是相对比较好理解的;这里稍微解释一下数学定义,博弈论也称Game Theory,一场博弈用G表示,Si表示博弈方i的策略,ui表示收益。因此,纳什均衡的意思是:任何一方采取的策略都是对其余所有方采取策略组合下的最佳对策;当所有其他人都不改变策略时,为了让自己的收益最大,任何一方都不会(或者无法)改变自己的策略,这个时候的策略组合就是一个纳什均衡。

    纳什证明了在每个参与者都只有有限种策略选择、并允许混合策略的前提下,纳什均衡一定存在。以两家公司的价格大战为例,纳什均衡意味着两败俱伤的可能:在对方不改变价格的条件下,既不能提价,否则会进一步丧失市场;也不能降价,因为会出现赔本甩卖。于是两家公司可以改变原先的利益格局,通过谈判寻求新的利益评估分摊方案,也就是Nash均衡。类似的推理当然也可以用到选举,群体之间的利益冲突,潜在战争爆发前的僵局,议会中的法案争执等。


    纳什均衡案例

    以下介绍几个经典的纳什均衡案例[2][4],因为本文主要是以科普为主,所以案例不会涉及到复杂深奥的经济学问题(事实上,我也不懂,哈~)。

    (1)囚徒困境

    假设有两个小偷A和B联合犯事、私入民宅被警察抓住。警方将两人分别置于不同的两个房间内进行审讯,对每一个犯罪嫌疑人,警方给出的政策是:如果一个犯罪嫌疑人坦白了罪行,交出了赃物,于是证据确凿,两人都被判有罪。如果另一个犯罪嫌疑人也作了坦白,则两人各被判刑8年;如果另一个犯罪嫌人没有坦白而是抵赖,则以妨碍公务罪(因已有证据表明其有罪)再加刑2年,而坦白者有功被减刑8年,立即释放。如果两人都抵赖,则警方因证据不足不能判两人的偷窃罪,但可以私入民宅的罪名将两人各判入狱1年。

    此时产生了两个嫌疑人之间的一场博弈:

    这里写图片描述

    表中的数字表示A,B各自的判刑结果。博弈论分析中一般都用这样的表来表示。

    该案例,显然最好的策略是双方都抵赖,结果是大家都只被判1年。但是由于两人处于隔离的情况,首先应该是从心理学的角度来看,当事双方都会怀疑对方会出卖自己以求自保、其次才是亚当·斯密的理论,假设每个人都是“理性的经济人”,都会从利己的目的出发进行选择。这两个人都会有这样一个盘算过程:假如他坦白,如果我抵赖,得坐10年监狱,如果我坦白最多才8年;假如他要是抵赖,如果我也抵赖,我就会被判一年,如果我坦白就可以被释放,而他会坐10年牢。综合以上几种情况考虑,不管他坦白与否,对我而言都是坦白了划算。两个人都会动这样的脑筋,最终,两个人都选择了坦白,结果都被判8年刑期。

    注:亚当·斯密的理论(“看不见的手”原理),在市场经济中,每一个人都从利己的目的出发,而最终全社会达到利他的效果。但是我们可以从“纳什均衡”中引出“看不见的手”原理的一个悖论:从利己目的出发,结果损人不利己,既不利己也不利他。

    (2)智猪博弈

    猪圈里有两头猪,一头大猪,一头小猪。猪圈的一边有个踏板,每踩一下踏板,在远离踏板的猪圈的另一边的投食口就会落下少量的食物。如果有一只猪去踩踏板,另一只猪就有机会抢先吃到另一边落下的食物。当小猪踩动踏板时,大猪会在小猪跑到食槽之前刚好吃光所有的食物;若是大猪踩动了踏板,则还有机会在小猪吃完落下的食物之前跑到食槽,争吃到另一半残羹。

    那么,两只猪各会采取什么策略?答案是:小猪将选择“搭便车”策略,也就是舒舒服服地等在食槽边;而大猪则为一点残羹不知疲倦地奔忙于踏板和食槽之间。

    原因何在?因为,小猪踩踏板将一无所获,不踩踏板反而能吃上食物。对小猪而言,无论大猪是否踩动踏板,不踩踏板总是好的选择。反观大猪,已明知小猪是不会去踩动踏板的,自己亲自去踩踏板总比不踩强吧,所以只好亲力亲为了。

    (3)普通范式博弈

    GOO公司和SAM公司是某手机产品生态的两大重量级参与者,双方在产业链的不同位置上各司其职且关系暧昧,有时也往往因商业利益和产品影响力的争夺而各怀异心。二者的收益也随着博弈的变化而不断更替。

    这里写图片描述

    上图表格模拟了两家公司的博弈现状,双方各有两个可选策略“合作”与“背叛”,格中的四组数据表示四个博弈结局的分数(收益),每组数据的第一个数字表示GOO公司的收益,后一个数字表示SAM公司的收益。

    博弈是同时进行的,一方参与者必须站在对方的角度上来思考我方的策略选择,以追求收益最大化。这在博弈论里称作Putting yourselves into other people’s shoes。

    现在我们以GOO公司为第一人称视角来思考应对SAM公司的博弈策略。假如SAM公司选择合作,那么我方也选择合作带来的收益是3,而我方选择背叛带来的收益是5,基于理性的收益最大化考虑,我方应该选择背叛,这叫严格优势策略;假如SAM公司选择背叛,那么我方选择合作带来的收益是-3,而选择背叛带来的收益为-1,为使损失降到最低,我方应该选择背叛。最后,GOO公司的分析结果是,无论SAM公司选择合作还是背叛策略,我方都必须选择背叛策略才能获得最大化的收益。

    同理,当SAM公司也以严格优势策略来应对GOO公司的策略选择时,我们重复上述分析过程,就能得出结论:无论GOO公司选择合作还是背叛策略,SAM公司都必须选择背叛策略才能获得最大化收益。

    最后我们发现,本次博弈的双方都采取了背叛策略,各自的收益都为-1,这是一个比较糟糕的结局,尽管对任何一方来说都不是最糟糕的那种。这种局面就是著名的“囚徒困境”。

    但是,博弈的次数往往不止一次,就像COO与SAM公司双方的商业往来也许会有很多机会。当二者经历了多次背叛策略的博弈之后,发现公式上还有一个(3,3)收益的双赢局面,这比(-1,-1)的收益结果显然要好很多,因此二者在之后的博弈过程中必然会尝试互建信任,从而驱使双方都选择合作策略。

    这里有一个理想化假设,那就是假设双方都知道博弈次数是无限的话,也就是说双方的商业往来是无止尽的,那么二者的策略都将持续选择合作,最终的博弈收益将定格在(3,3),这就是一个纳什均衡。既然博弈次数是无限的,那么任何一方都没有理由选择背叛策略去冒险追求5点短暂收益,而招致对方在下一轮博弈中的报复(这种报复在博弈论里称作“以牙还牙”策略)。

    还有另一种假设情况是,假使双方都知道博弈次数是有限的,也许下一次博弈就是最后一次,那么为了避免对方在最后一轮博弈中选择背叛策略而使我方遭受-3的收益损失,于是双方都重新采取了背叛的策略选择,最后的博弈结果又回到了(-1,-1),这就形成了第二个纳什均衡。

    由此可见,随着次数(博弈性质)的变化,纳什均衡点也并非唯一。

    (4)饿狮博弈

    假设有A、B、C、D、E、F六只狮子(强弱从左到右依次排序)和一只绵羊。假设狮子A吃掉绵羊后就会打盹午睡,这时比A稍弱的狮子B就会趁机吃掉狮子A,接着B也会午睡,然后狮子C就会吃掉狮子B,以此类推。那么问题来了,狮子A敢不敢吃绵羊?

    为简化说明,我们先给出此题的解法。该题须采用逆向分析法,也就是从最弱的狮子F开始分析,依次前推。假设狮子E睡着了,狮子F敢不敢吃掉狮子E?答案是肯定的,因为在狮子F的后面已没有其它狮子,所以狮子F可以放心地吃掉午睡中的狮子E。

    继续前推,既然狮子E睡着会被狮子F吃掉,那么狮子E必然不敢吃在他前面睡着的狮子D。

    再往前推,既然狮子E不敢吃掉狮子D,那么D则可以放心去吃午睡中的狮子C。依次前推,得出C不吃,B吃,A不吃。所以答案是狮子A不敢吃掉绵羊。

    推理结果如下图:
    这里写图片描述

    但是,如果我们在狮子F的后面增加了一只狮子G,总数变成7只,用逆向分析法按照上题步骤再推一次,很容易得出结论:狮子G吃,狮子F不吃,E吃,D不吃,C吃,B不吃,A吃。这次的答案变成了狮子A敢吃掉绵羊。

    这里写图片描述

    对比两次博弈我们发现,狮子A敢不敢吃绵羊取决于狮子总数的奇偶性,总数为奇数时,A敢吃掉绵羊;总数为偶数时,A则不敢吃。因此,总数为奇数和总数为偶数的狮群博弈结果形成了两个稳定的纳什均衡点。

    (5)硬币正反

    你正在图书馆枯坐,一位陌生美女主动过来和你搭讪,并要求和你一起玩个数学游戏。美女提议:“让我们各自亮出硬币的一面,或正或反。如果我们都是正面,那么我给你3元,如果我们都是反面,我给你1元,剩下的情况你给我2元就可以了。”那么该不该和这位姑娘玩这个游戏呢?

    每一种游戏依具其规则的不同会存在两种纳什均衡,一种是纯策略纳什均衡,也就是说玩家都能够采取固定的策略(比如一直出正面或者一直出反面),使得每人都赚得最多或亏得最少;或者是混合策略纳什均衡,而在这个游戏中,便应该采用混合策略纳什均衡。

    这里写图片描述

    假设我们出正面的概率是x,反面的概率是1-x,美女出正面的概率是y,反面的概率是1-y。为了使利益最大化,应该在对手出正面或反面的时候我们的收益都相等,由此列出方程就是

    3x + (-2)(1-x)=(-2) * x + 1*( 1-x )——解方程得x=3/8;同样,美女的收益,列方程-3y + 2( 1-y)= 2y+ (-1) * ( 1-y)——解得y也等于3/8。

    于是,我们就可以算美女每次的期望收益是: (1-y)(2x-(1-x)) + y(-3x+2(1-x)) = 1/8元,也就是说,双方都采取最优策略的情况下,平均每次美女赢1/8元。

    其实只要美女采取了(3/8,5/8)这个方案,不论你再采用什么方案,都是不能改变局面的。如果全部出正面,每次的期望收益是 (3+3+3-2-2-2-2-2)/8=-1/8元;如果全部出反面,每次的期望收益也是(-2-2-2+1+1+1+1+1)/8=-1/8元。比如你用完全随机(1/2,1/2)策略,收益是1/2(3/8 * 3 + 5/8 * (-20)) + 1/2(3/8 * (-2) + 5/8 * 1) = -1/8;实际上,不论你用什么策略,你的收益都是-1/8,也就是说,随便玩一种策略,你都是在纳什均衡状态中的,所以,这个把戏你随便怎么玩,都是亏的。

    以下一段补充说明(补充于2017年5月30日端午节,大家端午快乐!):
    这个例子中是没有纯战略纳什均衡的,因为只出一种策略,肯定有一方要亏钱,所以并不是其均衡状态(明明只要换一边就可以赚钱了,所以不是最佳策略);而混合纳什均衡是纯在的,事实上,Nash告诉我们“每个参与者都只有有限种策略选择、并允许混合策略的前提下,纳什均衡一定存在”,如果美女出(3/8,5/8)这个方案,另一边任何玩法都是期望收益一样的,也就满足了纳什均衡的条件。


    纳什均衡分类

    最后讲一讲纳什均衡的分类。纳什均衡可以分成两类:“纯战略纳什均衡”和“混合战略纳什均衡”。

    要说明纯战略纳什均衡和混合战略纳什均衡,要先说明纯战略和混合战略。所谓纯战略是提供给玩家要如何进行赛局的一个完整的定义。特别地是,纯战略决定在任何一种情况下要做的移动。战略集合是由玩家能够施行的纯战略所组成的集合。而混合战略是对每个纯战略分配一个机率而形成的战略。混合战略允许玩家随机选择一个纯战略。混合战略博弈均衡中要用概率计算,因为每一种策略都是随机的,达到某一概率时,可以实现支付最优。因为机率是连续的,所以即使战略集合是有限的,也会有无限多个混合战略。

    当然,严格来说,每个纯战略都是一个“退化”的混合战略,某一特定纯战略的机率为 1,其他的则为 0。
    故“纯战略纳什均衡”,即参与之中的所有玩家都玩纯战略;而相应的“混合战略纳什均衡”,之中至少有一位玩家玩混合战略。并不是每个赛局都会有纯战略纳什均衡,例如“钱币问题”就只有混合战略纳什均衡,而没有纯战略纳什均衡。不过,还是有许多赛局有纯战略纳什均衡(如协调赛局,囚徒困境和猎鹿赛局)。甚至,有些赛局能同时有纯战略和混合战略均衡。


    参考资料

    [1] http://baike.baidu.com/view/52630.htm,百度百科:约翰·纳什
    [2] http://baike.baidu.com/view/28460.htm,百度百科:纳什均衡
    [3] 高鸿业.西方经济学(微观部分)第五版:人民大学出版社,2011:292-296
    [4] http://www.vccoo.com/v/7074d4,一般人也能看懂的纳什均衡案例

    展开全文
  • 要建立一个均衡的平台 ──任正非在公司秘书业务培训班上的讲话 在座的各位都是秘书,从事着秘书的工作。怎样做一合格、称职的秘书,来适应华为公司超大规模的发展,是我们这次学习的目的。 做一秘书,首先要...

    要建立一个均衡的平台

    ──任正非在公司秘书业务培训班上的讲话

    在座的各位都是秘书,从事着秘书的工作。怎样做一个合格、称职的秘书,来适应华为公司超大规模的发展,是我们这次学习的目的。

    做一个秘书,首先要具备做一个基本文员的条件。如果你没有达到做一个基本文员的标准,我认为秘书是做不好的。

    我们公司过去最好的秘书是张燕燕,她是公司最早的秘书。人们常常怀念张燕燕时代,就是她十分投入地服务,人们对她印象很深。她的秘书工作做得相当不错,因为她个人,无论是在品德上、技能上、管理上都出类拔萃。譬如打字,当年她打字是非常非常快的,好多人都比不过她。她参加公司的管理,也做了大量的工作。虽然现在她在做公司的副总裁,但她依然刻苦钻研业务,如进出口业务、物料采购等。

    从秘书成长为公司的副总裁,张燕燕为公司的发展作出了她应有的贡献!你们以后也可以私下和张燕燕交流交流。

    我们公司秘书的前途在哪儿呢?我认为在你们手里。

    华为公司要大规模地推行网络化的管理、矩阵管理,推行计算机体系化管理,怎么个管法呢?秘书在这里面起了很大的作用!经理们主要是对一些宏观的、重要的、更需要平衡思维的方面进行决策,更多的事则由秘书在公司允许的一个误差范围内来处理,因为日常的交流与管理,不一定非要经理亲自来做。如果象公司这样一个大的信息系统都由经理来处理,你说他能有多大水平?所以单就秘书工作而言,这是一个重要的岗位。可是现在有很多秘书,只会打字,我看就很有必要加以提高。

    应该说,我们华为公司的秘书系统是比较庞大的,可能中国很少有这样的公司,有一百四、五十个秘书人员,而且文化素质总的都是比较高的,基本上都是本科以上,如果大家都能把握到发展的脉搏的话,那发展前途还是十分大的。

    作为秘书,你要主动地服务。主动地服务,并不是要你成为一个中心,我们全公司都为你服务,这是不可能的。秘书的主动性,是一个很重要的因素。你要做一个合格的秘书,是不容易的。这是我说的第一点。

    第二点,就是“善解人意”,这是秘书的一个最重要的原则,是必须好好把握的。

    善解人意,通俗地说,就是人家想做啥,你就把这个事情准备好;或者是人家说了这句话,你就把它整理成一个有条理的东西。

    当然,要做到善解人意,你必须拓宽你的知识面。如果你不精通天文地理,不通晓古往今来的历史,不了解世界科技发展的现状,你怎么可能善解人意?这是从大的方面讲;从小的方面讲,华为公司有什么重大决策,有什么样的规划、计划……公司发了这么多的文件,你是否认真去读过、思考过?

    另外,你还要努力寻找彼此间共同的语言,如何才能与经理产生共同的语言,你琢磨过了吗?

    这些都是你达到善解人意的前提条件。否则,你就不能善解人意。既然不能善解人意,则要你这个秘书又有何用呢?你一定要理解你的领导要做什么?与周边的关系需要你的领导来解决什么?你的领导应该向周围扩散什么?公司的这个运行火车里头有什么在运行?你只有把握住了这个脉搏,才可能成为一个好秘书。

    我记得张燕燕做秘书的时候,石油部的领导对她有过很好的评价。他对我说:“你的这个秘书,特别能善解人意。你想做什么事,她在电话里就帮你处理了,但是你并没有交待她做什么事。”

    因此我认为对一个秘书来说,不要仅仅满足会打字,还要经常阅读公司的文件。公司的很多文件发下去,首先是到你们手里,并没有说不给你们看,那么你们不学习便是你们自己的问题了。公司的文件要学习,古往今来的历史要学习,天文地理要学习,世界科技发展的潮流要学习,我们客户的投诉要学习……这些都是很重要的信息源。你只有学通了这些东西,并加以掌握,才有可能善解人意。善解人意了,助手的工作不就做成了吗?就可以起助手的作用了嘛!

    第三,秘书要善于归纳。

    我觉得秘书的差距有时是很大的,其差距就在归纳上。

    以前我讲完话以后,我的秘书很快就能归纳成一篇文章。其实,文章里有些话我并不就是这么说的,而且在说话过程中,废话一定也不少,这是口语嘛!所以,这就要求秘书善于归纳总结给我看。如果我觉得需要改动的很少,那我就认为这个秘书的水平高,她能够理解、善解人意、善于归纳。

    有一些秘书用录音机一录音,送给我的便是这样一个录音稿。我想这个录音稿若是发表在报刊上,那一定很“臭”!肯定是很“臭”的!因为演说词与文字稿毕竟是有很大区别的。至少它的条理性并不是很强。

    你们经理的思维有很多可能是创造性的思维。他有时在会上只讲一、两句,就不说了,因为在座的都是他比较了解的人,一句话、二句话,就可以达到相互间的默契,就会达到相互间应用的交流。但是作为秘书,不能把他的两个字、一句话简单地写上去,那样很多人会读不明白,这个会议的主题是什么都不清楚。因此,要把这些关键、重点的字眼加以发挥,用文字准确地表达出说话者或指示者本人的意思。说话者或指示者的意思错了,那由他本人负责,但是作为秘书要把他本人的意思准确地翻译出来。

    所以,对一个秘书而言,首先要博览,然后要善于归纳。没有归纳,就掌握不住重点,就没有力量。我认为这是一个很重要的因素。

    第四,公司要重视文档建设。

    文档建设很重要的工作是由秘书来完成的。大家知道,开发部有些部门的文档建设做得比较好,我就提出来了,每年我们愿意出几千万购买开发部的文档!就是我们重视到这个程度,但是否我们所有的经理都给予了相应的重视呢?不一定的。

    如果文档未做好,对我们这样的公司来说,是非常危险的。对一个发展非常快的公司,对一个人员结构经常变的公司,如果没有大量的文档建设的话,是非常危险的,甚至会走到破产的边缘!

    比如说我们的万门机,如果我们没有良好的文档建设,没有记录下我们所走过的历程,当主持万门机工作的同志们一升官,走掉了,或者调到其它部门,过几个月请他回来说一说万门机的情况,可能也说不清楚了。在此情况下,我们只能重做万门机的软件。大家知道我们的200号就是重做了一次软件的。因为许国平出了车祸,当时文档建设还不是很好,为了200号能够出去,我们又相当于重做了一次文档。可见这个软件的重要性有多大呀!

    有了良好的文档建设,我们就能跟着前人的脚印前进,去理解他们的思维,接收下他们的系统,从而增加产品系统的可继承性。

    你们知道,我们公司现在不仅仅是在卖一台机器,而在有的地方卖支撑网了。

    那么支撑网是什么东西呢?就是说我们一个一个大交换机要用一个网联接起来,网的结构有信令网、同步网、交换网。可以想象,一旦这些支撑网停下来,就等于整个国民经济停下来!──火车不能走了,走了就要撞车了……──那么我们进入到这样一个高的层次以后,越往后走,胆子就越来越小而不是越来越大。胆子能否大起来,就取决于文档建设。

    美国纽约到新泽西州的7号信令网出了故障,瘫痪了7个小时。美国的AT&T、贝尔实验室,这么大的公司,做了这么久的工作,也出了这样的故障!不能说我们华为公司就不会出故障。谁也没有这个胆量拍这个胸口。关键在,出了这个故障以后,我们公司有没有能力在七个小时内排除几千公里的支撑网的技术故障,这里很重要的方面是查看档案,在发现这个问题以后,尽快翻阅我们的历史档案,在这个问题上我们是怎么考虑的?当时的考虑与今天运行的网是否有冲突?有,就尽快把这个软件修改了,然后弥补。可见,文档工作的重要。

    第五,要进行秘书系统整顿。

    公司要大规模发展,还要进行整顿。如果我们不提高自身的素质,便不能打赢一场大规模的战争。

    我们公司的办公体系要条理化、规范化、制度化,起点从哪开始?从秘书开始。只有秘书工作条理化、规范化、制度化后,才能带动其它方面进步。“牵一发而动全身”嘛!

    将来秘书工作规范化、制度化是一个很重要的工作。我们公司下阶段要引进美国的MRPⅡ软件,这个管理软件一旦引进,我们公司大量的经理们就消失了,我们的干部队伍就减少了很多,没有这么复杂了。由计算机取代了这项工作,但实际上秘书队伍会更庞大、服务性队伍会更庞大。因此你们现在提高自己的水平,对公司的发展也是有巨大的意义的。现在我们为什么要对秘书进行评定、进行考核?就是要推动我们公司下一阶段的规模发展。

    我们现在市场对抗的公司就是美国的AT&T、法国的阿尔卡特、德国的西门子等几家公司,可见我们的对抗力量已经进入国际状况。但是我们公司仍然是一家比较小的公司,公司的能量发挥还不够。公司是建立在我国整个管理平台还比较低的基础上的,什么都要靠自己摸索。而且,我们很快要推行矩阵管理,要否定掉宝塔式管理、层层管理这种形式。推行矩阵管理之后,秘书的工作更是纵横交错,公司要形成多个权力中心、受理中心,中心的权力会一步步分配到最原本的机构和单位上去,那么管理和操作这些系统,对秘书的要求会更高。

    我们公司有很多人到国外访问过,你们可以把他们请来作报告,象郑宝用、张燕燕等,没有一个人不对国外的秘书系统作出高度的评价,包括我自己。不论是欧美、还是日本等,它们的秘书系统发挥得相当出色。反观我们的秘书系统,则还比较混乱、低效。所以我认为今天通过这个培训、通过这个提升,使得我们对公司的经营水平提升一步。这次对你们也要考核、定级,也关系到你们的切身利益,所以你们认真学习、出好成绩也是很重要的。

    在公司秘书系统里尚没有博士一级的人员,但硕士有不少了,作为秘书系统承担公司发展的重担,现在还是很不够的。我们公司有一部分是畸形发展,不够均衡,过去比较重视技术和市场。这两个部门较受重视、干部也强一点。现在要建立一个均衡的系统,秘书在这里起非常重要的调节作用,很多事情没有必要由经理和经理碰头来完成。我们实行矩阵管理以后,多个权力中心之间的秘书可以相互协商,形成初步意见,报至经理办公会批准,形成一个决议,这个决议对全公司进行指导。

    象我们这样大小的公司,在美国可能年销售额3~5亿美元,而我们才2亿美元,能量还未充分发挥,其中相当多的是无效劳动。如果秘书能有效地相互沟通,无效劳动是可以减少的。所以,我们公司要进行现代化的管理,秘书是一个相当大的平台。

    我们今年要花大资金从国外购买计算机管理网络系统──这个网络系统本来我们也曾开发了,但它的弹性不够,随着公司的大发展,就把这个平台撕开了,撕开了以后,一直在修补,使我们不能有效地利用起这个系统──这个软件回来后,其中有很大的工作是由秘书来完成、是由秘书先来消化的,可能是由秘书先把经理培训会了;也可能是先对经理们进行系列培训。我认为,推行新的管理系统,秘书将会起到非常重大的作用!

    最后一点,对秘书的希望。

    大家知道,现在全国程控交换机并不是供不应求,而是供过于求。而华为公司则是供货不已,而且还要限制卖!在这种低潮之下,我们还有这种能量,那么,96、97、98年三年将是华为公司超大规模发展的三年。在这大跃进的三年中,如果我们不乱,则在很大程度上取决于秘书系统不乱,有条不紊。

    华为公司的整体水平在提升,如果我们的秘书跟不上趟,则你们就拖了公司很大的后腿。

    我认为,通过这次考核,工作应有调整,即使工资级别的确定,也要参考一下其实际表现和这一次的学习成绩。这些都应有所参考。当然以后还要多次考试、多次学习,那么大家都争取好成绩吧!将来我们也开放一些高级秘书的位置,把高级秘书的条件公布出来,招标嘛!可以用内部招标的形式来解决。

    我希望大家一定要学习好,认真考核;同时对大家的评定要客观、要公正。至于对个别同志的工作要调整,也不要有什么意见。为了明天更大规模的发展作好准备,每个人的能力有大也有小,只要能够到一个你能发挥工作作用的地方,我认为就非常有意义了。

    我们在座的人都很年轻,你们的可培养性很强。在目前的发展形势之下,我认为我们的秘书队伍总的说来是非常可爱的,为公司的发展作出了很大的贡献。但我们必须正视我们,同世界各国相比,我们还有差距,还须不断地学习、不断地提升。大家不要寄望于这一、二次培训,这一、二次考试上,每一天、每一时、每一刻都是学习的机会!古人云:“三人行,必有我师焉。”希望你们抓紧时间、抓住机遇、不断学习、努力进取,为公司的发展作出自己应有的贡献!

    展开全文
  • 全栈必备 负载均衡

    千次阅读 2016-10-13 10:07:48
    了不起的创意会产生一很棒的产品,如果它一炮走红,你发现手中的是下一facebook 或者twitter,而且随着用户越来越多,系统变得越来越慢,该...对全栈而言,解决这类问题的一重要技能就是——负载均衡......

    一个了不起的创意会产生一个很棒的产品,如果它一炮走红,你发现手中的是下一个facebook 或者twitter,而且随着用户越来越多,会变得越来越慢,该怎么办呢?对全栈而言,解决这类问题的一个重要技能就是——负载均衡。

    什么是负载均衡

    负载(load)一词起源于典型系统,指连接在电路中消耗电能的装置,负载(用电器)的功能是把电能转变为其他形式能。引申出来,一个是实体,一个转化。

    于是,对于实体,有了通信帧或者报文中数据字段的内容被称为信息负载(payload),网络负载指的就是网络中继承载的流量以及网络设备承载的用户量。

    转化被进一步阐释为资源的使用情况,系统平均负载是CPU的Load 即workload,它所包含的信息不是CPU的使用率状况,而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息。

    了解了负载,那么负载均衡就容易理解了。wiki百科给出的定义是这样的:

    负载均衡(Load balancing)是一种计算机网络技术,用来在多个计算机(计算机集群)、网络连接、CPU、磁盘驱动器或其他资源中分配负载,以达到最佳化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。使用带有负载平衡的多个服务器组件,取代单一的组件,可以通过冗余提高可靠性。负载平衡服务通常是由专用软件和硬件来完成。

    并且,wiki百科自身的系统就使用了负载均衡。

    wikipedia

    每一种技术都有它应用的场景和领域,负载均衡主要解决的是系统性能问题。但是,了解了根源,就可以知道不能够一提到性能问题就非负载均衡莫属,如果负载减少了,可能少一点均衡也可以解决问题,这样的技术例如缓存。

    基于DNS的负载均衡

    基于DNS的负载均衡是负载均衡的最简方法,可以说是穷人的负载均衡。

    DNS会将域名映射为IP地址,反之亦然。所有核心DNS服务器都是集群,用的最多的DNS服务器大概就是BIND了。查询DNS服务器时,推荐使用dig;查询DNS解析时,推荐使用nslookup。 使用DNS缓存可以提高DNS解析的性能。Dig 在mac上的使用示例如下:
    dig 用法

    对于DNS实现的负载均衡非常简单,采用轮转的方式,只要为所要服务的域名增加多个A记录即可。
    例如:

    abel.com. IN A 168.168.168.168 
    
    abel.com. IN A 168.168.168.168 
    
    abel.com. IN A 168.168.168.168 
    
    abel.com. IN A 168.168.168.168

    基于DNS的负载均衡简单,易于调试且容易扩展。缺陷在于它有慢性失忆症,无法将会话信息从一个请求保留到下一个请求。而且,只是对目标服务地址进行了均衡,无法考虑请求处理的负载强度进行均衡,同时容错性较差。

    支持DNS 负载均衡的服务商有AWS Route 53 以及dnspod。

    HTTP 负载均衡

    负载均衡解决的是性能问题,要先了解单个服务器的状况。一般地,nginx 的应答率比Apache 高,所以,有时更换Web 服务器就可以提高性能。

    提高Apache Http的方法有禁用空载模块,禁用DNS查询,采用压缩模块,不使用SymLinksIfOwnerMatch选项,并且在Directory选项中启用FollowSymLinks,等等。

    Nginx本身就是高性能的,但可以通过worker_processes 和worker_cpu_affinity调整来匹配服务器的硬件平台,还可以对压缩进行区分对待,使用其缓存的能力。例如

    Http{
            gzip on;
            gzip_static on;
            gzip_comp_level 2;
            gzip_types application/javascript;
    }

    HTTP的负载均衡相当于7层负载均衡,不论Apache 还是 Nginx 都可以充当HTTP的负载均衡器。

    以基于权重的负载均衡为例,可以配置Nginx把请求更多地分发到高配置的后端服务器上,把相对较少的请求分发到低配服务器。配置的示例如下:


    http{
    upstream sampleapp {
    server 192.168.1.23 weight=2;
    server 192.168.1.24;
    }
    ....
    server{
    listen 80;
    ...
    location / {
    proxy_pass http://myapp;
    }
    }

    Nginx 作为负载均衡工作在7层,可以对做正则规则处理(如针对域名、目录进行分流等) ,配置简单,能ping通就能进行负载功能,可以通过端口检测后端服务器状态,不支持url检测。Nginx 负载均衡抗高并发,采用epoll网络模型处理客户请求,但应用范围受限。

    数据库负载均衡

    数据库负载均衡的一般用法从读写分离开始的,因为一般的应用都是读多写少的缘故吧。将数据库做成主从,主数据用于写操作,从数据库用于读操作,事务一般在主库完成。

    数据库集群是数据库负载均衡的典型方式,集群管理服务器作为负载均衡器,例如mysql cluster。

    更简单的方式是通过Haproxy 来完成负载均衡的调度。

    Haproxy 均衡数据库

    HAProxy能够补充Nginx的一些缺点比如Session的保持,Cookie的引导等工作,支持url检测后端的服务器出问题的检测会有很好的帮助。

    HAProxy拥有更多的负载均衡策略比如:动态加权轮循(Dynamic Round Robin),加权源地址哈希(Weighted Source Hash),加权URL哈希和加权参数哈希(Weighted Parameter Hash)等,单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。

    网络连接的负载均衡

    LVS(IPVS,IP虚拟服务器)是在四层交换上设置Web服务的虚拟IP地址,对客户端是可见的。当客户访问此Web应用时,客户端的Http请求会先被第四层交换机接收到,它将基于第四层交换技术实时检测后台Web服务器的负载,根据设定的算法进行快速交换。常见的算法有轮询、加权、最少连接、随机和响应时间等。

    LVS抗负载能力强,使用IP负载均衡技术,只做分发,所以LVS本身并没有多少流量产生。 LVS的稳定性和可靠性都很好应用范围比较广,可以对所有应用做负载均衡,缺陷是不支持正则处理,不能做动静分离。

    通过LVS+Keepalived构建的LVS集群,LVS负载均衡用户请求到后端服务器,Keepalived的作用是检测web服务器的状态,如果有一台web服务器死机,或工作出现故障,Keepalived将检测到,并将有故障的web服务器从系统中剔除,当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中,这些工作全部自动完成,不需要人工干涉,需要人工做的只是修复故障的web服务器。

    下图是Keepalived的原理图:
    KeepLived 的原理图

    SSL负载均衡

    信任是互联网的基石,出于安全性的考量,服务中往往需要SSL的连接。SSL 有两种认证方式:双向认证 SSL 协议要求服务器和用户双方都有证书;单向认证 SSL 协议不需要客户拥有CA证书。一般Web应用,配置SSL单向认证即可。但部分金融行业用户的应用对接,可能会要求对客户端(相对而言)做身份验证。这时就需要做SSL双向认证。

    SSL 属于应用层的协议,所以只能在 7 层上来做,而 HAProxy 也是支持 SSL 协议的,所以一种方式是只需简单的让 HAProxy 开启 SSL 支持完成对内解密对外加密的处理, 但引入 SSL 处理是有额外的性能开销的(如上面谈到的认证), 所以 一般采用SSL proxy farm, 典型的架构如下:

    SSL 负载均衡

    压力和负载测试

    测试负载的状况,一般要涉及负载或压力测试。

    负载测试是模拟实际软件系统所承受的负载条件的系统负荷,通过不断增加负载载(如逐渐增加模拟用户的数量)或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源等,以检验系统的行为和特性,并发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。

    负载测试更多地体现了一种方法或一种技术。压力测试是在强负载(大数据量、大量并发用户等)下的测试,查看应用系统在峰值使用情况下操作行为,从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间(如24小时以上)的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。

    压力测试可以被看作是负载测试的一种,即高负载下的负载测试,或者说压力测试采用负载测试技术。

    简单地,httperf 或者Apache AB 就可以测量HTTP 服务器的负载性能。

    云服务的负载均衡

    云时代的到来,使负载均衡成了平台级的服务,几乎所有的云服务提供商都提供了负载均衡服务。下面是阿里云的负载均衡基础框架图:

    阿里云的slb

    特别的,qingcloud 的vpc 也是挺有特点的,私有网络 用于主机之间互联,类似于使用交换机(L2 Switch)自组局域网。弹性IP还好,管理路由器就显得很贴心了。

    AWS 的负载均衡还是业界典范,官方给出的示意图如下:
    AWS ELB

    高可用性

    高可用性是负载均衡带来的另一价值, 即负载均衡经常被用于实现故障转移。当一个或多个组件出现故障时,能持续提供服务的这些组件都在持续监控中,当一个组件没有响应,负载均衡器就会发现它,并不再向其发送数据。同样当一个组件重新上线,负载均衡器会重新开始向其发送数据。

    SLA 作为高可用性的指标,一般有3个时间标准:99.9%,99.99%,99.999%. 表示不间断运行的离线时间不超过:

    • 3个9: 8.76 小时
    • 4个9:52.26 小时
    • 5个9:5.26 分钟

    三点两地的灾备方案并不是谁都做的起的,有了云服务就显得不那么苦难了。下面是阿里云给出的容灾示意图,多可用区部署,机房宕机后,仍能正常工作。
    阿里云的容灾示意图

    系统的监控在系统高可用性上作用很大,个人推荐zabbix。

    总体来看, 负载均衡是系统架构和DevOps 中的重要技术,对系统性能影响巨大。当然,如果有更高需求的话,就需要考虑硬件的负载均衡方案了,比如说F5。

    展开全文
  • 负载均衡(汇总)

    万次阅读 2019-09-02 15:44:46
    负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一,它通常是指,将请求/数据【均匀】分摊到多操作单元上执行,负载均衡的关键在于【均匀】。 常见的负载均衡方案 常见互联网分布式架构如上...

    微信搜索:“二十同学” 公众号,欢迎关注一条不一样的成长之路

    一分钟了解负载均衡的一切

    什么是负载均衡

    负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一,它通常是指,将请求/数据【均匀】分摊到多个操作单元上执行,负载均衡的关键在于【均匀】。

     

    常见的负载均衡方案


    常见互联网分布式架构如上,分为客户端层、反向代理nginx层、站点层、服务层、数据层。可以看到,每一个下游都有多个上游调用,只需要做到,每一个上游都均匀访问每一个下游,就能实现“将请求/数据【均匀】分摊到多个操作单元上执行”。

     

    【客户端层->反向代理层】的负载均衡


    【客户端层】到【反向代理层】的负载均衡,是通过“DNS轮询”实现的:DNS-server对于一个域名配置了多个解析ip,每次DNS解析请求来访问DNS-server,会轮询返回这些ip,保证每个ip的解析概率是相同的。这些ip就是nginx的外网ip,以做到每台nginx的请求分配也是均衡的。

     

    【反向代理层->站点层】的负载均衡


    【反向代理层】到【站点层】的负载均衡,是通过“nginx”实现的。通过修改nginx.conf,可以实现多种负载均衡策略:

    1)请求轮询:和DNS轮询类似,请求依次路由到各个web-server

    2)最少连接路由:哪个web-server的连接少,路由到哪个web-server

    3)ip哈希:按照访问用户的ip哈希值来路由web-server,只要用户的ip分布是均匀的,请求理论上也是均匀的,ip哈希均衡方法可以做到,同一个用户的请求固定落到同一台web-server上,此策略适合有状态服务,例如session(58沈剑备注:可以这么做,但强烈不建议这么做,站点层无状态是分布式架构设计的基本原则之一,session最好放到数据层存储)

    4)…

     

    【站点层->服务层】的负载均衡


    【站点层】到【服务层】的负载均衡,是通过“服务连接池”实现的。

    上游连接池会建立与下游服务多个连接,每次请求会“随机”选取连接来访问下游服务。

    【数据层】的负载均衡

    在数据量很大的情况下,由于数据层(db,cache)涉及数据的水平切分,所以数据层的负载均衡更为复杂一些,它分为“数据的均衡”,与“请求的均衡”。

    数据的均衡是指:水平切分后的每个服务(db,cache),数据量是差不多的。

    请求的均衡是指:水平切分后的每个服务(db,cache),请求量是差不多的。

    业内常见的水平切分方式有这么几种:

    一、按照range水平切分


    每一个数据服务,存储一定范围的数据,上图为例:

    user0服务,存储uid范围1-1kw

    user1服务,存储uid范围1kw-2kw

    这个方案的好处是:

    (1)规则简单,service只需判断一下uid范围就能路由到对应的存储服务

    (2)数据均衡性较好

    (3)比较容易扩展,可以随时加一个uid[2kw,3kw]的数据服务

    不足是:

    (1)请求的负载不一定均衡,一般来说,新注册的用户会比老用户更活跃,大range的服务请求压力会更大

     

    二、按照id哈希水平切分


    每一个数据服务,存储某个key值hash后的部分数据,上图为例:

    user0服务,存储偶数uid数据

    user1服务,存储奇数uid数据

    这个方案的好处是:

    (1)规则简单,service只需对uid进行hash能路由到对应的存储服务

    (2)数据均衡性较好

    (3)请求均匀性较好

    不足是:

    (1)不容易扩展,扩展一个数据服务,hash方法改变时候,可能需要进行数据迁移

     

    总结

    负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一,它通常是指,将请求/数据【均匀】分摊到多个操作单元上执行,负载均衡的关键在于【均匀】。

    (1)【客户端层】到【反向代理层】的负载均衡,是通过“DNS轮询”实现的

    (2)【反向代理层】到【站点层】的负载均衡,是通过“nginx”实现的

    (3)【站点层】到【服务层】的负载均衡,是通过“服务连接池”实现的

    (4)【数据层】的负载均衡,要考虑“数据的均衡”与“请求的均衡”两个点,常见的方式有“按照范围水平切分”与“hash水平切分”

     

    lvs为何不能完全替代DNS轮询

    对于接入层负载均衡技术,部分同学持这样的观点:

    1)nginx前端加入lvs和keepalived可以替代“DNS轮询”

    2)F5能搞定接入层高可用、扩展性、负载均衡,可以替代“DNS轮询”

    “DNS轮询”究竟是不是过时的技术,是不是可以被其他方案替代???”

    一、问题域

    nginx、lvs、keepalived、f5、DNS轮询,每每提到这些技术,往往讨论的是接入层的这样几个问题:

    1)可用性:任何一台机器挂了,服务受不受影响

    2)扩展性:能否通过增加机器,扩充系统的性能

    3)反向代理+负载均衡:请求是否均匀分摊到后端的操作单元执行

     

    二、上面那些名词都是干嘛的

    由于每个技术人的背景和知识域不同,上面那些名词缩写(运维的同学再熟悉不过了),还是花1分钟简单说明一下:

    1)nginx:一个高性能的web-server和实施反向代理的软件

    2)lvs:Linux Virtual Server,使用集群技术,实现在linux操作系统层面的一个高性能、高可用、负载均衡服务器

    3)keepalived:一款用来检测服务状态存活性的软件,常用来做高可用

    4)f5:一个高性能、高可用、负载均衡的硬件设备(听上去和lvs功能差不多?)

    5)DNS轮询:通过在DNS-server上对一个域名设置多个ip解析,来扩充web-server性能及实施负载均衡的技术

     

    三、接入层技术演进

    【裸奔时代(0)单机架构】


    裸奔时代的架构图如上:

    1)浏览器通过DNS-server,域名解析到ip

    2)浏览器通过ip访问web-server

    缺点

    1)非高可用,web-server挂了整个系统就挂了

    2)扩展性差,当吞吐量达到web-server上限时,无法扩容

    注:单机不涉及负载均衡的问题

     

    【简易扩容方案(1)DNS轮询】

    假设tomcat的吞吐量是1000次每秒,当系统总吞吐量达到3000时,如何扩容是首先要解决的问题,DNS轮询是一个很容易想到的方案:


    此时的架构图如上:

    1)多部署几份web-server,1个tomcat抗1000,部署3个tomcat就能抗3000

    2)在DNS-server层面,域名每次解析到不同的ip

    优点

    1)零成本:在DNS-server上多配几个ip即可,功能也不收费

    2)部署简单:多部署几个web-server即可,原系统架构不需要做任何改造

    3)负载均衡:变成了多机,但负载基本是均衡的

    缺点

    1)非高可用:DNS-server只负责域名解析ip,这个ip对应的服务是否可用,DNS-server是不保证的,假设有一个web-server挂了,部分服务会受到影响

    2)扩容非实时:DNS解析有一个生效周期

    3)暴露了太多的外网ip

     

    【简易扩容方案(2)nginx】

    tomcat的性能较差,但nginx作为反向代理的性能就强多了,假设线上跑到1w,就比tomcat高了10倍,可以利用这个特性来做扩容:


    此时的架构图如上:

    1)站点层与浏览器层之间加入了一个反向代理层,利用高性能的nginx来做反向代理

    2)nginx将http请求分发给后端多个web-server

    优点

    1)DNS-server不需要动

    2)负载均衡:通过nginx来保证

    3)只暴露一个外网ip,nginx->tomcat之间使用内网访问

    4)扩容实时:nginx内部可控,随时增加web-server随时实时扩容

    5)能够保证站点层的可用性:任何一台tomcat挂了,nginx可以将流量迁移到其他tomcat

    缺点

    1)时延增加+架构更复杂了:中间多加了一个反向代理层

    2)反向代理层成了单点,非高可用:tomcat挂了不影响服务,nginx挂了怎么办?

     

    【高可用方案(3)keepalived】

    为了解决高可用的问题,keepalived出场了:


    此时:

    1)做两台nginx组成一个集群,分别部署上keepalived,设置成相同的虚IP,保证nginx的高可用

    2)当一台nginx挂了,keepalived能够探测到,并将流量自动迁移到另一台nginx上,整个过程对调用方透明


    优点

    1)解决了高可用的问题

    缺点

    1)资源利用率只有50%

    2)nginx仍然是接入单点,如果接入吞吐量超过的nginx的性能上限怎么办,例如qps达到了50000咧?

     

    【scale up扩容方案(4)lvs/f5】

    nginx毕竟是软件,性能比tomcat好,但总有个上限,超出了上限,还是扛不住。

    lvs就不一样了,它实施在操作系统层面;f5的性能又更好了,它实施在硬件层面;它们性能比nginx好很多,例如每秒可以抗10w,这样可以利用他们来扩容,常见的架构图如下:


    此时:

    1)如果通过nginx可以扩展多个tomcat一样,可以通过lvs来扩展多个nginx

    2)通过keepalived+VIP的方案可以保证可用性

    99.9999%的公司到这一步基本就能解决接入层高可用、扩展性、负载均衡的问题。

     

    这就完美了嘛?还有潜在问题么?

    好吧,不管是使用lvs还是f5,这些都是scale up的方案,根本上,lvs/f5还是会有性能上限,假设每秒能处理10w的请求,一天也只能处理80亿的请求(10w秒吞吐量*8w秒),那万一系统的日PV超过80亿怎么办呢?(好吧,没几个公司要考虑这个问题)

     

    【scale out扩容方案(5)DNS轮询】

    如之前文章所述,水平扩展,才是解决性能问题的根本方案,能够通过加机器扩充性能的方案才具备最好的扩展性。

    facebook,google,baidu的PV是不是超过80亿呢,它们的域名只对应一个ip么,终点又是起点,还是得通过DNS轮询来进行扩容


    此时:

    1)通过DNS轮询来线性扩展入口lvs层的性能

    2)通过keepalived来保证高可用

    3)通过lvs来扩展多个nginx

    4)通过nginx来做负载均衡,业务七层路由

     

    四、结论

    聊了这么多,稍微做一个简要的总结:

    1)接入层架构要考虑的问题域为:高可用、扩展性、反向代理+扩展均衡

    2)nginx、keepalived、lvs、f5可以很好的解决高可用、扩展性、反向代理+扩展均衡的问题

    3)水平扩展scale out是解决扩展性问题的根本方案,DNS轮询是不能完全被nginx/lvs/f5所替代的

     

    末了,上一篇文章有同学留言问58到家采用什么方案,58到家目前部署在阿里云上,前端购买了SLB服务(可以先粗暴的认为是一个lvs+keepalived的高可用负载均衡服务),后端是nginx+tomcat。

     

    五、挖坑

    接入层讲了这么多,下一章,准备讲讲服务层“异构服务的负载均”(牛逼的机器应该分配更多的流量,如何做到?)。

     

    如何实施异构服务器的负载均衡及过载保护?

    “负载均衡是指,将请求/数据【均匀】分摊到多个操作单元上执行,负载均衡的关键在于【均匀】”。

    然而,后端的service有可能部署在硬件条件不同的服务器上

    1)如果对标最低配的服务器“均匀”分摊负载,高配的服务器的利用率不足;

    2)如果对标最高配的服务器“均匀”分摊负载,低配的服务器可能会扛不住;

    能否根据异构服务器的处理能力来动态、自适应进行负载均衡及过载保护,是本文要讨论的问题。

     

    一、service层的负载均衡通常是怎么做的


    service层的负载均衡,一般是通过service连接池来实现的,调用方连接池会建立与下游服务多个连接,每次请求“随机”获取连接,来保证service访问的均衡性。

    负载均衡、故障转移、超时处理等细节也都是通过调用方连接池来实现的。

    这个调用方连接池能否实现,根据service的处理能力,动态+自适应的进行负载调度呢?

     

    二、通过“静态权重”标识service的处理能力


    调用方通过连接池组件访问下游service,通常采用“随机”的方式返回连接,以保证下游service访问的均衡性。

     

    要打破这个随机性,最容易想到的方法,只要为每个下游service设置一个“权重”,代表service的处理能力,来调整访问到每个service的概率,例如:

    假设service-ip1,service-ip2,service-ip3的处理能力相同,可以设置weight1=1,weight2=1,weight3=1,这样三个service连接被获取到的概率分别就是1/3,1/3,1/3,能够保证均衡访问。

     

    假设service-ip1的处理能力是service-ip2,service-ip3的处理能力的2倍,可以设置weight1=2,weight2=1,weight3=1,这样三个service连接被获取到的概率分别就是2/4,1/4,1/4,能够保证处理能力强的service分别到等比的流量,不至于资源浪费。

     

    使用nginx做反向代理与负载均衡,就有类似的机制。

    这个方案的优点是:简单,能够快速的实现异构服务器的负载均衡。

    缺点也很明显:这个权重是固定的,无法自适应动态调整,而很多时候,服务器的处理能力是很难用一个固定的数值量化。

     

    三、通过“动态权重”标识service的处理能力

    提问:通过什么来标识一个service的处理能力呢?

    回答:其实一个service能不能处理得过来,能不能响应得过来,应该由调用方说了算。调用服务,快速处理了,处理能力跟得上;调用服务,处理超时了,处理能力很有可能跟不上了。

     

    动态权重设计

    1)用一个动态权重来标识每个service的处理能力,默认初始处理能力相同,即分配给每个service的概率相等;

    2)每当service成功处理一个请求,认为service处理能力足够,权重动态+1

    3)每当service超时处理一个请求,认为service处理能力可能要跟不上了,权重动态-10(权重下降会更快)

    4)为了方便权重的处理,可以把权重的范围限定为[0, 100],把权重的初始值设为60分

    举例说明:

    假设service-ip1,service-ip2,service-ip3的动态权重初始值weight1=weight2=weight3=60,刚开始时,请求分配给这3台service的概率分别是60/180,60/180,60/180,即负载是均衡的。

    随着时间的推移,处理能力强的service成功处理的请求越来越多,处理能力弱的service偶尔有超时,随着动态权重的增减,权重可能变化成了weight1=100,weight2=60,weight3=40,那么此时,请求分配给这3台service的概率分别是100/200,60/200,40/200,即处理能力强的service会被分配到更多的流量。

     

    四、过载保护

    提问:什么是过载保护?

    互联网软件架构设计中所指的过载保护,是指当系统负载超过一个service的处理能力时,如果service不进行自我保护,可能导致对外呈现处理能力为0,且不能自动恢复的现象。而service的过载保护,是指即使系统负载超过一个service的处理能力,service让能保证对外提供有损的稳定服务。

    提问:如何进行过载保护?

    回答:最简易的方式,服务端设定一个负载阈值,超过这个阈值的请求压过来,全部抛弃。这个方式不是特别优雅。

     

    五、如何借助“动态权重”来实施过载保护

    动态权重是用来标识每个service的处理能力的一个值,它是RPC-client客户端连接池层面的一个东东。服务端处理超时,客户端RPC-client连接池都能够知道,这里只要实施一些策略,就能够对“疑似过载”的服务器进行降压,而不用服务器“抛弃请求”这么粗暴的实施过载保护。

    应该实施一些什么样的策略呢,例如:

    1)如果某一个service的连接上,连续3个请求都超时,即连续-10分三次,客户端就可以认为,服务器慢慢的要处理不过来了,得给这个service缓一小口气,于是设定策略:接下来的若干时间内,例如1秒(或者接下来的若干个请求),请求不再分配给这个service;

    2)如果某一个service的动态权重,降为了0(像连续10个请求超时,中间休息了3次还超时),客户端就可以认为,服务器完全处理不过来了,得给这个service喘一大口气,于是设定策略:接下来的若干时间内,例如1分钟(为什么是1分钟,根据经验,此时service一般在发生fullGC,差不多1分钟能回过神来),请求不再分配给这个service;

    3)可以有更复杂的保护策略…

    这样的话,不但能借助“动态权重”来实施动态自适应的异构服务器负载均衡,还能在客户端层面更优雅的实施过载保护,在某个下游service快要响应不过来的时候,给其喘息的机会。

    需要注意的是:要防止客户端的过载保护引起service的雪崩,如果“整体负载”已经超过了“service集群”的处理能力,怎么转移请求也是处理不过来的,还得通过抛弃请求来实施自我保护。

    六、总结

    1)service的负载均衡、故障转移、超时处理通常是RPC-client连接池层面来实施的

    2)异构服务器负载均衡,最简单的方式是静态权重法,缺点是无法自适应动态调整

    3)动态权重法,可以动态的根据service的处理能力来分配负载,需要有连接池层面的微小改动

    4)过载保护,是在负载过高时,service为了保护自己,保证一定处理能力的一种自救方法

    5)动态权重法,还可以用做service的过载保护

     

    单点系统架构的可用性与性能优化

    一、需求缘起

    明明架构要求高可用,为何系统中还会存在单点?

    回答:单点master的设计,会大大简化系统设计,何况有时候避免不了单点

     

    在哪些场景中会存在单点?先来看一下一个典型互联网高可用架构。


    典型互联网高可用架构:

    (1)客户端层,这一层是浏览器或者APP,第一步先访问DNS-server,由域名拿到nginx的外网IP

    (2)负载均衡层,nginx是整个服务端的入口,负责反向代理与负载均衡工作

    (3)站点层,web-server层,典型的是tomcat或者apache

    (4)服务层,service层,典型的是dubbo或者thrift等提供RPC调用的后端服务

    (5)数据层,包含cache和db,典型的是主从复制读写分离的db架构

    在这个互联网架构中,站点层、服务层、数据库的从库都可以通过冗余的方式来保证高可用,但至少

    (1)nginx层是一个潜在的单点

    (2)数据库写库master也是一个潜在的单点

     

    再举一个GFS(Google File System)架构的例子。


    GFS的系统架构里主要有这么几种角色:

    (1)client,就是发起文件读写的调用端

    (2)master,这是一个单点服务,它有全局事业,掌握文件元信息

    (3)chunk-server,实际存储文件额服务器

    这个系统里,master也是一个单点的服务,Map-reduce系统里也有类似的全局协调的master单点角色。

     

    系统架构设计中,像nginx,db-master,gfs-master这样的单点服务,会存在什么问题,有什么方案来优化呢,这是本文要讨论的问题。

     

    二、单点架构存在的问题

    单点系统一般来说存在两个很大的问题:

    (1)非高可用:既然是单点,master一旦发生故障,服务就会受到影响

    (2)性能瓶颈:既然是单点,不具备良好的扩展性,服务性能总有一个上限,这个单点的性能上限往往就是整个系统的性能上限

    接下来,就看看有什么优化手段可以优化上面提到的两个问题

    三、shadow-master解决单点高可用问题

    shadow-master是一种很常见的解决单点高可用问题的技术方案。

    “影子master”,顾名思义,服务正常时,它只是单点master的一个影子,在master出现故障时,shadow-master会自动变成master,继续提供服务。

    shadow-master它能够解决高可用的问题,并且故障的转移是自动的,不需要人工介入,但不足是它使服务资源的利用率降为了50%,业内经常使用keepalived+vip的方式实现这类单点的高可用

     


    以GFS的master为例,master正常时:

    (1)client会连接正常的master,shadow-master不对外提供服务

    (2)master与shadow-master之间有一种存活探测机制

    (3)master与shadow-master有相同的虚IP(virtual-IP)

     


    当发现master异常时:

    shadow-master会自动顶上成为master,虚IP机制可以保证这个过程对调用方是透明的

     

    除了GFS与MapReduce系统中的主控master,nginx亦可用类似的方式保证高可用,数据库的主库master(主库)亦可用类似的方式来保证高可用,只是细节上有些地方要注意:


    传统的一主多从,读写分离的db架构,只能保证读库的高可用,是无法保证写库的高可用的,要想保证写库的高可用,也可以使用上述的shadow-master机制:


    (1)两个主库设置相互同步的双主模式

    (2)平时只有一个主库提供服务,言下之意,shadow-master不会往master同步数据

    (3)异常时,虚IP漂移到另一个主库,shadow-master变成主库继续提供服务

    需要说明的是,由于数据库的特殊性,数据同步需要时延,如果数据还没有同步完成,流量就切到了shadow-master,可能引起小部分数据的不一致。

     

    四、减少与单点的交互,是存在单点的系统优化的核心方向

    既然知道单点存在性能上限,单点的性能(例如GFS中的master)有可能成为系统的瓶颈,那么,减少与单点的交互,便成了存在单点的系统优化的核心方向。

    怎么来减少与单点的交互,这里提两种常见的方法。

    批量写

    批量写是一种常见的提升单点性能的方式。

    例如一个利用数据库写单点生成做“ID生成器”的例子:


    (1)业务方需要ID

    (2)利用数据库写单点的auto increament id来生成和返回ID

    这是一个很常见的例子,很多公司也就是这么生成ID的,它利用了数据库写单点的特性,方便快捷,无额外开发成本,是一个非常帅气的方案。

    潜在的问题是:生成ID的并发上限,取决于单点数据库的写性能上限。

    如何提升性能呢?批量写

     


    (1)中间加一个服务,每次从数据库拿出100个id

    (2)业务方需要ID

    (3)服务直接返回100个id中的1个,100个分配完,再访问数据库

    这样一来,每分配100个才会写数据库一次,分配id的性能可以认为提升了100倍。

     

    客户端缓存

    客户端缓存也是一种降低与单点交互次数,提升系统整体性能的方法。

    还是以GFS文件系统为例:


    (1)GFS的调用客户端client要访问shenjian.txt,先查询本地缓存,miss了

    (2)client访问master问说文件在哪里,master告诉client在chunk3上

    (3)client把shenjian.txt存放在chunk3上记录到本地的缓存,然后进行文件的读写操作

    (4)未来client要访问文件,从本地缓存中查找到对应的记录,就不用再请求master了,可以直接访问chunk-server。如果文件发生了转移,chunk3返回client说“文件不在我这儿了”,client再访问master,询问文件所在的服务器。

     

    根据经验,这类缓存的命中非常非常高,可能在99.9%以上(因为文件的自动迁移是小概率事件),这样与master的交互次数就降低了1000倍。

     

    五、水平扩展是提升单点系统性能的好方案

    无论怎么批量写,客户端缓存,单点毕竟是单机,还是有性能上限的。

    想方设法水平扩展,消除系统单点,理论上才能够无限的提升系统系统。

    以nginx为例,如何来进行水平扩展呢?


    第一步的DNS解析,只能返回一个nginx外网IP么?答案显然是否定的,“DNS轮询”技术支持DNS-server返回不同的nginx外网IP,这样就能实现nginx负载均衡层的水平扩展。

     


    DNS-server部分,一个域名可以配置多个IP,每次DNS解析请求,轮询返回不同的IP,就能实现nginx的水平扩展,扩充负载均衡层的整体性能。

     

    数据库单点写库也是同样的道理,在数据量很大的情况下,可以通过水平拆分,来提升写入性能。

     

    遗憾的是,并不是所有的业务场景都可以水平拆分,例如秒杀业务,商品的条数可能不多,数据库的数据量不大,就不能通过水平拆分来提升秒杀系统的整体写性能(总不能一个库100条记录吧?)。

     

    六、总结

    今天的话题就讨论到这里,内容很多,占用大家宝贵的时间深表内疚,估计大部分都记不住,至少记住这几个点吧:

    (1)单点系统存在的问题:可用性问题,性能瓶颈问题

    (2)shadow-master是一种常见的解决单点系统可用性问题的方案

    (3)减少与单点的交互,是存在单点的系统优化的核心方向,常见方法有批量写,客户端缓存

    (4)水平扩展也是提升单点系统性能的好方案

    集群信息管理,架构设计中最容易遗漏的一环

    • 是什么

    • 什么场景,为什么会用到,存在什么问题

    • 常见方案及痛点

    • 不同阶段公司,不同实现方案

    一、啥是集群?

    互联网典型分层架构如下:

    • web-server层

    • service层

    • db层与cache层

     

    为了保证高可用,每一个站点、服务、数据库、缓存都会冗余多个实例,组成一个分布式的系统,集群则是一个分布式的物理形态。

     

    额,好拗口,通俗的说,集群就是一堆机器,上面部署了提供相似功能的站点,服务,数据库,或者缓存。

    如上图:

    • web集群,由web.1和web.2两个实例组成

    • service集群,由service.1/service.2/service.3三个实例组成

    • db集群,由mysql-M/mysql-S1/mysql-S2三个实例组成

    • cache集群,由cache-M/cache-S两个实例组成

     

    与“集群”相对应的是“单机”。

    画外音:关于高可用架构,详见文章《究竟啥才是互联网架构“高可用”》。

    画外音:缓存如果没有高可用要求,可能是单机架构,而不是集群。

     

    二、集群信息

    什么是集群信息?

    一个集群,会包含若干信息(额,这tm算什么解释),例如:

    • 集群名称

    • IP列表

    • 二进制目录

    • 配置目录

    • 日志目录

    • 负责人列表

    画外音:集群IP列表不建议直接使用IP,而建议使用内网域名,详见文章《小小的IP,大大的耦合》。

     

    什么时候会用到集群信息呢?

    很多场景,特别是线上操作,都会使用到各种集群信息,例如:

    • 自动化上线

    • 监控

    • 日志清理

    • 二进制与配置的备份

    • 下游的调用(额,这个最典型)

     

    这些场景,分别都是如何读取集群信息的?

    一般来说,早期会把集群信息写在配置文件里。

     

    例如,自动化上线,有一个配置文件,deploy.user.service.config,其内容是:

    name : user.service

    ip.list : ip1, ip2, ip3

    bin.path : /user.service/bin/

    ftp.path : ftp://192.168.0.1/USER_2_0_1_3/user.exe

     

    自动化上线的过程,则是:

    • 把可执行文件从ftp拉下来

    • 读取集群IP列表

    • 读取二进制应该部署的目录

    • 把二进制部署到线上

    • 逐台重启

    画外音:啥,还没有实现自动化脚本部署?还处在运维ssh到线上,手动执行命令,逐台机器人肉部署的刀耕火种阶段?赶紧照着这个方案,做自动化改造吧。

    又例如,web-X调用下游的user服务,又有一个配置文件,web-X.config,其内容配置了:

    service.name : user.service

    service.ip.list : ip1, ip2, ip3

    service.port : 8080

    web-X调用user服务的过程,则是:

    • web-X启动

    • web-X读取user服务集群的IP列表与端口

    • web-X初始化user服务连接池

    • web-X拿取user服务的连接,通过RPC接口调用user服务

    日志清理,服务监控,二进制备份的过程,也都与上述类似。

    三、存在什么问题?

    上述业务场景,对于集群信息的使用,有两个最大的特点

    • 每个应用场景,所需集群信息都不一样(A场景需要集群abc信息,B场景需要集群def信息)

    • 每个应用场景,集群信息都写在“自己”的配置文件里

    一句话总结:集群信息管理分散化。

    这里最大的问题,是耦合,当集群的信息发生变化的时候,有非常多的配置需要修改:

    • deploy.user.service.config

    • clean.log.user.service.config

    • backup.bin.user.service.config

    • monitor.config

    • web-X.config

    这些配置里,user服务集群的信息都需要修改:

    • 随着研发、测试、运维人员的流动,很多配置放在哪里,逐步就被遗忘了

    • 随着时间的推移,一些配置就被改漏了

    • 逐渐的,莫名其妙的问题出现了

    画外音:ca,谁痛谁知道

    如何解决上述耦合的问题呢?

    一句话回答:集群信息管理集中化。

    四、如何集中化管理集群信息

    如何集中化管理集群配置信息,不同发展阶段的公司,实现的方式不一样。

     

    早期方案

    通过全局配置文件,实现集群信息集中管理,举例global.config如下:

    [user.service]

    ip.list : ip1, ip2, ip3

    port : 8080

    bin.path : /user.service/bin/

    log.path : /user.service/log/

    conf.path : /user.service/conf/

    ftp.path :ftp://192.168.0.1/USER_2_0_1_3/user.exe

    owner.list : shenjian, zhangsan, lisi

     

    [passport.web]

    ip.list : ip11, ip22, ip33

    port : 80

    bin.path : /passport.web/bin/

    log.path : /passport.web/log/

    conf.path : /passport.web/conf/

    ftp.path :ftp://192.168.0.1/PST_1_2_3_4/passport.jar

    owner.list : shenjian, zui, shuaiqi

     

    集中维护集群信息之后:

    • 任何需要读取集群信息的场景,都从global.config里读取

    • 任何集群信息的修改,只需要修改global.config一处

    • global.config会部署到任何一台线上机器,维护和管理也很方便

    画外音:额,当然,信息太多的话,global.config也要垂直拆分

     

    中期方案

    随着公司业务的发展,随着技术团队的扩充,随着技术体系的完善,通过集群信息管理服务,来维护集群信息的诉求原来越强烈。

    画外音:慢慢的,配置太多了,通过global.config来修改配置太容易出错了

    如上图,建立集群信息管理服务

    • info.db :存储集群信息

    • info.cache :缓存集群信息

    • info.service :提供集群信息访问的RPC接口,以及HTTP接口

    • info.web :集群信息维护后台

     

    服务的核心接口是:

    Info InfoService::getInfo(String ClusterName);

    Bool InfoService::setInfo(String ClusterName, String key, String value);

     

    然后,统一通过服务来获取与修改集群信息:

    • 所有需要获取集群信息的场景,都通过info.service提供的接口来读取集群信息

    • 所有需要修改集群信息的场景,都通过info.web来操作

     

    长期方案

    集群信息服务可以解决大部分的耦合问题,但仍然有一个不足:集群信息变更时,无法反向实时通知关注方,集群信息发生了改变。更长远的,要引入配置中心来解决。

    配置中心的细节,网上的分析很多,之前也撰文写过,细节就不再本文展开。

     

    五、总结

    集群信息管理,是架构设计中非常容易遗漏的一环,但又是非常基础,非常重要的基础设施,一定要在早期规划好:

    • 传统的方式,分散化管理集群信息,容易导致耦合

    • 集中管理集群信息,有全局配置,信息服务,配置中心三个阶段

    展开全文
  • Apache负载均衡设置的大策略原则

    千次阅读 2016-11-26 16:40:10
    Apache作为LoadBalance前置机分别有种不同的部署方式,分别是: 1 )轮询均衡策略的配置 进入Apache的conf目录,打开httpd.conf文件,在文件的末尾加入: ProxyPass /balancer://proxy/   #注意这里以"/"结尾 ...
  • ) SpringCloud 实现Ribbon 负载均衡

    千次阅读 2020-07-15 17:16:49
    翻译文章:... ... ... 前言: 上篇文章我们学了如何搭建Eureka 服务注册中心,这节我们结合Ribbo 来实现客户端负载均衡。本文按照上面的翻译文章所写。 首先我们需要了解一下什么是Ribbon? Ribbon 是Netf
  • 很明显通过前面的八篇文章的介绍,并不能覆盖负载均衡层的所有技术,但是可以作为一引子,告诉各位读者一学习和使用负载均衡技术的思路。虽然后面我们将转向“业务层”和“业务通信”层的介绍,但是对负载均衡层...
  • 完整的负载均衡的例子

    千次阅读 2013-08-01 15:07:12
    原理:tomcat 做WEB服务器有它的局限性,处理能力低,效率低。承受并发小(1000左右)。但目前有不少网站或者页面是JSP的。并采用了tomcat做为WEB,因此只能在此基础上调优。 目前采取的办法是Apache + Mod_JK...
  • 二、ribbon负载均衡有几种策略 1、随机策略RandomRule 2、轮询策略RoundRobinRule(默认策略) 3、重试策略RetryRule 4、最低并发策略BestAvailableRule 5、可用过滤策略AvailabilityFilteringRule 6、响应时间加权...
  • 负载均衡

    千次阅读 2011-09-02 10:35:35
    百度百科... 负载均衡 (Outbound Load Balancing) 负载均衡建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高
  • 博弈均衡算法

    千次阅读 2017-08-16 09:55:30
    非合作博弈理论中最基本的均衡概念就是纳什均衡,它只能描述均衡点的局部静态性质;进化博弈理论基本均衡 概念就是进化稳定策略,它是也是一静态概念,但可以描述系统的局部动态性质;进化博弈理论另一重要概
  • 客户端负载均衡(Ribbon)

    万次阅读 多人点赞 2019-01-22 15:04:11
    服务器端负载均衡 客户端负载均衡 Ribbon负载均衡示例搭建 创建服务提供者 引入依赖 添加配置 服务提供者 创建启动类 启动服务 服务消费者 引入Ribbon依赖 添加配置 使用Ribbon客户端 切换Ribbon负载...
  • 【图像处理算法】直方图均衡

    万次阅读 多人点赞 2019-03-26 20:24:54
    数字图像处理(第版) 左飞. 图像处理中的数学修炼 目录 直方图均衡化的介绍 直方图的概念 直方图均衡化的理论基础 手工实现直方图均衡化 MATLAB上实现直方图均衡化 直方图均衡化的缺点 直方图均衡...
  • 全球网络的三个边界

    千次阅读 2012-11-24 11:00:22
    1.IP编址与地理分布-物理与逻辑的边界IP路由的效率和路由器以及主机的地理分布关系重大,地理分布零散带来的后果就是路由表的庞大,因为在这无线核心网络还远未实现的时期,网络的本质就是一根根的线缆连接着的一...
  • Spring Cloud Ribbon是一基于HTTP和TCP的客户端负载均衡工具,它基于Netflix Ribbon实现。通过Spring Cloud的封装,而已让我们将面向服务的REST模板请求自动转换成客户端负载均衡的服务调用。它只是一工具类框架...
  • 负载均衡,会话保持,session同步

    千次阅读 2012-05-18 11:58:53
    一,什么负载均衡新网站是不要做负载均衡的,因为访问量不大,流量也不大,所以没有必要搞这些东西。但是随着网站访问量和流量的快速增长,单台服务器受自身硬件条件的限制,很难承受这么大的访问量。在这种情况...
  • Nginx 负载均衡

    千次阅读 2014-11-13 21:05:04
    1.负载均衡概览;...3.选择一负载均衡方法;4.服务器权值;5.服务器慢启动;6.开启会话持久;7.限制连接数目;8.被动的健康检测;9.主动的健康检测;10.多工作进程共享数据;11.使用DNS配置负载均衡;12.实时重配置
  • Ribbon负载均衡策略详解

    千次阅读 2018-11-07 11:35:54
    目前主流的负载方案分为两种,一种是集中式负载均衡,在消费者和服务提供方中间使用独立的代理方式进行负载,有硬件的,比如F5,也有软件的,比如Nginx。 另一种则是客户端自己做负载均衡,根据自己的请求情况做...
  • Springcloud 负载均衡理解

    万次阅读 热门讨论 2018-07-18 00:19:37
    本来想写私人学习笔记的,但是...负载均衡分为两种,一种是服务端负载均衡,一种是客户端负载均衡。 服务端负载均衡:分为两种,一种是硬件负载均衡,还有一种是软件负载均衡。 硬件负载均衡主要通过在服务器节点...
  • 前提条件:搭建好了docker,(没有的话,就修改tomcat的端口)+我是在服务器上操作的+nginx(我前面的博客都有相关教程)1.用docker的tomcat镜像启动tomcat服务docker run -d -p 8088:8080 tomcat docker run -d -p ...
  • 负载均衡SLB高可用的四层次

    千次阅读 2017-09-06 16:56:28
    摘要: 负载均衡支持对多台ECS进行流量分发,以提升应用系统的服务能力,长期以来都是关键业务系统的入口。淘宝,天猫,阿里云等无不依赖负载均衡产品,双11的流量洪峰也依赖负载均衡的调度和处理能力。 ...
  • RestTemplate的逆袭之路,从发送请求到负载均衡

    万次阅读 多人点赞 2017-09-12 08:35:36
    上篇文章我们详细的介绍了RestTemplate...本文我们就来聊一聊RestTemplate的逆袭之路,看它如何从一普通的请求发送工具变成了具有客户端负载均衡功能的请求发送工具。本文是Spring Cloud系列的第七篇文章,了解前六篇
  • 负载均衡常见架构

    千次阅读 2018-04-19 20:51:31
    转自:https://blog.csdn.net/yinwenjie/article/details/481018693、负载均衡层技术汇总3-4、Keepalived技术Keepalived在我的博客文章《架构设计:负载均衡层设计方案(7)》...负载均衡层设计方案(6)》(...
  • windows 2008 NLB (网络负载均衡

    千次阅读 2012-01-08 15:35:22
    NLB (网络负载均衡)使用 TCP/IP 网络协议在多台服务器中分发流量。可以对终端服务器场使用 NLB 以通过在多台服务器中分发会话来提高单个终端服务器的性能。终端服务会话 Broker(TS 会话 Broker)包含于 Microsoft...
  • apache 负载均衡

    千次阅读 2009-08-15 13:00:00
    随着访问量的不断提高,以及对响应速度的要求,进行负载均衡设置就显得非常必要了。公司的系统在最初设计的时候就...此次就是对负载均衡的一简单测试。 先介绍一下apache mod_proxy_balancer的几配置规则(从网上
  • 6例子让你彻底明白,什么是纳什均衡电影《美丽心灵》的主人公原型——约翰·纳什因车祸去世。你也许听说过他是厉害的数学家、1994 年诺贝尔经济学奖得主、博弈论之父……但是,他的最大贡献是“纳什均衡”。那么...
  • 关于linux内核cpu进程的负载均衡

    千次阅读 2010-02-09 21:51:00
    推这里不考虑,关于拉均衡有一篇文章特别好,具体出处就不记得了,我当时用的百度快照,那篇文章我认为最精彩的部分就是下面摘录的这段话: 当某个 cpu 负载过轻而另一 cpu 负载较重时,系统会从重载 cpu 上"拉...
  • 【OpenCV-Python】 直方图均衡

    千次阅读 2018-04-12 14:27:41
    OpenCV 直方图均衡化 直方图 直方图相关术语 BINS DIMS RANGE OpenCV中直方图的计算 Numpy中直方图的计算 绘制直方图 1. 使用Matplotlib 2. 使用OpenCV 应用遮罩 直方图均衡化 直方图均衡化算法 Numpy中的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 86,323
精华内容 34,529
关键字:

一般均衡的三个条件