压力流量控制如何搭建

2014年12月第2周 1）SLB植入cookie和SLB重写cookie有什么区别？ cookie植入，表示直接由SLB系统来分配和管理对客户端进行的cookie植入操作，用户在进行配置时 需要指定会话保持的超时时间； cookie重写，表示SLB系统会根据用户自定义cookie名称来分配和管理对客户端进行的cookie植入操 作，便于用户识别和区分自定义的cookie名称 http://help.aliyun.com/doc/view/13510025.html?spm=0.0.0.0.vwbsGF 2）SLB有没有对外提供API接口，因为我想做到用程序自动去控制SLB的操作？ SLB api您可以参考http://help.aliyun.com/view/13621674.html? spm=5176.7114037.1996646101.1.9RoTFM&pos=1 3）使用slb怎么实现数据的单向同步和双向同步？ 单向同步可以使用rsync，双向同步的话rsync需要借用别的服务来实现,如unison+inotify。 4）slb的vip是否可以实现远程登录？ slb 的vip无法实现远程登录。 5）slb的带宽是所有后端ECS服务器的带宽总和吗? 不是，使您购买的slb实例带宽。 6）slb健康检查机制是什么？ 用户开启健康检查功能后，当后端某个ECS健康检查出现问题时会将请求转发到其他健康检查正常的 ECS上，而当该ECS恢复正常运行时，SLB会将其自动恢复到对外或对内的服务中。 针对7层（HTTP协议）服务，SLB系统的健康检查机制为：默认通过SLB的后端系统来向该ECS应用服务 器配置的缺省首页发起http head请求（缺省通过在服务监听配置中指定的后端ECS端口进行访问）， 返回200 OK后将视为后端ECS运行正常，否则视为后端ECS运行异常。如果用户用来进行健康检查的页 面并不是应用服务器的缺省首页，那么需要用户指定相应的URI。如果用户对http head请求限定了 host字段的参数，那么需要用户指定相应的URL。用户也可以通过设定健康检查的频率、健康阈值和 不健康阈值来更好的控制健康检查功能。 针对4层（TCP协议）服务，SLB系统的健康检查机制为：默认通过在服务监听配置中指定的后端ECS端 口发起访问请求，如果端口访问正常则视为后端ECS运行正常，否则视为后端ECS运行异常。 当用户后端ECS健康检查异常后，SLB系统会将该ECS的转发权重设置为0，从而确保新的连接不会再被 转发到该ECS上，而已经建立的连接的请求却不会被直接断掉。 针对可能引起健康检查异常的排查思路点击这里查看。 关于健康检查的参数配置，提供如下参考建议： 响应超时时间：5秒 健康检查间隔：2秒 不健康阈值：3 健康阈值：3 7）权重设置为0怎么办？ 权重为0的服务器将无法提供服务。 ８）健康检查异常的排查思路？ 参考http://help.aliyun.com/doc/view/13510029.html?spm=0.0.0.0.Oa9Ezv ------------------------- 12月份第3周1）轮询与最小连接数方式的区别是什么？当前SLB支持轮询和最小连接数2种模式的转发规则。“轮询模式”会将外部和内部的访问请求依序分发给后端ECS进行处理，而“最小连接数模式”会将外部和内部的访问请求分发给当前连接数最小的一台后端ECS进行处理。2）SLB支持redis的主备？目前我们的SLB不支持主备模式（冷备），只支持"轮询"和"最小连接数"两种负载模式。关于SLB的原理您可以参阅如下博文：http://blog.aliyun.com/149 基于ECS的redis搭建，您可以参阅论坛中其它用户的分享案例：http://bbs.aliyun.com/read/161389.html3）负载均衡的多台服务器之间文件会不会自动同步？slb是不会自动同步的，需要您自行配置。4）四层和七层检查的区别是什么？如果是4层（TCP）配置，健康检查只是简单的TCP握手，不会真正去访问您的业务。但对于7层（HTTP）配置，会发HTTP请求（类似于正常访问），并根据返回状态码判断服务状态（2XX表示服务正常）。5）我有多个slb，之前一个slb由于被攻击被黑洞给屏蔽了外部请求，是否可以在slb 并屏蔽后 能够自动将请求分发到另外的slb？由于攻击导致屏蔽外部请求的话，slb没有自动切换的方法的。6）目前slb是否可以设置黑名单?暂不支持。7）我的slb实例控制台显示是停止，为什么？需要给监听的端口设置带宽才能正常。  8）我使用了 SLB那么ESC 需要购买带宽吗？不需要的。但如需要管理ECS，则可购买少些的带宽如1M来管理。9）slb变更计费方式需要多久才能生效？变更和计费将在第二日零点后生效。10）私网SLB的使用，是如何收费的呢？私网slb是不收取费用的。 ------------------------- 12月第4周1）最近用slb后打开网页老出现503 和504错误？一般都是从ECS获取站点信息等异常导致的。您首先先确保源站都可以正常的访问。2）slb检查时突然发现SLB监听错误，怎么回事？配置的健康检查的域名为空，检查的路径是/index.html，目前查看服务器中只有站点c绑定了空主机头，且站点目录下有index.html，而此站点是停止状态，现已帮您启用，查看服务器的健康检查状态已经正常。3）我想使用slb搭建一个负载均衡，后端使用windows服务器，想咨询一下后端服务器是否需要进行什么特别配置呢？另外使用了slb后，后端还能否得到用户的真实IP地址呢，要不要进行什么特殊配置才可以得到后端用户的真实IP。后端服务器的操作系统和web环境最好保持一致，硬件配置上没有什么特别的，4层tcp是可以直接获得前端用户访问的真实地址的，7层http需要在后端web服务端设置一下，参考http://help.aliyun.com/view/13502961.html?spm=5176.7114037.1996646101.1.oRpnOM&pos=14）slb支持https吗？slb您可以通过TCP协议配置443端口的方式来实现，但是安全证书需要保存在您的后端ECS上。5）健康检查后续是否提供多个域名？健康检查只支持一个域名。6）我想关闭负载均衡的健康检查，请问如何配置？4层tcp是无法关闭健康检查的，7层http可以在控制台关闭。健康检查是不会消耗您服务器的资源的，因为slb都是通过内网ip来进行健康检查。7）如何在BLS上 限制单个IP 禁止访问 我的网站呢？SLB暂时不支持设置屏蔽用户端IP。 ------------------------- Re:Re负载均衡SLB常见咨询问题（持续连载） 引用第2楼517449116于2014-12-17 15:54发表的 Re负载均衡SLB常见咨询问题（持续连载） : 如果开启健康检查，健康检查异常的话，是不是就不会给这个异常的ECS分发？ [url=http://bbs.aliyun.com/job.php?action=topost&tid=188736&pid=596806][/url] 异常的话不会在分发。 ------------------------- 2015年1月第1周1）有2台ECS起名叫A和B做SLB，A权重设的100 B权重设的0.请问.当A死机时,SLB是否会转到权重是0的B上?如果有一台设置为0，永远都不会有请求转发到此服务器上，即使权重100的宕机也不会转发到0权重的。2）会话保持的选择？开启会话保持功能后，SLB会把来自同一客户端的访问请求分发到同一台后端ECS上进行处理。针对7层（HTTP协议）服务，SLB系统是基于cookie的会话保持。针对4层（TCP协议）服务，SLB系统是基于IP地址的会话保持。3）用nagios或zabbix监控网络带宽，是否可以监控 slb的流量？nagios或zabbix，cacti是要要被监控端安装snmp或者相关agent ，slb不支持安装这些，所以无法通过这条监控软件进行监控。您可以在slb的控制台里面进行查看流量等相关信息。4）用了负载均衡后升级带宽，是不是只用在负载上面升级就可以了，ECS是不是不用在升级了？SLB与后端服务器是经过内网通信，所以如果业务量增加，您对SLB的带宽调整就行，不需要对服务器ECS进行带宽的升级。 ------------------------- 2015年1月第2周 1）SLB到期之后，会对SLB有关联的云主机怎么处理？云主机还没到期的前提下  我想把网站域名解析到SLB上 如果SLB到期了 会影响到我的网站服务么？ 云服务器是不会有什么影响的，会自动又变成单独的云服务器可以供您使用的。但是如果您的域名是解析到SLB上，那么会影响到您的站点访问的。服务器上不会有其他的问题感谢您的支持。 2)当SLB 状态为停止的时候 还计算费用吗？停止后公网slb会收取实例费用。SLB价格总览参考：http://help.aliyun.com/view/11108234_13502923.html?spm=0.0.0.0.kBLsVA 3)做了SLB负载均衡，四层和7层负载均衡是否都走slb带宽？ 都走slb带宽。 4)我想 移除 slb下的ecs（用作其他用途），请问在移除的时候是否会影响被负载到这台 ecs上的服务的使用 ，也是说slb这是是怎么处理的？ 您可以将要移除的主机的权重更改为0 ，这样默认就不会在分发到权重为0的主机上，这个时候您可以移除该主机。但要确保您的另外一台服务器可以承受所有的访问。 5)SLB实例如何释放? 您需要登录管理控制台点击负载均衡。查询您之前创建的实例在哪个节点下，然后释放您的实例。 6)SLB按照小时的带宽计费， 是否需要每小时调整？比如我可否按照一个比较高的上限， 比如3G,然后每个小时按照该小时的峰值进行独立计费呢？   在一个自然日内，限制用户变更计费方式的次数为1次，变更计费方式将在第二日零点后生效；比如用户在今天5月5日的10:00提交了变更计费方式，那么该变配申请将在明天5月6日00:00后生效。http://help.aliyun.com/view/13502923.html?spm=5176.7114037.1996646101.3.67L5dm&pos=2;SLB目前最大带宽是1000Mbps 7）SLB可以限制每个ip的访问频率吗?(工单1F684MN)slb不支持这样配置的。 8）为什么我设置SLB健康检查间隔为5S，但却每秒都有很多请求？因为用于健康检查的服务ip不止一个，每秒中都会有不同的内网ip进行健康检查，健康检查是通过内网方式，不会消耗您后端服务器的资源，您可以将健康检查间隔阈值跳大些，这样监测频率会降低很多。 ------------------------- Re:负载均衡SLB常见咨询问题（持续连载至2015年1月第3周） 2015年1月第3周 1.发现很多100.97.0.0/16 的ip段扫描，给我服务器带来很大压力，怎么办？ 100.97.0.0/16 是我们slb的健康检查服务ip段，如果给服务器带来较大压力，请调整健康检查的设置；健康检查的话 1）调低检查频率 2）设置检查静态文件，而不是默认首页或者动态文件 3）设置一个不记录日志的virtualhost，专门用于健康检查。 2）SLB里的带宽 和后面对应服务器的带宽有什么关联关系？比如SLB我设置了带宽为10M， 但是我后 面2台服务器购买的带宽都只有2M， 这种情况带宽以哪个为准？ 如果您设置的是常规7层slb负载均衡，那么网站访问所使用的带宽，都将通过slb而不需要消耗云服 务器的带宽，但是云服务器本身的系统更新，以及您更新网站等等也是需要带宽的，因此您保留2M 即可。 3)采用流量计费方式的话带宽是否没有限制? SLB按流量计费最大的带宽是1G。 4)请问我如何获得一个外网SLB期所对应的内网IP呢？比如现在我有一个外网SLB下挂了一个ECS， 而ECS的iptables里我想做一些配置，针对来自于这个SLB的请求做一个判断，我需要知道这个外网 SLB的内网IP。 目前SLB与后端通过如下地址段进行交互： 10.158.0.0/16 10.159.0.0/16 100.97.0.0/16 您可以针对上述地址段做相关配置。 5)如何确保SLB后端的多台ECS之间的数据同步呢? 目前，有很多类似的工具可以实现服务器之间的数据同步，比如：rsync。具体使用及选择，还请通 过其他途径获得更多的介绍资料及指导信息。您也可以将您的ECS配置成无状态的应用服务器，而数 据和文件统一存放在RDS和OSS服务上。 ------------------------- 2015年1月第4周1.为什么我的SLB实例突然消失了？请检查您的SLB服务是否设置了自动释放时间导致。2.我想关掉负载均衡，怎么操作？您直接登录到阿里云管理控制台——slb负载均衡——实例中查询创建的slb服务，后方有“释放”的按钮，您直接释放即可。3. 我现在有两个阿里账号里面都有ECS，我能不能在一个slb里面配置不同阿里云账户下的ECS？目前只能将同一账户下的服务器添加到SLB中，无法跨账户添加。4.ECS做负载均衡需要用户做额外的配置吗？可以参考http://help.aliyun.com/knowledge_detail.htm?knowledgeId=5973987。5. 云服务器上做数据库负载均衡如何实现，需要购买什么产品 ？文件服务器能否做负载均衡，比如10台文件服务器，包括读写这种的  ？1）数据库集群,用slb理论上是可以做的,但是如果您需要集群级别的数据库,建议使用我们的RDS。2）文件服务器也可以负载均衡,使用slb在均衡,保持会话,但是有一个问题是后端文件同步的,需要您自行同步,如 rsync。6.看SLB的说明是支持ddos的防护的，请问下，SLB的防护的峰值是多少，超过峰值黑洞时间是多少？这个与slb所在地区有关，和ecs的防御阀值是一样的，黑洞时间也是2.5小时。7. slb第七层是基于haproxy还是nginx还是tengine实现的？使用tengine实现的。8.7层和4层 SLB的超时时间是多少？7层超时时间是60s，4层超时时间是900s。9.负载均衡健康检查请求数量太多，怎么回事？因为slb前端机器是一组机器，所以健康检查请求较多，请您不要担心，集群内的每台服务都会对您的健康按照您设定的频率去做健康检查：您可以按照上述方法去优化您的健康检查项，看似请求量很大，但是对您资源消耗很少的，有2个建议给您：1）扩大健康检查的频率2）将检查页面配置为静态页面。这样请求消耗的资源会节省。10. SLB配置中的最小连接数是基于什么样判断？SLB会自动判断 当前ECS 的established 来判断是否转发。 ------------------------- 2015年2月第1周1)我想了解下SLB按流量计费是不是每小时需要扣0.02元?按量付费，国内节点配置费用是按照0.02/小时。流量单独计费。按带宽计费:采取按小时计费，以日结算（运行未满一日，按照当日实际使用小时数*当日开通的最高带宽的天价格/24）。如果您使用SLB实例的时间不足一小时，按一小时收费。2）请问健康检查发的什么请求？ head 还是 get？head请求。3）SLB最大连接数如何来设置？目前暂不支持设置最大连接数限制。4）SLB 后端有两个服务器HA1和HA2，为什么我将HA1的权重设置成0，SLB的健康检查就有告警呢？slb四层的话，只要权重设置为0，那么健康检查就是显示异常。 ------------------------- 2015年2月第3周1)负载均衡SLB的实例防攻击防御是多少？我们有云盾的防御黑洞策略，比如以杭州节点的slb，其最高防御的流量阈值为5G，当最大流量超过5Ｇ，您的slb vip则会被加入到黑洞中，触发黑洞会使ecs或者slb正常使用中断2.5小时，这个您可以通过云盾管理控制台查看到这个说明。2） 我其他机房的服务器能添加到你们的负载均衡SLB中吗？不可以的，slb使用的是内网和后端的ECS互联，无法直接添加非阿里云主机的服务器，且slb后端的ecs需要使用同一节点的主机。3）负载均衡服务支持的最大负载均衡实例数目多少？总体峰值可支持每秒新建链接数大约多少？SLB对于后端服务器的数目是没有限制的。对于总体峰值每秒新建连接数是没有限制的。但是因为SLB前端是云盾服务，所以最大值取决于云盾中您配置的请求数。您可以查看云盾看到具体的值。4）SLB按量计费为什么需要设置带宽峰值？如果不设置带宽峰值，遇到攻击等情况，可能流量打的非常高的，带宽流量峰值您可以在slb控制台设置。5）在SLB控制面板看到的流入流量，要比后端服务器的eth0的income流量小很多， 请问slb的流入流量是否应该等于后端服务器的内网网卡入流量吗？不等于的，后端的eth0包括了slb的流量，还有其他的流量，包括ecs直接的内网通信等。slb只做转发，不处理请求的，slb通过内网转发到ecs。6）SLB中的月账单 是指我们拥有所有的 SLB 实例的计费呢，还是单独的某个 SLB 的计费？月账单是指您不同类型产品，截止当前日期内月内消费计费额度的，是所有SLB产品的。您也可以通过账单明细进行查询具体信息的。 ------------------------- 2014年2月第4周1）10.159.63.55,这个内网ip，总是恶意访问我们网站？SLB系统除了会通过系统服务器的内网IP将来自外部的访问请求转到后端ECS上之外，还会对ECS进行健康检查（前提是您已经开启了这一功能）和对您的SLB服务进行可用性监控，这些访问的来源都是由SLB系统发起的，具体包含的IP地址段是：杭州、青岛、北京、深圳节点SLB系统IP地址段：10.159.0.0/16，10.158.0.0/16和100.97.0.0/16，为了确保您对外服务的可用性，请确保对上述地址的访问配置放行规则。2）slb计费方式变更需要多久，业务会受到影响么？变更计费方式与变更配置说明1、支持用户在按使用流量和按公网带宽2种计费方式间切换；2、支持按固定带宽方式计费的用户灵活变更带宽配置；3、在一个自然日内，限制用户变更计费方式的次数为1次，变更计费方式将在第二日零点后生效；比如：用户在今天5月5日的10:00提交了变更计费方式，那么该变配申请将在明天5月6日00:00后生效。4、按固定带宽方式计费变更带宽配置即时生效，带宽计费取自然日内用户开通的最高带宽。5、对客户业务不会造成影响；3）负载均衡能将我的外部非阿里云服务器和ECS服务器放到一块？目前负载均衡SLB仅支持阿里云ECS，无法支持外部非阿里云服务器。4）slb是否有连接数限制，需要大量终端一直与平台保持长连接，阿里云能提多少长连接？SLB没有并发连接数限制的，slb是转发请求不做处理，实际连接数还要跟您后端的处理能力有关。 ------------------------- 2015年3月第1周1）调整权重会对SLB已经有的正常连接有影响吗？目前调整权重会对调整权重的这台主机已有的连接产生影响，会有连接卡主，卡住时间由健康检查配置的时间决定。2)slb是否支持UDP协议？目前SLB暂不支持UDP协议。3）现在TCP四层负载均衡的出口带宽受ECS机器的出口带宽限制吗？slb和ECS之间走的是内网流量，带宽是不受限制的。4）如果没有外网ip, 是否可以用slb的4层转发 ?没有带宽4层SLB也是可以使用的。 ------------------------- Re:负载均衡SLB常见咨询问题（持续连载至2015年3月第1周） 2015年3月第2周 1)SLB变更计费方式并支付成功后无法添加配置? SLB在一个自然日内，限制用户变更计费方式的次数为1次，变更计费方式将在第二日零点后生效查看您今天变更过一 次计费方式，开始时间：2015-03-09 00:00:00。原按使用流量计费，在2015-03-09 00:00:00后变更为按固定带宽计 费，带宽峰值: 2Mbps。同时在您新的计费方式生效之前，您是无法对该SLB进行修改配置的。 2）我的账户怎么欠费￥7.88，这是怎么回事？ 查看您有使用负载均衡slb业务，在slb产品的账单欠费，请您登陆用户中心-消费记录-账单明细中查看 记录。 3）如何屏蔽健康检查探测的日志记录？ 关闭或者屏蔽对test.php访问日志的方式： 在站点配置文件中添加内容： location ~ /test.php { access_log off; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi.conf; } 注： 1、对test.php的location必须要放置在对php|php5处理前，否则会因为先被进行全局匹配导致无法生效。 2、还可以用另一种方案实现： a、在后端服务器中单独为用于健康检查的页面建立一个站点； b、关闭这个站点的日志记录： location ~ .*\.(php|php5)?$ { access_log off; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi.conf; } 3、如果检查页面是其他格式，比如test.html，可以采用如下方式进行屏蔽： location ~ /test.html { access_log off; } 4.我想问下SLB的固定带宽，10M是不是上行和下行最大都能达到10M？ 固定带宽指的是下行带宽最大达到10M，上行带宽没有限制。上行带宽指的是SLB的入流量（上行），就是进入SLB的 流量。带宽指的是SLB的出流量（下行），就是SLB对外发生给客户端的流量。 5.一般配置SLB的时候有个权重0到100，是如何选择数值的？ 权重需要您根据后端机器的配置进行选择比如AB两台机器性能一致就分别设置50，这样请求就会在这两台机器上轮询 ，不同权重决定请求分发的分配。 ------------------------- 2015年3月第3周1）公网的SLB和ECS之间的流量是否收费？不收费。2） 想做SLB+两台ECS，附件OSS，程序Discuz。但是不知道如何实现?slb要求后端的两台ecs数据是一致的,为了保持数据的一致性，建议共享存数和数据，静态文件放置到oss里，数据库文件走自己搭建的主从或者，连接同一台rds。3）按流量计算是否需要设置峰值？按流量计费不需要设置峰值的。4）如何建一个子帐号来管理负载均衡SLB?子账户无法管理负载均衡服务。

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