Session和Cookie在网站开发中是用来保存用户与后端服务器的交互状态。它们有各自的缺点和优点。而且，他们的优点和应用场景是对立的。   Cookie 完整地描述：当一个用户通过HTTP访问一个服务器时，这个服务器会将一些Key/Value键值返回给客户端浏览器，并给这些数据加上一些限制条件，在条件符合时，用户下次访问这个服务器时，数据又将完整地带回给服务器。 简短版描述：Cookie就像是访问服务器时服务器颁发给用户的“身份证”，下次访问的时候带回这身份证，服务器就能识别信息。   版本：当前的Cookie有两种版本，Version 0 和Version 1，它们分别对应两种设置相应头的标识，分别是“Set-Cookie”和“Set-Cookie2”。两种版本的属性项有些不一样。值得注意的是：Java Web的Servlet并不支持Set-Cookie2响应头，在实际应用中，Set-Cookie2的一些属性项可以设置在Set-Cookie中。   Cookie是如何工作的？ 真正创建Cookie是在org.apache.catalina.connector.Response类中完成的，调用generateCookieString方法将Cookie对象构造成一个字符串，构造的字符串的格式如userName="junshan";Version="1";Max-Age=1000.然后将这个字符串命名为Set-Cookie添加到MimeHeaders中。值得注意的是：Cookie对象的名字不能和Header的项重复，不然将导致错误。 我们在创建Cookie时，都创建了一个以NAME为Set-Cookie的MimeHeaders。每次调用addCookie时，都会创建一个Header。同时，在HTTP返回字符流时，是将Header中的所有项顺序地写入，而没有经过任何地修改。所以浏览器在接受HTTP返回的数据时是分别解析Header项的。 当我们请求某个URL路径时，浏览器会根据这个URL将符合条件的Cookie放在Request请求头中传回服务器，服务器通过request.getCookies()来获取所有的Cookie。   使用Cookie的注意事项 1、如果不为Cookie设置它的生存周期的话，默认是关闭浏览器的时候就销毁Cookie。 2、Cookie默认情况下是不允许出现中文字符的，如果我们要添加具有中文内容的Cookie时，我们需要使用java.net.URLEncoder先对中文进行编码，随后在进行Cookie的添加。读取Cookie时，需要使用java.net.URLDecoder对其进行解码。 3、不同的浏览器对Cookie的存储都有一些限制，通常是Cookie数量和Cookie总大小的限制。像火狐对Cookie的限制是每个域名只能有50个Cookie值，总大小不能超过4097个字。 4、Cookie在HTTP的头部，所以通常的gzip和deflate针对HTTP Body的压缩不能压缩Cookie，如果Cookie的量非常大，要做Cookie做压缩，压缩方法是将Cookie的多个K/V看作是普通的文本，做文本压缩。值得注意的是，Cookie的规范中规定，Cookie仅能保存ASCII码为34~126的可见字符，所以压缩之后的结果再进行转码，可以进行Base32或者Base64编码。     Session 完整描述：从客户端浏览器连接服务器开始，到客户端浏览器与服务器断开为止，像这样的一次会话中，Session起到的作用是跟踪用户的会话信息。 简短版描述：Session在浏览器和服务器连接过程中跟踪用户信息。   Session是如何工作的？ 服务器创建HttpSession对象的前提是拥有Session ID。第一次触发通过request.getSession()方法。当当前的Seesion ID还没有相应的HttpSession对象时，服务器会创建一个新的，并将这个对象加到org.apache.catalina.Manager的session容器中保存。 Manager类将管理所有Session的生命周期，Session过期就会被回收，服务器关闭，Session 将被序列化到磁盘等。 只要这个HttpSession对象存在，用户就可以根据Session ID来获取这个对象，也就做到了对状态的保持。 从Request中获得的Session对象保存在org.apache.catalina.Manager类中，它的实现类是StandardManager，通过requestedSessionId从StandardManager的session集合中取出SandardSession对象。一个客户端对应一个StandardSession对象，这个对象正是保存着我们创建的Session值。 当Servelt容器重启或者关闭的时候，StandardManager负责持久化没有过期的StandardSession对象，它将所有的StandardSession对象持久化到“SESSIONS.ser”为文件名的文件中，到Servlet重启的时候，它会重新读取这个文件，解析出所有的Session对象，并重新保存在session集合中。   说明 session范围内的属性可以在多个页面的跳转之间共享。一旦关闭浏览器，即session结束，session范围内的属性将全部失去。 session对象是HttpSession的实例，它有两个常见的方法：getAttribute（）和setAttribute（）。 session的属性值可以是任何可序列化的java对象。   安全性对比 Cookie：数据保存在客户端的中，所有这些数据可以被访问到的，甚至可以人为地进行修改和添加，所以在这方面的话，Cookie是不安全的。 Session：数据保存在服务器端，只是通过Cookie传递一个SessionID而已，所以Session更适合用来存储用户私密和重要信息。如登陆密码等。   安全性解决方案：分布式Session框架 使用Cookie可以很好地解决应用的分布式部署问题，由于Cookie是将值存储在客户端的浏览器里，用户每次访问都会将最新的值带回到处理该请求的服务器，所以不存在同一个用户的请求会在同一台服务器处理而导致Cookie不一致的问题。 但是，过多的使用Cookie也会造成一些麻烦：如客户端的限制、Cookie管理混乱、安全令人担忧等。 于是，分布式Session框架诞生。 统一使用订阅服务器推送配置可以有效地集中管理资源，所以省去了每个应用都来配置Cookie，简化Cookie的管理。用统一的一个服务订阅服务器，在应用启动的时候从该服务器订阅这个应用能够使用哪些Session和Cookie项，这些配置的Session和Cookie可以限制这个应用能够使用哪些Session和Cookie，甚至控制Session和Cookie可读或者可写。这样就可以精确地控制哪些应用可以操作哪些Session和Cookie，从而有效地控制Session的安全性和Cookie的数量。 还有一个非常重要的问题是：如何处理跨域名来共享Cookie的问题。Cookie是有域名限制的，一个域名下的Cookie不能再另外一个域名下访问，如果要在两个域名之间实现登陆有效，需要实现Session同步，需要另外一个跳转应用，这个应用可以被一个或多个域名访问。 它的主要功能是从一个域名下取得sessionID，然后将这个sessionID同步到另外一个域名下。这个sessionID其实就是一个Cookie，相当于JSESSIONID，所以，经过12步的操作，一个域名不用登陆就可以取到另外一个域名下的session。   http://www.cnblogs.com/zhouyuqin/p/4693737.html    

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/a724888/article/details/63683030 这位大侠，这是我的公众号：程序员江湖。 分享程序员面试与技术的那些事。 干货满满，关注就送。  session和cookie都是用来保持用户与后端服务器的交互状态。 cookie大小大小受限，并且占带宽。 session不能在多个服务器间共享。   cookie是保存在客户端的一个数据结构 session是保存在服务端的一个数据结构。   服务端：在tomcat中使用addcookie方法添加cookie，真正则是在response中完成创建。 接受客户端cookie：通过request.getcookies()来获得。   request和response  Request 和 Response 对象起到了服务器与客户机之间的信息传递作用。Request 对象用于接收客户端浏览器提交的数据，而 Response 对象的功能则是将服务器端的数据发送到客户端浏览器。   session对cookie的改进： cookie在每次访问时需要传回，增加传输量，可以设置id作为标志进行传递，即session id是通过cookie传递的，属性值为jsessionid。   有了seesionid，服务端可以创建httpsession对象。第一次触发通过request.getsession（）。以后都通过session id来找到session。   session没过期时，即使容器关闭或重启也会被持久化。 同个浏览器打开同一个应用多次会使用同一个session，不同浏览器打开一个应用会用不同的session。       cookie问题：客户端存储限制、cookie管理混乱，cookie不能跨域名，安全问题。 可以用分布式session框架解决。 实现方式：   1统一使用订阅服务器管理cookie，应用服务器需要哪个cookie由订阅服务器来推送。一般用zookeeper实现 集群的配置管理。     2session将保存到分布式缓存中，让服务器可以共享访问，因为session不可能同步到每个服务器上。   分布式缓存可以用memcache实现。   3cookie太大的办法是压缩cookie，将keyvalue转化为文本。   4多终端session统一：手机和电脑的cookie和session需要统一，即包括数据结构，存储。防止二次登陆等问题。所以需要在服务端统一session，所有终端拿到的session id都一样。   5：热门。电脑打开网页扫码登录 服务端不停检测标识，手机登录后产生标识使pc端登录成功。

负载均衡支持对多台ECS进行流量分发，以提升应用系统的服务能力，长期以来都是关键业务系统的入口。淘宝，天猫，阿里云等无不依赖负载均衡产品，双11的流量洪峰也依赖负载均衡的调度和处理能力。 负载均衡SLB简单介绍 下图是负载均衡的简单示意图，用户的访问请求经过SLB实例的一个监听（端口），再被转发到后端的ECS上。SLB实例对应一个IP地址，监听就是实例上IP地址的一个端口，流量调度是基于监听（端口）进行的，ECS是真正处理服务请求的。   负载均衡SLB架构 下图是从流量转发路径来看的负载均衡SLB的架构图，可以称为一个负载均衡SLB的集群，这个集群部署在华东1的两个可用区，每个可用区都部署了LVS集群和Tengine集群，其中LVS集群负责接收所有流量的请求，包括TCP/UDP/HTTP/HTTPS，对于TCP和UDP请求，LVS集群会直接将流量转发到后端ECS，对于HTTP/HTTPS 请求会将流量转发给Tengine集群，再转发到后端ECS上。 负载均衡SLB高可用的四个层次 为了便于理解和说明，可以将负载均衡SLB高可用划分为四个层次，如图上图所示，第1层是应用处理层，即真正处理请求的ECS层。第2层是集群转发层，即在集群转发层面要保证高可用，第3层是跨可用区容灾层，在出现可用区级别的故障时可以切换，第4层是跨地域容灾层，上图未标示。下面分别从这4个层次进行分析和说明。 特别要说明的是，产品设计上SLB会尽可能做到高可用，但如果用户系统没有高可用设计，最终也不可能实现真正的高可用，而且除了负载均衡，还有数据库等的高可用问题，因此产品设计的高可用和用户系统设计高可用必须结合起来。下面4个层次的说明也会分别从产品设计和用户使用两个角度进行分析和解读。 第一层 应用处理层 应用处理层是真正处理用户请求的，一般将应用部署在ECS上。 从产品设计角度看： 应用处理层的高可用主要有下面两点，一是要保证ECS出现故障时能及时屏蔽，避免将流量转发到故障节点从而影响用户访问，SLB产品是通过健康检查功能实现的。二是SLB实例能够添加多台ECS，特别是可以添加不同可用区的ECS，从而避免一个可用区的ECS均不可用时影响用户访问。这两点目前SLB产品都可以做到。 从用户使用角度看： 首先，用户一定要开启并正确配置健康检查。SLB支持TCP/UDP/HTTP/HTTPS 四种协议，其中对TCP协议提供了TCP和HTTP两种健康检查方式，用户可以根据需要选择。对UDP协议，用户可以定义UDP健康检查端口，还可以根据自己定义健康检查请求和返回值来判断健康检查结果。对于HTTP和HTTPS协议，默认使用HTTP健康检查，用户可以定义一个健康检查URL，负载均衡的健康检查模块会通过HTTP HEAD来探测获取状态。关于健康检查详细信息可以参考健康检查原理说明 其次，用户要考虑到单可用区ECS都不可用的情况，选择多个可用区的ECS添加到负载均衡SLB的实例中。用户可能有疑问，如果一个可用区的ECS不可用了，那这个可用区的负载均衡是不是也会不可用？这个问题在稍后的第三层来说明。 第二层 集群转发层 集群转发层指的是负载转发用户请求的SLB集群，包括LVS 集群和Tengine集群，不管是机器故障还是集群升级，都要保障用户请求尽可能不中断， 从产品设计角度看： 首先，必须避免单点故障，如果采用传统的主备切换模式一方面在切换的时候可能影响用户请求，另一方面主备切换还是依赖单机的处理能力，无法很好的横向扩充，因此，转发层不管是LVS还是Tengine集群都集群部署，并通过上层交换机的ECMP等价路由还实现用户请求到集群多台机器的流量转发。看上面的架构图可能用户有疑问，TENGINE集群是接在LVS集群后面的，上层交换机的ECMP如何起作用呢？其实LVS集群对Tengine集群也是有健康检查机制的，即如果Tengine集群的机器出现异常，LVS健康检查发现后会将这台异常的Tengine机器从集群中摘除。 其次，在集群中机器出现down机等异常时尽可能不影响用户请求。有了集群部署后，集群中的机器出现软硬件故障还是难以避免的，有可能机器彻底不可用了或者有异常了需要通过运维手段将这台机器从集群中移出并维修，这个时候这台机器上的用户请求要尽可能做到不中断。 SLB集群是通过Session同步来实现集群中有机器故障时尽可能不影响用户请求的。如下图所示，当用户的访问请求经过集群中的一台LVS时，集群会根据预设的规则将Session同步到其它LVS机器，从而实现LVS集群所有机器都有该Session，当如下图中的LVS1机器出现故障或需要维护时，用户请求就会通过其它LVS机器进行流量转发并且用户基本不感知。但是有Session同步不代表就解决了所有问题，Session同步能解决大部分长连接的问题，但是对于短链接，连接未建立（三次握手未完成）或者已建立连接但是还没有触发Session同步规则时，机器故障还是可能会影响用户请求。因此，需要用户的系统和程序进行配合。                        从用户使用角度看，一定要在代码中加上相应的重试机制！ 这样在上述情况出现时，会进一步降低对用户访问影响。 第三层 跨可用区容灾层 上面说的是在一个可用区内负载均衡转发集群的高可用，跨可用容灾层则要解决的是当一个可用区都不可用时，还能继续使用另外一个可用区的负载均衡继续提供服务。 从产品设计角度看： 还是如看SLB架构图，首先，负载均衡集群要实现跨可用区部署。另外，还需要一种机制能及时发现其中某个可用区，如可用区A都出现了故障然后切换到另外一个可用区B继续服务。从技术上讲，使用了路由探测和路由优先级机制来实现，即可用区A的一段地址（对应一批SLB实例1-N）除了在本可用区的集群上配置外，其实底层还在可用区B的集群上也有这段地址（对应一批SLB实例1-N），只不过在正常情况下，由于可用区A的这段地址路由优先级更高，所以流量都从可用区A的集群进行转发，如果路由探测到整个可用区A不可用（路由不可达）或者可用区A的某段地址不可用（路由不可达），则路由到可用区B的集群进行流量转发。 从用户对产品形态的感知上来说，就是主可用区和备可用区，但实例上的这个主备可用区用户选择后就无法更改了，用户也无法自行切换主备关系。也就是说主备可用区是底层的机制，用户一旦选择无法干预了。暴露主备可用区概念的原因一方面希望用户在使用SLB和其它有可用区属性的产品进行组合的时候，能做到按需组合，如ECS可用区，RDS的主备可用区等。另一方面也是希望用户更多认知到产品在高可用方面的价值。不过在实际使用时，用户往往存在误区，这些误区使我们考虑是不是要关闭备可用区概念，只对用户暴露主可用区，后面再来解释这些误区。 回过头来说跨可用区高可用，其实，最理想的情况是一个可用区的一个SLB实例出现异常（路由不可达）时，系统就能够自动切换或者用户能手动切换到另外一个可用区的SLB实例继续服务。但不能这样做的主要原因是需要发布明细路由，即32位路由，而这在云环境中是无法接受的。 从用户使用角度看： 首先，跨可用区容灾需要保证一个SLB实例的后端服务器ECS分布在多个可用区，即避免一个可用区不可用时，SLB后端的ECS都无法使用从而影响用户访问，这点在第一层 应用处理层中已经说明了。当然，如果还使用DB等产品，还需要考虑DB的跨可用区容灾问题，用户可以参考DB相关产品的说明。这里主要谈负载均衡本身以及和负载均衡紧密相关的后端服务器ECS的高可用问题。 其次，对于重要的业务，一定要使用至少两个且主可用区不一样的实例来容灾，这点非常重要。如重要的用户注册系统，如下图所示，在华东1的可用区A和可用区B分布部署一个SLB实例，都挂载了两个可用区的相同ECS。                                                                                                                  用户可能会有两个疑问，一是负载均衡SLB产品本身有跨可用区切换能力，为什么注册系统还需要自己在两个可用区建立两个实例进行跨可用区容灾呢？负载均衡SLB产品本身的跨可用区切换是在非常极端的情况下（整个可用区不可用/所有LVS集群上的IP无法路由/某个地址段都无法路由）才切换，而对于比如仅一个可用区的Tengine有部分异常、LVS集群有异常但是IP还可以Ping通等相对不那么极端又会影响用户业务的情况下是不起作用的，因此，重要的业务系统非常有必要用户自己在两个可用区建立实例容灾。 二是注册系统使用的两个SLB实例如何调度，用户可以使用云解析将注册系统的域名解析到上面的两个SLB实例，其它的相关域名解析系统也都支持这样的功能。如果是私网SLB实例，阿里云正在研发私网DNS系统，当前用户可以自己构建一个私网DNS系统或者通过程序来实现调度。 再次强调一下重要业务系统用户自行在两个可用区建立实例容灾的必要性。哪怕正常情况下有一个实例就配置好不使用，虽然需要支付每小时2分钱的公网IP费用，但当出现其中一个实例所在集群异常并且恢复时间较长时，用户也可以自行通过修改DNS解析或者程序调用地址来快速恢复业务。 最后，再来说下用户对于主备可用区可能存在的误区 1）认为主备可用区就是只要一个实例有异常了负载均衡就能自动切换到备可用区 2）认为主备可用区切换的异常包括个别实例无法Ping、实例上的服务异常等等很多条件 其实，负载均衡主备可用区切换设计是在极端情况下（整个可用区不可用/所有LVS集群上的IP无法路由/某个地址段都无法路由）才会自动进行的，它既不是某个IP地址无法路由就切换，也不是某个或者某些IP地址可以Ping但这些IP的服务异常就切换。因此，用户系统通过自身在多个可用区建立实例实现跨可用区灾是非常必要的。 第四层 跨地域容灾层 最后来说下跨地域容灾层。随着业务的发展，用户对业务系统的高可用要求越来越高，已经不满足于只能做到跨可用区的容灾，用户希望即使某个地域的系统都不可用了，还可用通过其它地域的系统继续提供服务，这就是跨地域容灾。 跨地域容灾是个非常大的课题，不仅仅涉及到网络层面，更涉及到应用系统的改造和适配，数据的同步和一致性等很棘手的问题。这里仅说明下网络层面的跨地域容灾。从产品角度看，跨可用区容灾一般是通过DNS来实现的，如下图所示 传统的如F5的全局负载均衡（以前叫GTM，现在叫BIG-IP DNS）就有比较完善的解决方案，或者一些提供DNS服务的系统也有类似的功能。负载均衡SLB产品本身没有提供这样的能力，跨地域容灾的能力是通过云解析DNS产品来实现的，云解析DNS产品提供了全局负载均衡的能力，还有如健康检查，路由调度优化等功能，可以参考 全球负载均衡跨地域容灾解决方案 另外，对于跨可用区容灾可能需要使用在不同地域间同步数据或者跨地域私网调用，可以使用高速通道产品构建不同地域的通信链路 从用户角度看，跨可用区容灾网络层面主要通过云解析DNS产品，对于不同地域间通信可以使用高速通道产品，这两个产品不是本文的重点，可以查看阿里云官网的相关产品文档说明。

源文档链接: http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html  翻译日期: 2014年3月19日 翻译人员: 铁锚 感受: Tomcat 的这个集群有很多问题, 所以如果需要做分布式集群，最好使用无状态的应用程序,外加缓存系统。假如改造旧系统，那么也许可以参考一下。 翻译如下: Apache Tomcat 6.0 如何实现 集群化/Session 复制 重要提示 也可以查阅 cluster配置参考文档. 内容列表 快速设置 Cluster 基础 概述 集群信息 崩溃后绑定会话到故障转移节点 配置示例 集群架构 运行机制 FAQ 快速设置 只要在 <Engine> 节点 或者 <Host> 节点内部加上下面的代码即可支持集群化: <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/> 上面的配置将开启 all-to-all session 复制,并通过 DeltaManager 来复制 session 增量. 采用 all-to-all 方式意味着 session 会被复制到此集群中其他的所有节点. 对于很小的集群,这种方式很适用, 但我们不推荐在较大的集群中使用(有很多 tomcat 节点的情况,译者注: 例如,几十个节点及以上...). 另外,使用 delta 增量管理器时,即使 某些节点没有部署应用程序,也会复制 session 到所有节点上.  要在较大的集群上进行session复制,您需要使用 BackupManager. 此 manager 只复制 session 数据到一个备份节点, 并且只复制到部署了对应应用程序的那些节点. BackupManager的缺点: 经过测试,性能不如 delta manager.  下面是一些重要的默认值:  1. 默认的 Multicast (组播)地址是: 228.0.0.4  2. 默认的 Multicast (组播)端口是: 45564 (端口号和地址组合以后就决定了 cluster 关系,被认为是同一个集群).  3. 默认广播的IP java.net.InetAddress.getLocalHost().getHostAddress() (确保你不是广播到 127.0.0.1, 这是一个常见的错误)  4. 默认的监听复制消息的 TCP 端口是在 4000-4100 范围内第一个可用的server socket。  5. 配置了两个监听器: ClusterSessionListener 和 JvmRouteSessionIDBinderListener  6. 配置了两个拦截器: TcpFailureDetector 和 MessageDispatch15Interceptor  下面是默认 cluster 配置信息的完整列表(效果和上面只配置一行是一样的):  <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster" channelSendOptions="8"> <Manager className="org.apache.catalina.ha.session.DeltaManager" expireSessionsOnShutdown="false" notifyListenersOnReplication="true"/> <Channel className="org.apache.catalina.tribes.group.GroupChannel"> <Membership className="org.apache.catalina.tribes.membership.McastService" address="228.0.0.4" port="45564" frequency="500" dropTime="3000"/> <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver" address="auto" port="4000" autoBind="100" selectorTimeout="5000" maxThreads="6"/> <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter"> <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/> </Sender> <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/> <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/> </Channel> <Valve className="org.apache.catalina.ha.tcp.ReplicationValve" filter=""/> <Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/> <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer" tempDir="/tmp/war-temp/" deployDir="/tmp/war-deploy/" watchDir="/tmp/war-listen/" watchEnabled="false"/> <ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/> <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/> </Cluster> 本文稍后将详细介绍此节的信息. Cluster 基础 要在 Tomcat 6.0 容器中执行 session 复制, 需要完成下列步骤: 所有存放到 session attributes 中的对象必须实现 java.io.Serializable 接口 将 server.xml 中的 Cluster 元素取消注释(或者加上此元素) If you have defined custom cluster valves, make sure you have the ReplicationValve defined as well under the Cluster element in server.xml 如果多个 Tomcat 实例是运行在同一台机器上, 确保 tcpListenPort 属性对每个实例都是唯一的, 在大多数情况下 Tomcat 会自己解决这个问题(如果没指定的话),通过 自动检测 4000-4100 范围内的可用端口号. 确保在项目的 web.xml 文件中 web-app 根节点内加上 <distributable/> 元素 如果使用 mod_jk, 请确保在 Engine 节点上设置了 jvmRoute 属性 < Engine name="Catalina" jvmRoute="node01"> ,并且 jvmRoute 属性值与 workers.properties 中的 worker name 对应 确保所有的节点有相同的时间,并都采用 NTP 服务来同步! 确保 loadbalancer 负载均衡器配置了 sticky session 模式. 负载均衡可以通过多种方式实现, 可以参考 Load Balancing 文档. 注意: 请记住在Java中 session 状态是通过一个 cookie 来跟踪的, 所以客户端看到的 URL 必须是一致的(host,port), 否则就会创建一个新的 session. 注意: 当前要支持 Clustering 需要 JDK 版本号 1.5 或更高. Cluster 模块使用的是 Tomcat JULI 日志框架, 因此你可以通过常规的 logging.properties 文件来配置. 要打印日志跟踪信息, 可以通过 key: org.apache.catalina.tribes.MESSAGES 来启用日志功能. 概述 要在Tomcat中启用 session 复制, 下面的3种不同的途径都可以达成同样的目的: 使用 session 持久化, 并保存session到一个共享的文件系统中 (PersistenceManager + FileStore) 使用 session 持久化, 并保存session到一个共享的数据库中 (PersistenceManager + JDBCStore) 使用 内存复制(in-memory-replication), 通过 Tomcat 6 附带的 SimpleTcpCluster (lib/catalina-tribes.jar + lib/catalina-ha.jar) 在这个版本的 session 复制中, Tomcat 可以通过 DeltaManager来进行 all-to-all 方式的session复制, 也可以通过 BackupManager 将session备份复制到单个节点. all-to-all 复制算法只在集群很小时具有高效率. 对较大的集群, 可以使用 主备会话复制(primary-secondary session replication), 只需要简单地配置 BackupManager 即可将会话信息复制到备份节点.  那么现在你可以使用domain worker 属性 (要求 mod_jk > 1.2.8) 通过DeltaManager来构建集群分区的可伸缩集群解决方案 (为此需要配置域名拦截器[domain interceptor]). 为了在一个 all-to-all 环境中降低复制所消耗的网络流量, 可以将集群切分为更小的组. 通过为不同 group 使用不同的组播地址(multicast addresses)这可以很容易地实现. 一个很简单的集群配置如下所示: DNS 轮询 | Load Balancer / \ Cluster1 Cluster2 / \ / \ Tomcat1 Tomcat2 Tomcat3 Tomcat4 需要郑重指出的是, 会话复制(session replication) 只是集群化的起步. 另一个用于实现集群的流行概念是farming, 例如, 你只需要部署 app 到一台服务器上, 则集群会自动将此部署分发到整个集群中.这是所有可以和 FarmWarDeployer 一起使用的功能(参见server.xml 中的集群示例 ) 下一节将深入讲解会话复制(session replication )的工作原理,以及如何配置它. 集群信息 集群关系是通过广播心跳包来建立的. 因此,如果想要细分集群,可以通过改变组播IP地址或 <Membership>元素中的端口号来实现. 心跳包括Tomcat节点的IP地址以及Tomcat监听复制通信的TCP端口号. 所有数据交换使用的都是在TCP协议. 参数 ReplicationValve 用来决定何时请求完成,何时对复制进行初始化, 如果 session 改变了(通过调用 session 的 setAttribute 或 removeAttribute 方法),才会复制那部分数据. 最重要的注意事项之一就是同步和异步复制的性能对比. 在同步复制模式下请求不会立刻返回,需要等待复制的session被发送到集群中的其他所有节点,并处理完成后才会返回. Synchronous(同步) vs. asynchronous(异步) 通过 channelSendOptions 标志进行配置,类型为整数型. SimpleTcpCluster/DeltaManager 的默认值都是 8, 也就是异步的(asynchronous). 更多信息请参考 send flag(overview) 或者 send flag(javadoc). 在异步复制期间, 在数据被复制之前,客户端请求就已经返还了. 异步复制拥有更短的响应时间, 而同步复制则保证 session 信息在请求返回之前被复制. 崩溃后绑定会话到故障转移节点 如果你使用了 mod_jk 却没有使用 sticky sessions 或由于某些原因 sticky session 没有生效, 或者只是简单的故障转移, 则 session id 需要被修改,因为其中包含了原来 tomcat 的 worker id (在Engine 元素中通过jvmRoute 定义). 要解决这个问题, 将要使用到 JvmRouteBinderValve. The JvmRouteBinderValve 重写 session id 以确保在故障转移后,下一个请求仍然是粘连的 (并不会因为 worker 的不可用就被回退到其他的随机节点). 该 valve(阀门) 将会重写 cookie中的 JSESSIONID 值,当然,使用的是同样的名字(name). 假如没有正确地设置 valve, 将使 mod_jk 模块在失败后很难保持会话的粘连。 如果没有配置阀门(valves),会添加默认的 JvmRouteBinderValve， 同时会添加名为 JvmRouteSessionIDBinderListener 的集群消息侦听器(listener),以用来在故障转移发生时执行重写 session id 到集群中的其他节点。 记住,如果你在 server.xml 中添加自定义的阀门和监听器, 则默认设置就不再生效,请确保添加了所有和默认设置兼容替换的阀门和监听器。 提示:  通过属性 sessionIdAttribute 可以更改包括旧 session id 的请求属性名。 默认属性名为org.apache.catalina.cluster.session.JvmRouteOrignalSessionID。 技巧:  您也可以在删除一个节点之前通过 JMX 启用 mod_jk 的转移模式 到所有备份节点! 备份节点上在所有的 JvmRouteBinderValve 备份节点上设置 enable为 true, 禁用mod_jk 的 worker, 然后删除节点并重启!然后再次启用mod_jk Worker 和禁用JvmRouteBinderValves。这个用法意味着只有请求会话被迁移。 配置示例 <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster" channelSendOptions="6"> <Manager className="org.apache.catalina.ha.session.BackupManager" expireSessionsOnShutdown="false" notifyListenersOnReplication="true" mapSendOptions="6"/> <!-- <Manager className="org.apache.catalina.ha.session.DeltaManager" expireSessionsOnShutdown="false" notifyListenersOnReplication="true"/> --> <Channel className="org.apache.catalina.tribes.group.GroupChannel"> <Membership className="org.apache.catalina.tribes.membership.McastService" address="228.0.0.4" port="45564" frequency="500" dropTime="3000"/> <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver" address="auto" port="5000" selectorTimeout="100" maxThreads="6"/> <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter"> <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/> </Sender> <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/> <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/> <Interceptor className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/> </Channel> <Valve className="org.apache.catalina.ha.tcp.ReplicationValve" filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;"/> <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer" tempDir="/tmp/war-temp/" deployDir="/tmp/war-deploy/" watchDir="/tmp/war-listen/" watchEnabled="false"/> <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/> </Cluster> 我们一项项地来解读!! <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster" channelSendOptions="6"> Cluster是主要的元素,所有集群相关的详细配置都包含在元素内部. SimpleTcpCluster类或调用 SimpleTcpCluster.send 方法发送的每个消息, 都会附加上 channelSendOptions 这么一个标志. 关于发送标志的详细描述信息可以参考 Tomcat 官方 javadoc . DeltaManager 调用 SimpleTcpCluster.send 方法来发送消息, 而 backup manager 则自己直接通过channel来发送.  想要了解更多信息, 请访问 集群配置参考文档 <Manager className="org.apache.catalina.ha.session.BackupManager" expireSessionsOnShutdown="false" notifyListenersOnReplication="true" mapSendOptions="6"/> <!-- <Manager className="org.apache.catalina.ha.session.DeltaManager" expireSessionsOnShutdown="false" notifyListenersOnReplication="true"/> --> 这是一个用于 manager 配置的模板,当 <Context> 元素中没有定义 manager 时作为默认值. 在 Tomcat 5.x 中每个标记为 distributable 的 webapp 都需要使用同一个manager。 但从 Tomcat 6 开始就没有这样的限制了, 可以为每个 webapp 指定一个 manager 类, 因此在 cluster 中可以存在多种 managers. 显然, 在一个节点中某个应用程序的 管理器 必须同集群中其他节点同一个应用的管理器保持一致。 如果 webapp 被标记为 <distributable/> , 而webapp又没有自定义 manager, Tomcat 就会使用此模板克隆一个 manager 实例.  想要了解更多信息, 请访问 集群manager配置参考文档 <Channel className="org.apache.catalina.tribes.group.GroupChannel"> channel 元素是 Apache Tribes(Tribes,一群的), Tomcat 内部使用的 group 通讯框架. 该元素封装了通讯和成员关系需要用到的一切. 想要了解更多信息, 请访问 集群channel配置参考文档 <Membership className="org.apache.catalina.tribes.membership.McastService" address="228.0.0.4" port="45564" frequency="500" dropTime="3000"/> Membership 是通过 组播(multicasting) 建立的. 请注意 Tribes 也支持使用 StaticMembershipInterceptor 来设置静态的成员关系， 如果你想要不使用组播来扩展成员关系的话。 address 属性是要使用的广播地址, port 属性是广播的端口号. 两者组合在一起创建了集群区分(cluster separation). 如果你想要一个可靠(QA cluster) 的生产集群(production cluster), the easiest config is to have the QA cluster be on a separate multicast address/port combination the the production cluster. 最简单的配置是使 QA集群在 一个分开的多播地址/端口组合成生产集群  membership 组件 广播其自身的 TCP adress/port 到其他节点 以 在 TCP 上完成 节点间的通信. 请注意被广播的地址是Receiver.address 属性 中的一个.  想要了解更多信息, 请访问 reference documentation <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver" address="auto" port="5000" selectorTimeout="100" maxThreads="6"/> 在 tribes 中,发送与接收数据的逻辑已经被分解到两个功能组件中. Receiver, 顾名思义, 负责接收消息. 因为 Tribes stack 是线程无关的(thread less), (这是一个很受欢迎的改进,其他框架也在使用), 所以在此组件中有一个线程池,并且可以设置 maxThreads 和 minThreads 参数.  address 属性是将要通过membership 组件广播给其他节点的 host 地址.  想要了解更多信息, 请访问 集群 receiver 配置参考文档 <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter"> <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/> </Sender> sender 组件, 见名知意,负责发送消息给其他节点. sender 有一个 shell 组件, 即 ReplicationTransmitter, 但是真正干活的是其子组件Transport. Tribes 支持 sender 池, 所以消息可以并行(Parallel)发送, 如果使用 NIO sender,还可以并发地(Concurrently)发送消息. 并发(Concurrently) 的意思是同一时间一条消息对于多个 sender; 而并行(Parallel) 的意思是同一时间多条消息对应多个 sender.  想要了解更多信息, 请访问 集群 sender 配置参考文档 <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/> <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/> <Interceptor className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/> </Channel> Tribes 发送消息要经过一个栈(stack). 栈中的元素被叫做拦截器(interceptor), 工作机制类似于 Tomcat servlet container中的valve阀门. 使用拦截器, 运算逻辑可以分解成可管理的多个代码片断. 上面配置的 interceptors 是: TcpFailureDetector - 通过TCP验证崩溃的节点, 如果组播数据包丢失, 这个拦截器防止假活跃(false positives), 即便节点仍然是存活的,但被标记为崩溃状态的情况. MessageDispatch15Interceptor - 分派消息到线程(池)来异步地(asynchrously)发送消息。 ThroughputInterceptor - 打印出简单的信息统计流量.  请注意 interceptors 的顺序是很重要的. 他们定义在 server.xml 中的顺序决定了他们在 channel stack 中的表现方式. 可以把他看成一个 linked list, head 是第一个拦截器,而 tail 是最后一个.  想要了解更多信息, 请访问 集群 interceptor 配置参考文档 <Valve className="org.apache.catalina.ha.tcp.ReplicationValve" filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;"/> 集群使用阀门(valve)来根据requests 找到 web applications, 我们在上面提到过 ReplicationValve 和 JvmRouteBinderValve. <Cluster> 元素本身并不是Tomcat管道的一部分, 而是cluster 将 valve 添加到其父容器中. 假如 <Cluster> 元素被配置到 <Engine> 元素中, 那么 valves 就会被加到 engine 里,诸如此类.  想要了解更多信息, 请访问 集群 valve 配置参考文档 <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer" tempDir="/tmp/war-temp/" deployDir="/tmp/war-deploy/" watchDir="/tmp/war-listen/" watchEnabled="false"/> 默认的tomcat集群支持 farmed 部署,即集群可以部署和卸载在其他节点上的应用程序。该组件目前的状态在不断变化,但很快就会得到解决。 在 Tomcat 5.0 和5.5 之间的部署算法发生了变化, 在这一点上,该组件的逻辑改变为 部署目录必须匹配 webapps目录。  想要了解更多信息, 请访问 集群 deployer 配置参考文档 <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/> </Cluster> 因为 SimpleTcpCluster 自身是 Channel object 的一个 sender 和 receiver, 所以其他组件可以注册成为 SimpleTcpCluster 的监听器(listener). 上面的 ClusterSessionListener 监听着 DeltaManager 的 复制消息(replication messages) 并应用 manager 的增量已经 反过来应用到 session中..  想要了解更多信息, 请访问 集群 listener 配置参考文档 集群架构 Component Levels(组件级别): Server | Service | Engine | \ | --- Cluster --* | Host | ------ / \ Cluster Context(1-N) | \ | -- Manager | \ | -- DeltaManager | -- BackupManager | --------------------------- | \ Channel \ ----------------------------- \ | \ Interceptor_1 .. \ | \ Interceptor_N \ ----------------------------- \ | | | \ Receiver Sender Membership \ -- Valve | \ | -- ReplicationValve | -- JvmRouteBinderValve | -- LifecycleListener | -- ClusterListener | \ | -- ClusterSessionListener | -- JvmRouteSessionIDBinderListener | -- Deployer \ -- FarmWarDeployer 运行机制 为了您能够快速容易地理解集群的运行机制, 我们将引导您体验一些列具体情境. 在情境中我们只使用两个Tomcat实例: TomcatA 和TomcatB . 并涵盖下面的事件序列: 启动 TomcatA (在 TomcatA 完全启动之后)启动 TomcatB TomcatA 收到一个请求,则创建一个 session,假设为 S1. TomcatA 崩溃了 TomcatB 收到一个来自 session S1的请求 TomcatA 启动 TomcatA 收到一个请求, 调用 session (S1) 的 invalidate 方法使其失效 TomcatB 收到一个请求, 属于一个新的 session: (S2) 因为不活动, TomcatA 中 session S2 超时. OK,现在我们有一个很好的顺序,我们将带你通过 session repliction 代码中 了解到底发生了什么 启动 TomcatA Tomcat 使用标准的启动顺序进行启动(starts up). 当 Host object 创建时, 会关联上一个 cluster object. 在解析 contexts 时, 如果在 web.xml 中存在 distributable 元素,则 Tomcat 通知 Cluster 类 (此时是 SimpleTcpCluster) 创建复制上下文(replicated context)的管理器(manager). 启用了集群, 在 web.xml 中设置了 distributable， Tomcat 会为 context 创建一个DeltaManager ,而不是使用 StandardManager. cluster 类将启动一个 membership service (广播) 以及一个 replication service (tcp单播). 在本文档下面将会介绍更多的架构信息。 启动 TomcatB 当TomcatB启动时,它遵循TomcatA一样相同的序列,只有一个例外。集群启动,并将建立一个成员关系(TomcatA TomcatB)。 TomcatB现在将请求服务器集群中已经存在的会话状态,在这种情况下也就是TomcatA。 TomcatA响应请求,在TomcatB开始监听HTTP请求之前,状态已经从TomcatA传输到了TomcatB。如果TomcatA不回应,TomcatB将在 60秒后超时,并报告一个日志条目。每个在 web.xml 中标记了 distributable 的web应用程序的会话状态都会得到传输。 注意: 要有效地使用会话复制,所有tomcat实例都应该配置成一样。 TomcatA 收到一个请求, 创建 session S1 . 来到TomcatA的请求处理就和没有会话复制时完全一样。当请求完成后,ReplicationValve在响应返回给用户将拦截请求,并激发一些行为。此时会发现session 已被修改,它会使用TCP复制会话信息给 TomcatB。 一旦序列化数据交给操作系统TCP逻辑,请求就通过阀门的管道返回给用户。对每个请求整个会话都被复制,这使得修改属性的代码在会话中不用调用setAttribute或removeAttribute也会被复制。 一个useDirtyFlag配置参数可以用来优化会话复制的次数。 TomcatA 崩溃 当TomcatA崩溃,TomcatB接收通知,TomcatA退出集群。TomcatB从其成员列表删除TomcatA,TomcatA将不再收到发生在TomcatB任何变化的通知。负载平衡器将所有会话(包括当前会话)请求从TomcatA重定向到TomcatB。 TomcatB 收到一个来自 session S1的请求 没有什么可激动的,TomcatB会处理此请求,就和其他普通请求一样. TomcatA 启动 TomcatA开始接受新的请求之前,将会根据上面描述的启动序列 1) 2) 来进行启动。它将加入到集群中,联系TomcatB获取所有会话的当前状态。一旦它收到会话状态,它完成装载并打开HTTP / mod_jk 端口。所以没有请求发给TomcatA,直到它从TomcatB接收完会话状态。 TomcatA 收到一个请求, 调用 session (S1) 的 invalidate 方法使其失效 invalidate 调用会被拦截, 并且 session 会被加入失效会话队列。 在请求完成时,不会发送会话改变消息, 而是发送一个“expire”消息给TomcatB, TomcatB也会让此会话失效。 TomcatB 收到一个新的请求, session (S2) (同步骤 3) 因为不活动, TomcatA 中的 session S2 超时. 当一个会话被用户标记失效时 invalidate 调用会被拦截, session 会被加入失效会话队列。此时,失效的会话不会被复制,直到另一个请求通过系统并检查无效队列。 Phuuuhh! :) Membership 集群成员关系关系是通过使用非常简单的多播ping建立的。每个Tomcat实例都会周期性地发送一个 multicast ping,在 ping 消息中包含 tomcat 实例自身的IP和配置的TCP监听端口。如果实例在一个给定的时间内没有收到这样的ping信息,就会认为那个成员down掉了。非常简单,非常有效!当然,您需要在您的系统上启用广播。 TCP Replication 一旦收到一个多播ping 包,在下一个复制请求时成员被添加到集群, 发送实例将使用的host 和 port 信息和建立TCP套接字。使用该套接字发送序列化的数据。我选择TCP套接字的原因是因为它建立了流量控制和保证交付。所以我知道,当我发送一些数据时,它就会到达那里 :) Distributed locking and pages using frames Tomcat在跨集群同步不保持会话实例。这种逻辑的实现将是多开销和导致各种各样的问题。如果你的客户用同一个会话同时发送多个请求,那么最后的请求将会覆盖集群中的其他会话。 在线 FAQ 请访问 在线 FAQ 的集群化相关部分.

  大型网站的挑战主要来自庞大的用户，高并发的访问和海量数据，任何简单的业务一旦需要处理数以P计的数据和面对数以亿计的用户，问题就会变得棘手。大型网站架构主要就是解决这类问题。 本文内容大部分来自《大型网站技术架构》。 来自：HollisChuang's Blog 链接：http://www.hollischuang.com/archives/1132    网站系统架构层次如下图所示：   1、前端架构  前端指用户请求到达网站应用服务器之前经历的环节，通常不包含网站业务逻辑，不处理动态内容。  浏览器优化技术  并不是优化浏览器，而是通过优化响应页面，加快浏览器页面的加载和显示，常用的有页面缓存、合并HTTP减少请求次数、使用页面压缩等。  CDN  内容分发网络，部署在网络运营商机房，通过将静态页面内容分发到离用户最近最近的CDN服务器，使用户可以通过最短路径获取内容。  动静分离，静态资源独立部署  静态资源，如JS、CSS等文件部署在专门的服务器集群上，和Web应用动态内容服务分离，并使用专门的（二级）域名。  图片服务  图片不是指网站Logo、按钮图标等，这些文件属于上面提到的静态资源，应该和JS、CSS部署在一起。这里的图片指用户上传的图片，如产品图片、用户头像等，图片服务同样适用独立部署的图片服务器集群，并使用独立（二级）域名。  反向代理  部署在网站机房，在应用服务器、静态资源服务器、图片服务器之前，提供页面缓存服务。  DNS  域名服务，将域名解析成IP地址，利用DNS可以实现DNS负载均衡，配置CDN也需要修改DNS，使域名解析后指向CDN服务器。   2、应用层架构  应用层是处理网站主要业务逻辑的地方。  开发框架  网站业务是多变的，网站的大部分软件工程师都是在加班加点开发网站业务，一个好的开发框架至关重要。一个号的开发框架应该能够分离关注面，使美工、开发工程师可以各司其事，易于协作。同时还应该内置一些安全策略，防护Web用攻击。  页面渲染  将分别开发维护的动态内容和静态页面模板集成起来，组合成最终显示给用户的完整页面。  负载均衡  将多台应用服务器组成一个集群，通过负载均衡技术将用户请求分发到不同的服务器上，以应对大量用户同时访问时产生的高并发负载压力。  Session管理  为了实现高可用的应用服务器集群，应用服务器通常设计为无状态，不保存用户请求上下文信息，但是网站业务通常需要保持用户会话信息，需要专门的机制管理Session，使集群内甚至跨集群的应用服务器可以共享Session。  动态页面静态化  对于访问量特别大而更新又不很频繁的动态页面，可以将其静态化，即生成一个静态页面，利用静态页面的优化手段加速用户访问，如反向代理、CDN、浏览器缓存等。  业务拆分  将复杂而庞大的业务拆分开来，形成多个规模较小的产品，独立开发、部署、 维护，除了降低系统耦合度，也便于数据库业务分库。按业务对关系数据库进行拆分，技术难度相对较小，而效果又相对较好。  虚拟化服务器  将一台物理服务器虚拟化成多态虚拟服务器，对于并发访问较低的业务，更容易用较少的资源构架高可用的应用服务器集群。  3、服务层架构  提供基础服务，供应用层调用，完成网站业务。  分布式消息  利用消息队列机制，实现业务和业务、业务和服务之间的异步消息发送及低耦合的业务关系。  分布式服务  提供高性能、低耦合、易复用、易管理的分布式服务，在网站实现面向服务架构（SOA）。  分布式缓存  通过可伸缩的服务器集群提供大规模热点数据的缓存服务，是网站性能优化的重要手段。  分布式配置  系统运行需要配置许多参数，如果这些参数需要修改，比如分布式缓存集群加入新的缓存服务器，需要修改应用程序客户端的缓存服务器列表配置，并重启应用程序服务器。分布式配置在系统运行期提供配置动态推送服务，将配置修改实时推送到应用系统，无需重启服务器。    4、存储层架构  提供数据、文件的持久化存储访问与管理服务。  分布式文件  网站在线业务需要存储的文件大部分都是图片、网页、视频等比较小的文件，但是这些文件的数量非常庞大，而且通常都在持续增加，需要伸缩性设计比较好的分布式文件系统。  关系数据库  大部分万丈的主要业务是基于关系数据库开发的，但是关系数据库对集群伸缩性的支持表较差。通过在应用程序的数据访问层增加数据库访问的路由功能，根据业务配置将数据库访问路由到不同的物理数据库上，可实现关系数据库的分布式访问。  NoSQL数据库  目前各种NoSQL数据库层出不穷，在内存管理、数据模型、集群分布式管理等 方面各有优势，不过从社区活动性角度看，HBase无疑是目前最好的。  数据同步  在支持全球范围内数据共享的分布式数据库技术成熟之前，拥有多个数据中心的网站必须在多个数据中心之间进行数据同步，以保证每个数据中心都拥有完整的数据。在实践中，为了减轻数据库压力，将数据库的事物日志（或者NoSQL的写操作Log）同步到其他数据中心，根据Log进行数据重演，实现数据同步。  5、后台架构  网站应用中，除了要处理用户的实时访问请求外，还有一些后台非实时数据分析要处理。  搜索引擎  即使是网站内部的搜索引擎，也需要进行数据增量更新及全量更新、构建索引等。这些操作通过后台系统定时执行。  数据仓库  根据离线数据，提供数据分析与数据挖掘服务。  推荐系统  社交网站及购物网站通过挖掘人与人之间的关系，人和商品之间的关系，发展潜在的人际关系和购物兴趣，为用户提供个性化推荐服务。  6、数据采集与监控  监控网站访问情况与系统运行情况，为网站运营决策和运维管理提供支持保障。  浏览器数据采集  通过在网站页面中嵌入JS脚本采集用户浏览器环境与操作记录，分析用户行为。  服务器业务数据采集  服务器业务数据包括两种，一种是采集在服务器端记录的用户请求操作日志；一种是采集应用程序运行期业务数据，比如待处理消息数目等。  服务器性能数据采集  采集服务器性能数据，如系统负载、内存使用率、网卡流量等。  系统监控  将前述采集的数据以图表的方式展示，以便运营和运维人员监控网站运行状况，做到这一步仅仅是系统监视。更先进的做法是根据采集的数据进行自动化运维，自动处理系统异常状况，是吸纳自动化控制。  系统报警  如果采集来的数据超过预设的正常情况的阀值，比如系统负载过高，就通过邮件、短信、语音电话等方式发出警报信号，等待工程师干预。  7、安全架构  保护网站免遭攻击及敏感信息泄露。  Web攻击  以HTTP请求的方式发起的攻击，危害最大的就是XSS和SQL注入攻击。但是只要措施得当，这两种攻击都是比较容易防范的。  数据保护  敏感信息加密传输与存储，保护网站和用户资产。  8、数据中心机房架构  大型网站需要的服务器规模数以十万计，机房物理架构也需要关注。  机房架构  对于一个拥有十万台服务器的大型网站，每台服务器耗电（包括服务器本身耗电及空调耗电）每年大约需要人民币2000元，那么网站每年机房电费就需要两亿人民币。数据中心能耗问题日趋严重，Google、Facebook选择数据中心地理位置的时候趋向选择散热良好，供电充裕的地方。  机柜架构  包括机柜大小，网线布局、指示灯规格、不间断电源、电压规格（是48V直流电还是220V民用交流电）等一系列问题。  服务器架构  大型网站由于服务器采购规模庞大，大都采用定制服务器的方式代替购买服务器整机。根据网站应用需求，定制硬盘、内存、甚至CPU，同时去除不必要的外设接口（显示器输出接口，鼠标、键盘输入接口），并使空间结构利于散热。  

大型网站的挑战主要来自庞大的用户，高并发的访问和海量数据，任何简单的业务一旦需要处理数以P计的数据和面对数以亿计的用户，问题就会变得棘手。大型网站架构主要就是解决这类问题。更多内容也可以阅读各大互联网公司架构演进之路汇总、大型网站架构演化历程两篇文章。 整体架构图 image.png 这个网站架构层次，共分为8个层次，其中数据库中心机房架构是上面所有架构的物理基础；安全架构和数据库采集监控架构是贯穿在各个层次的重要保障，这两个架构主要解决五个业务相关层次的安全问题和数据采集监控问题，是一直都需要关注的地方； 对于目前的大型网络来看，可以分为前端、应用层、服务层、存储层、后台等5个方面，简单来说，前端存放的是静态网页，不涉及业务，就是为了客户端能够及时响应，并展现一些静态内容；应用层是处理业务逻辑的地方，前端开发的代码，主要就是发布在这个地方，实际用户的各种业务处理，也主要在这个地方进行；服务层介于应用层和存储层之间，主要为两者提供各种分布式服务，比如分布式缓存，能减少存储层的压力，并尽快响应应用层的请求，提高性能；存储层是存放各种业务数据的地方，包括关系型、非关系型数据库、文件已经它们之间的数据同步；上面4个层次可以说是实时的业务功能，有一个层次出现问题，就会直接影响用户体验，在这4个层次后面，还有一个后台，它是不直接与用户沟通，但从上面的业务中通过搜索引擎、数据仓库、推荐系统等，创造更加有价值的信息，在后台为业务提供支撑。 1.前端架构 前端指用户请求到达网站应用服务器之前经历的环节，通常不包含网站业务逻辑，不处理动态内容。 浏览器优化技术 并不是优化浏览器，而是通过优化响应页面，加快浏览器页面的加载和显示，常用的有页面缓存、合并HTTP减少请求次数、使用页面压缩等。 CDN 内容分发网络，部署在网络运营商机房，通过将静态页面内容分发到离用户最近最近的CDN服务器，使用户可以通过最短路径获取内容。 动静分离，静态资源独立部署 静态资源，如JS、CSS等文件部署在专门的服务器集群上，和Web应用动态内容服务分离，并使用专门的（二级）域名。 图片服务 图片不是指网站Logo、按钮图标等，这些文件属于上面提到的静态资源，应该和JS、CSS部署在一起。这里的图片指用户上传的图片，如产品图片、用户头像等，图片服务同样适用独立部署的图片服务器集群，并使用独立（二级）域名。 反向代理 部署在网站机房，在应用服务器、静态资源服务器、图片服务器之前，提供页面缓存服务。 DNS 域名服务，将域名解析成IP地址，利用DNS可以实现DNS负载均衡，配置CDN也需要修改DNS，使域名解析后指向CDN服务器。 2.应用层架构 应用层是处理网站主要业务逻辑的地方。 开发框架 网站业务是多变的，网站的大部分软件工程师都是在加班加点开发网站业务，一个好的开发框架至关重要。一个号的开发框架应该能够分离关注面，使美工、开发工程师可以各司其事，易于协作。同时还应该内置一些安全策略，防护Web用攻击。 页面渲染 将分别开发维护的动态内容和静态页面模板集成起来，组合成最终显示给用户的完整页面。 负载均衡 将多台应用服务器组成一个集群，通过负载均衡技术将用户请求分发到不同的服务器上，以应对大量用户同时访问时产生的高并发负载压力。 Session管理 为了实现高可用的应用服务器集群，应用服务器通常设计为无状态，不保存用户请求上下文信息，但是网站业务通常需要保持用户会话信息，需要专门的机制管理Session，使集群内甚至跨集群的应用服务器可以共享Session。 动态页面静态化 对于访问量特别大而更新又不很频繁的动态页面，可以将其静态化，即生成一个静态页面，利用静态页面的优化手段加速用户访问，如反向代理、CDN、浏览器缓存等。 业务拆分 将复杂而庞大的业务拆分开来，形成多个规模较小的产品，独立开发、部署、维护，除了降低系统耦合度，也便于数据库业务分库。按业务对关系数据库进行拆分，技术难度相对较小，而效果又相对较好。 虚拟化服务器 将一台物理服务器虚拟化成多态虚拟服务器，对于并发访问较低的业务，更容易用较少的资源构架高可用的应用服务器集群。 3.服务层架构 提供基础服务，供应用层调用，完成网站业务。 分布式消息 利用消息队列机制，实现业务和业务、业务和服务之间的异步消息发送及低耦合的业务关系。 分布式服务 提供高性能、低耦合、易复用、易管理的分布式服务，在网站实现面向服务架构（SOA）。 分布式缓存 通过可伸缩的服务器集群提供大规模热点数据的缓存服务，是网站性能优化的重要手段。 分布式配置 系统运行需要配置许多参数，如果这些参数需要修改，比如分布式缓存集群加入新的缓存服务器，需要修改应用程序客户端的缓存服务器列表配置，并重启应用程序服务器。分布式配置在系统运行期提供配置动态推送服务，将配置修改实时推送到应用系统，无需重启服务器。 4.存储层架构 提供数据、文件的持久化存储访问与管理服务。 分布式文件 网站在线业务需要存储的文件大部分都是图片、网页、视频等比较小的文件，但是这些文件的数量非常庞大，而且通常都在持续增加，需要伸缩性设计比较好的分布式文件系统。 关系数据库 大部分万丈的主要业务是基于关系数据库开发的，但是关系数据库对集群伸缩性的支持表较差。通过在应用程序的数据访问层增加数据库访问的路由功能，根据业务配置将数据库访问路由到不同的物理数据库上，可实现关系数据库的分布式访问。 NoSQL数据库 目前各种NoSQL数据库层出不穷，在内存管理、数据模型、集群分布式管理等方面各有优势，不过从社区活动性角度看，HBase无疑是目前最好的。 数据同步 在支持全球范围内数据共享的分布式数据库技术成熟之前，拥有多个数据中心的网站必须在多个数据中心之间进行数据同步，以保证每个数据中心都拥有完整的数据。在实践中，为了减轻数据库压力，将数据库的事物日志（或者NoSQL的写操作Log）同步到其他数据中心，根据Log进行数据重演，实现数据同步。 5.后台架构 网站应用中，除了要处理用户的实时访问请求外，还有一些后台非实时数据分析要处理。 搜索引擎 即使是网站内部的搜索引擎，也需要进行数据增量更新及全量更新、构建索引等。这些操作通过后台系统定时执行。 数据仓库 根据离线数据，提供数据分析与数据挖掘服务。 推荐系统 社交网站及购物网站通过挖掘人与人之间的关系，人和商品之间的关系，发展潜在的人际关系和购物兴趣，为用户提供个性化推荐服务。 6.数据采集与监控 监控网站访问情况与系统运行情况，为网站运营决策和运维管理提供支持保障 浏览器数据采集 通过在网站页面中嵌入JS脚本采集用户浏览器环境与操作记录，分析用户行为。 服务器业务数据采集 服务器业务数据包括两种，一种是采集在服务器端记录的用户请求操作日志；一种是采集应用程序运行期业务数据，比如待处理消息数目等。 服务器性能数据采集 采集服务器性能数据，如系统负载、内存使用率、网卡流量等。 系统监控 将前述采集的数据以图表的方式展示，以便运营和运维人员监控网站运行状况，做到这一步仅仅是系统监视。更先进的做法是根据采集的数据进行自动化运维，自动处理系统异常状况，是吸纳自动化控制。 系统报警 如果采集来的数据超过预设的正常情况的阀值，比如系统负载过高，就通过邮件、短信、语音电话等方式发出警报信号，等待工程师干预。 7.安全架构 保护网站免遭攻击及敏感信息泄露。 Web攻击 以HTTP请求的方式发起的攻击，危害最大的就是XSS和SQL注入攻击。但是只要措施得当，这两种攻击都是比较容易防范的。 数据保护 敏感信息加密传输与存储，保护网站和用户资产。 8.数据中心机房架构 大型网站需要的服务器规模数以十万计，机房物理架构也需要关注。 机房架构 对于一个拥有十万台服务器的大型网站，每台服务器耗电（包括服务器本身耗电及空调耗电）每年大约需要人民币2000元，那么网站每年机房电费就需要两亿人民币。数据中心能耗问题日趋严重，Google、Facebook选择数据中心地理位置的时候趋向选择散热良好，供电充裕的地方。 机柜架构 包括机柜大小，网线布局、指示灯规格、不间断电源、电压规格（是48V直流电还是220V民用交流电）等一系列问题。 服务器架构 大型网站由于服务器采购规模庞大，大都采用定制服务器的方式代替购买服务器整机。根据网站应用需求，定制硬盘、内存、甚至CPU，同时去除不必要的外设接口（显示器输出接口，鼠标、键盘输入接口），并使空间结构利于散热。 文章来源：http://blog.csdn.net/yumushui/article/details/45563527

　这里只是介绍Web测试相对于其他类型软件的测试额外需要了解的内容，关于测试方法不是本文的重点，里面谈到的每一项在以后的文章中再说明。大家看到这些内容可能都不陌生，我晒出的内容也许不对或有误导，请大家指正。 　　1. HTTP/HTTPS协议 　　·   你应该去了解什么是http协议 　　·   什么是GET, POST, session, cookie等 　　·   Get与Post的区别是什么? 　　·   session与cookie的区别是什么? 　　·   什么是无状态？ 　　2. 浏览器机制 　　·   理解浏览器在处理javascript及渲染CSS的机制 　　·   了解IE与其他浏览器的差异 　　·   为什么兼容性测试时需要特别关注IE 　　·   浏览器在加载javascript，CSS有时在前面有时在后面，为什么？ 　　·   加载顺序会对视觉和使用上有什么影响呢？ 　　·   各种浏览器使用的内核分别是什么？ 　　3. web架构 　　也许你会说这是架构师的事儿，没错，基本是他们的活儿，但是理解了web架构能让我们测试的更深入。你要知道： 　　·   软件出错时怎么个报警法？是否有详尽的log记录？ 　　·   服务器缓存机制如何？ 　　·   数据库如何主从同步，如何备份的？ 　　·   集群如何处理session的？ 　4. 安全 　　因为web应用的特殊性，你需要掌握的安全技能： 　　·   如何进行SQL注入测试？如何防止SQL注入？ 　　·   什么是跨站脚本攻击(XSS)？如何开展此类测试，应该如何防范XSS？ 　　·   什么是DOS，DDOS？开发人员如何coding来避免？ 　　·   传输哪些重要数据时需要加密 　　·   哪些页面需要使用SSL/https来加密传输 　　·   什么是跨站伪造请求攻击 cross site request forgeries (XSRF)，如何避免？ 　　·   安全证书的意义，浏览器在证书失效时提示是怎样的？ 　　5. web性能 　　你应该知道的web性能知识： 　　·   web前端的性能极大影响了用户，如何观察这些数据？CSS和图片的合并压缩的意义 　　·   了解浏览器cache及服务端cache 　　·   对于图片请求过多的网站，为何要把图片放置在不同的域名下，最好使用CDN？ 　　·   确认你的网站有一个 favicon.ico 文件放在网站的根下，如 /favicon.ico.每当有用户收藏网站/网页时，浏览器会自动请求这个文件，就算这个图标文件没有在你的网页中明显说明，浏览器也会请求。如果你没有这个文件，就会出大量的404错误，这会消耗你的服务器带宽，服务器返回404页面会比这个ico文件可能还大 　　·   知道单个页面的http请求数越少越好 　　·   顺序加载和异步加载的优劣，何时需要使用AJAX？懒加载的意义，用于何处？ 　　·   如何使用性能测试工具Jmeter/LR等开展性能测试？ 　　6. SEO 　　只要是WEB应用，都会有SEO，因为它是种免费的搜索引擎推广方式，否则在百度搜索你们网站，是没有结果的。所以，你需要知道： 　　·   XML sitemap的意义，可以让搜索引擎了解你的网站地图 　　·  了解 robots.txt 和搜索引擎爬虫是如何工作的 　　·   搜索引擎喜欢什么样的URL？ 　　·   重定向301和302对于搜索引擎的意义？ 　　·   网页Meta信息中title，description等的重要性 　　7. 用户体验 　　网站的功能只是说实现了什么，而用户体验则诠释了做的有多好，用户使用起来是否有难度，是否会爱上这个网站（当然12306除外，咯咯） 　　·   访问网站的用户操作行为是怎么样的？页面的访问频率占比如何？因为测试的精力和侧重点也要根据这个数据而定 　　·   网站部署时是否会影响到用户使用，如何避免？ 　　·   不要直接显示不友好的错误提示，是否有友好的提示信息？ 　　·   web应用不能泄漏用户的隐私信息 　　·   页面是在当前页打开还是另开一个tab？ 　　·   页面元素的布局如何影响到用户体验的？ 　　8. 使用工具 　　·   HttpWatch，基于IE的网络数据分析工具，包括网页摘要，Cookies管理，缓存管理，消息头发送/接受，字符查询，POST 数据和目录管理功能等 　　·   FireBug，用途同上，基于firefox的 　　·   Yslow，前端网站性能工具，显示测试结果的分析,分为等级、组件、统计信息 　　·   Fiddler，强大的web前端调试工具，它能记录/拦截所有客户端和服务器的http和https请求，允许你监视，设置断点，甚至修改输入输出数据，也可用于安全测试 　　·   Chrome扩展程序：浏览器兼容性检测工具，分析网站的兼容性情况 　　·   ShowIP：显示访问网站的IP，web测试中你是否经常因为访问的网站IP不对，而被开发人员BS呢？它能帮助到你。 　　谈到的内容很多，囊括了诸多内容，也有些没有罗列出来，因为都太细节了，不是此文的范围。本来只是做了个Overview，抛砖引玉罢了，因为里面每一子项都可以成为一个专题。     最新内容请见作者的GitHub页：http://qaseven.github.io/    

“异地多活”是互联网系统的一种高可用部署架构，而“单元化”正是实现异地多活的一个解题思路。说起这个话题，不得不提两个事件：一件是三年多前的往事，另一件就发生今年的杭州云栖大会上。 从“挖光缆”到“剪网线” 2015年5月27日，因市政施工，支付宝杭州某数据中心的光缆被挖断，造成对部分用户服务不可用，时间长达数小时。其实支付宝的单元化架构容灾很早就开始启动了，2015年也基本上成型了。当时由于事发突然，还是碰到很多实际问题，花费了数小时的时间，才在确保用户数据完全正确的前提下，完成切换、恢复服务。虽然数据没有出错，但对于这样体量的公司来说，服务不可用的社会舆论影响也是非常大的。 527这个数字，成为蚂蚁金服全体技术人心中悬着那颗苦胆。我们甚至把技术部门所在办公楼的一个会议室命名为527，把每年的5月27日定为技术日，来时刻警醒自己敬畏技术，不断打磨技术。经过几年的卧薪尝胆，时间来到2018年9月。云栖大会上，蚂蚁金服发布了“三地五中心金融级高可用方案”。现场部署了一个模拟转账系统，在场观众通过小程序互相不断转账。服务端分布在三个城市的五个数据中心，为了感受更直观，把杭州其中一个数据中心机柜设置在了会场。工作人员当场把杭州两个数据中心的网线剪断，来模拟杭州的城市级灾难。网线剪断之后，部分用户服务不可用。经过26秒，容灾切换完成，所有受影响的用户全部恢复正常。这个Demo当然只是实际生产系统的一个简化模型，但是其背后的技术是一致的。这几年来，其实每隔几周我们就会在生产环境做一次真实的数据中心断网演习，来不断打磨系统容灾能力。 从大屏幕上可以看到，容灾切换包含了“数据库切换”“缓存容灾切换”“多活规则切换”“中间件切换”“负载均衡切换”“域名解析切换”等多个环节。异地多活架构是一个复杂的系统工程，其包含的技术内涵非常丰富，单场分享实难面面俱到。本场是微服务话题专场，我们也将以应用层的微服务体系作为切入点，一窥异地多活单元化架构的真面目。 去单点之路 任何一个互联网系统发展到一定规模时，都会不可避免地触及到单点瓶颈。“单点”在系统的不同发展阶段有不同的表现形式。提高系统伸缩能力和高可用能力的过程，就是不断与各种层面的单点斗争的过程。我们不妨以一个生活中最熟悉的场景作为贯穿始终的例子，来推演系统架构从简单到复杂，所遇到的问题。上图展示的是用支付宝买早餐的情景，当然角色是虚构的。最早支付宝只是从淘宝剥离的一个小工具系统，处于单体应用时代。这个时候移动支付当然还没出现，我们的例子仅用于帮助分析问题，请忽略这个穿帮漏洞。假设图中的场景发生在北京，而支付宝系统是部署在杭州的机房。在小王按下“支付”按钮的一瞬间，会发生什么事情呢？支付请求要从客户端发送到服务端，服务端最终再把结果返回客户端，必然会有一次异地网络往返，耗时大约在数十毫秒的数量级，我们用红色线表示。应用进程内部会发生很多次业务逻辑运算，用绿色圈表示，不涉及网络开销，耗时忽略不计。应用会访问多次数据库，由于都在部署在同一个机房内，每次耗时按一毫秒以下，一笔支付请求按10次数据库访问算（对于支付系统来说并不算多，一笔业务可能涉及到各种数据校验、数据修改）。耗时大头在无可避免的用户到机房物理距离上，系统内部处理耗时很小。到了服务化时代，一个好的RPC框架追求的是让远程服务调用像调本地方法一样简单。随着服务的拆分、业务的发展，原本进程内部的调用变成了网络调用。由于应用都部署在同一个机房内，业务整体网络耗时仍然在可接受范围内。开发人员一般也不会特别在意这个问题，RPC服务被当成几乎无开销成本地使用，应用的数量也在逐渐膨胀。 服务化解决了应用层的瓶颈，紧接着数据库就成为制约系统扩展的瓶颈。虽然我们本次重点讨论的是服务层，但要讲单元化，数据存储是无论如何绕不开的话题。这里先插播一下分库分表的介绍，作为一个铺垫。通过引入数据访问中间件，可以实现对应用透明的分库分表。一个比较好的实践是：逻辑拆分先一步到位，物理拆分慢慢进行。以账户表为例，将用户ID的末两位作为分片维度，可以在逻辑上将数据分成100份，一次性拆到100个分表中。这100个分表可以先位于同一个物理库中，随着系统的发展，逐步拆成2个、5个、10个，乃至100个物理库。数据访问中间件会屏蔽表与库的映射关系，应用层不必感知。 解决了应用层和数据库层单点后，物理机房又成为制约系统伸缩能力和高可用能力的最大单点。要突破单机房的容量限制，最直观的解决办法就是再建新的机房，机房之间通过专线连成同一个内部网络。应用可以部署一部分节点到第二个机房，数据库也可以将主备库交叉部署到不同的机房。这一阶段，只是解决了机房容量不足的问题，两个机房逻辑上仍是一个整体。日常会存在两部分跨机房调用： 服务层逻辑上是无差别的应用节点，每一次RPC调用都有一半的概率跨机房 每个特定的数据库主库只能位于一个机房，所以宏观上也一定有一半的数据库访问是跨机房的同城跨机房专线访问的耗时在数毫秒级，图中用黄色线表示。随着微服务化演进如火如荼，这部分耗时积少成多也很可观。 改进后的同城多机房架构，依靠不同服务注册中心，将应用层逻辑隔离开。只要一笔请求进入一个机房，应用层就一定会在一个机房内处理完。当然，由于数据库主库只在其中一边，所以这个架构仍然不解决一半数据访问跨机房的问题。这个架构下，只要在入口处调节进入两个机房的请求比例，就可以精确控制两个机房的负载比例。基于这个能力，可以实现全站蓝绿发布。“两地三中心”是一种在金融系统中广泛应用的跨数据中心扩展与跨地区容灾部署模式，但也存在一些问题。异地灾备机房距离数据库主节点距离过远、访问耗时过长，异地备节点数据又不是强一致的，所以无法直接提供在线服务。在扩展能力上，由于跨地区的备份中心不承载核心业务，不能解决核心业务跨地区扩展的问题；在成本上，灾备系统仅在容灾时使用，资源利用率低，成本较高；在容灾能力上，由于灾备系统冷备等待，容灾时可用性低，切换风险较大。 小结一下前述几种架构的特点。直到这时，微服务体系本身的变化并不大，无非是部署几套、如何隔离的问题，每套微服务内部仍然是简单的架构。 架构类型 优势 问题 单体应用 网络开销小 扩展性差，维护困难 单机房服务化 解耦，可扩展 容量受限，机房级单点 同城多机房阶段一 突破单机房容量瓶颈 非必要的跨机房网络开销大 同城多机房阶段二 非必要的跨机房网络开销小；机房级容灾能力 城市级单点 两地三中心 异地容灾能力 网络耗时与数据一致性难两全 蚂蚁金服单元化实践 蚂蚁金服发展单元化架构的原始驱动力，可以概括为两句话： 异地多活容灾需求带来的数据访问耗时问题，量变引起质变 数据库连接数瓶颈制约了整体水平扩展能力，危急存亡之秋 第一条容易理解，正是前面讨论的问题，传统的两地三中心架构在解决地区级单点问题上效果并不理想，需要有其他思路。但这毕竟也不是很急的事情，真正把单元化之路提到生死攸关的重要性的，是第二条。 到2013年，支付宝核心数据库都已经完成了水平拆分，容量绰绰有余，应用层无状态，也可以随意水平扩展。但是按照当年双十一的业务指标做技术规划的时候，却碰到了一个棘手的问题：Oracle数据库的连接不够用了。虽然数据库是按用户维度水平拆分的，但是应用层流量是完全随机的。以图中的简化业务链路为例，任意一个核心应用节点C可能访问任意一个数据库节点D，都需要占用数据库连接。连接是数据库非常宝贵的资源，是有上限的。当时的支付宝，面临的问题是不能再对应用集群扩容，因为每增加一台机器，就需要在每个数据分库上新增若干连接，而此时几个核心数据库的连接数已经到达上限。应用不能扩容，意味着支付宝系统的容量定格了，不能再有任何业务量增长。别说大促，可能再过一段时间连日常业务也支撑不了了。单元化架构基于这样一种设想：如果应用层也能按照数据层相同的拆片维度，把整个请求链路收敛在一组服务器中，从应用层到数据层就可以组成一个封闭的单元。数据库只需要承载本单元的应用节点的请求，大大节省了连接数。“单元”可以作为一个相对独立整体来挪动，甚至可以把部分单元部署到异地去。 单元化有几个重要的设计原则： 核心业务必须是可分片的 必须保证核心业务的分片是均衡的，比如支付宝用用户ID作分片维度 核心业务要尽量自包含，调用要尽量封闭 整个系统都要面向逻辑分区设计，而不是物理部署 在实践上，我们推荐先从逻辑上切分若干均等的单元，再根据实际物理条件，把单元分布到物理数据中心。单元均等的好处是更容易做容量规划，可以根据一个单元的压测结果方便换算成整站容量。 我们把单元叫做Regional Zone。例如，数据按100份分片，逻辑上分为5个Regional Zone，每个承载20份数据分片的业务。初期可能是部署成两地三中心（允许多个单元位于同一个数据中心）。随着架构的发展，再整单元搬迁，演化成三地五中心，应用层无需感知物理层面的变化。回到前面买早餐的例子，小王的ID是12345666，分片号是66，应该属于Regional Zone 04；而张大妈ID是54321233，分片号33，应该属于Regional Zone 02。应用层会自动识别业务参数上的分片位，将请求发到正确的单元。业务设计上，我们会保证流水号的分片位跟付款用户的分片位保持一致，所以绝大部分微服务调用都会收敛在Regional Zone 04内部。但是转账操作一定会涉及到两个账户，很可能位于不同的单元。张大妈的账号就刚好位于另一个城市的Regional Zone 02。当支付系统调用账务系统给张大妈的账号加钱的时候，就必须跨单元调用Regional Zone 02的账务服务。图中用红线表示耗时很长（几十毫秒级）的异地访问。从宏观耗时示意图上就可以比较容易地理解单元化的思想了：单元内高内聚，单元间低耦合，跨单元调用无法避免，但应该尽量限定在少数的服务层调用，把整体耗时控制在可接受的范围内（包括对直接用户体验和对整体吞吐量的影响）。 前面讲的是正常情况下如何“多活”，机房故障情况下就要发挥单元之间的容灾互备作用了。一个城市整体故障的情况下，应用层流量通过规则的切换，由事先规划好的其他单元接管。 数据层则是依靠自研的基于Paxos协议的分布式数据库OceanBase，自动把对应容灾单元的从节点选举为主节点，实现应用分片和数据分片继续收敛在同一单元的效果。我们之所以规划为“两地三中心”“三地五中心”这样的物理架构，实际上也是跟OceanBase的副本分布策略息息相关的。数据层异地多活，又是另一个宏大的课题了，以后可以专题分享，这里只简略提过。 这样，借助单元化异地多活架构，才能实现开头展示的“26秒完成城市级容灾切换”能力。 关键技术组件 单元化是个复杂的系统工程，需要多个组件协同工作，从上到下涉及到DNS层、反向代理层、网关/WEB层、服务层、数据访问层。总体指导思想是“多层防线，迷途知返”。每层只要能获取到足够的信息，就尽早将请求转到正确的单元去，如果实在拿不到足够的信息，就靠下一层。 DNS层照理说感知不到任何业务层的信息，但我们做了一个优化叫“多域名技术”。比如PC端收银台的域名是cashier.alipay.com，在系统已知一个用户数据属于哪个单元的情况下，就让其直接访问一个单独的域名，直接解析到对应的数据中心，避免了下层的跨机房转发。例如上图中的cashiergtj.alipay.com，gtj就是内部一个数据中心的编号。移动端也可以靠下发规则到客户端来实现类似的效果。 反向代理层是基于Nginx二次开发的，后端系统在通过参数识别用户所属的单元之后，在Cookie中写入特定的标识。下次请求，反向代理层就可以识别，直接转发到对应的单元。 网关/Web层是应用上的第一道防线，是真正可以有业务逻辑的地方。在通用的HTTP拦截器中识别Session中的用户ID字段，如果不是本单元的请求，就 forward到正确的单元。并在Cookie中写入标识，下次请求在反向代理层就可以正确转发。 服务层RPC框架和注册中心内置了对单元化能力的支持，可以根据请求参数，透明地找到正确单元的服务提供方。 数据访问层是最后的兜底保障，即使前面所有的防线都失败了，一笔请求进入了错误的单元，在访问数据库的时候也一定会去正确的库表，最多耗时变长，但绝对不会访问到错误的数据。 这么多的组件要协同工作，必须共享同一份规则配置信息。必须有一个全局的单元化规则管控中心来管理，并通过一个高效的配置中心下发到分布式环境中的所有节点。规则的内容比较丰富，描述了城市、机房、逻辑单元的拓扑结构，更重要的是描述了分片ID与逻辑单元之间的映射关系。 服务注册中心内置了单元字段，所有的服务提供者节点都带有“逻辑单元”属性。不同机房的注册中心之间互相同步数据，最终所有服务消费者都知道每个逻辑单元的服务提供者有哪些。RPC框架就可以根据需要选择调用目标。RPC框架本身是不理解业务逻辑的，要想知道应该调哪个单元的服务，信息只能从业务参数中来。如果是从头设计的框架，可能直接约定某个固定的参数代表分片ID，要求调用者必须传这个参数。但是单元化是在业务已经跑了好多年的情况下的架构改造，不可能让所有存量服务修改接口。要求调用者在调用远程服务之前把分片ID放到ThreadLocal中？这样也很不优雅，违背了RPC框架的透明原则。于是我们的解决方案是框架定义一个接口，由服务提供方给出一个实现类，描述如何从业务参数中获取分片ID。服务提供方在接口上打注解，告诉框架实现类的路径。框架就可以在执行RPC调用的时候，根据注解的实现，从参数中截出分片ID。再结合全局路由规则中分片ID与逻辑单元之间的映射关系，就知道该选择哪个单元的服务提供方了。 后记 本文着重介绍了蚂蚁金服异地多活单元化架构的原理，以及微服务体系在此架构下的关键技术实现。要在工程层面真正落地单元化，涉及的技术问题远不止此。例如：数据层如何容灾？无法水平拆分的业务如何处理？ 蚂蚁技术团队会坚持走技术开放路线，后续还会以不同的形式分享相关话题，也欢迎各位读者留言探讨。 长按关注，获取分布式架构干货 欢迎大家共同打造 SOFAStack https://github.com/alipay

2017阿里云网络技术高峰论坛在线技术峰会，阿里云卫峥带来题为高性能负载均衡设计与实现的演讲。本文主要从早期的负载均衡开始谈起，进而讲解了高性能负载均衡，着重分析了LVS和Tengine，以及如何做到高可用，最后作了简要总结。   以下是精彩内容整理： 负载均衡 负载均衡是云计算的基础组件，是网络流量的入口，其重要性不言而喻。 什么是负载均衡呢？用户输入的流量通过负载均衡器按照某种负载均衡算法把流量均匀的分散到后端的多个服务器上，接收到请求的服务器可以独立的响应请求，达到负载分担的目的。从应用场景上来说，常见的负载均衡模型有全局负载均衡和集群内负载均衡，从产品形态角度来说，又可以分为硬件负载均衡和软件负载均衡。全局负载均衡一般通过DNS实现，通过将一个域名解析到不同VIP，来实现不同的region调度能力；硬件负载均衡器常见的有F5、A10、Array，它们的优缺点都比较明显，优点是功能强大，有专门的售后服务团队，性能比较好，缺点是缺少定制的灵活性，维护成本较高；现在的互联网更多的思路是通过软件负载均衡来实现，这样可以满足各种定制化需求，常见的软件负载均衡有LVS、Nginx、Haproxy。 阿里云高性能负载均衡使用LVS和Tengine，我们在一个region区分不同的机房,每个机房都有LVS集群和Tengine集群，对于用户配置的四层监听，LVS后面会直接挂载用户ECS，七层用户监听ECS则挂载在Tengine上，四层监听的流量直接由LVS转发到ECS，而7层监听的流量会经过LVS到Tenigine再到用户ECS。每一个region里都会有多个可用区，达到主备容灾目的，每一个集群里都有多台设备，第一是为了提升性能，第二也是基于容灾考虑。 图为高性能负载均衡控制管理概要图，SLB产品也有SDN概念，转发和控制是分离的，用户所有配置通过控制台先到控制器，通过集中控制器转换将用户配置推送到不同设备上，每台设备上都有Agent接收控制器下发的需求，通过本地转换成LVS和Tengine能够识别的配置，这个过程支持热配置，不影响用户转发，不需要reload才能使新配置生效。   LVS LVS支持的三种模式 早期LVS支持三种模式，DR模式、TUN模式和NAT模式。DR模式经过LVS之后，LVS会将MAC地址更改、封装MAC头，内层IP报文不动，报文经过LVS负载均衡查找到RS之后，将源MAC头改成自己的，目的MAC改成RS地址，MAC寻址是在二层网络里，对网络部署有一定的限定，在大规模分布式集群部署里，这种模式的灵活性没有办法满足需求；TUN模式走在LVS之后，LVS会在原有报文基础上封装IP头，到了后端RS之后，RS需要解开IP报文封装，才能拿到原始报文，不管是DR模式还是TUN模式，后端RS都可以看到真实客户源IP，目的IP是自己的VIP，VIP在RS设备上需要配置，这样可以直接绕过LVS返回给用户，TUN模式问题在于需要在后端ECS上配置解封装模块，在Linux上已经支持这种模块，但是windows上还没有提供支持，所以会对用户系统镜像选择有限定。NAT模式用户访问的是VIP，LVS查找完后会将目的IP做DNAT转换，选择出RS地址，因为客户端的IP没变，在回包的时候直接向公网真实客户端IP去路由，NAT的约束是因为LVS做了DNAT转换，所以回包需要走LVS，把报文头转换回去，由于ECS看到的是客户端真实的源地址，我们需要在用户ECS上配置路由，将到ECS的默认路由指向LVS上，这对用户场景也做了限制。 LVS基于Netfilter框架实现 Netfilter是Linux提供的网络开放平台，基于平台可以开发自己的业务功能模块，早期好多安全厂商都是基于Netfilter做一些业务模型实现，这种模型比较灵活，但通用模型里更多的是兼容性考虑，路径会非常长；而且通用模型中没办法发挥多核特性，目前CPU的发展更多是向横向扩展，我们经常见到多路服务器，每路上有多少核，早期通用模型对多核支持并不是特别友善，在多核设计上有些欠缺，导致我们在通用模型上做一些应用开发时的扩展性是有限的，随着核的数量越来越多，性能不增反降。 LVS的改进 早期模式的各种限制制约了我们的发展，所以我们首先做了FullNAT，相比原来的NAT方式，FullNAT多了SNAT属性，将客户端的原IP地址作了转换；其次，我们在并行化上做了处理，充分利用多核实现性能线性提升；然后是快速路径，我们在做网络转发模型时很容易想到设计快速路径和慢速路径，慢速路径更多是解决首包如何通过设备问题，可能需要查ACL或路由，需要判断许多和策略相关的东西，后面所有报文都可以通过快速路径转发出去；还有指令相关优化，利用因特尔特殊指令提升性能；另外针对多核架构，NUMA多节点内存访问，通过访问Local节点内存可能获得更好的延迟表现。 客户端进来IP首先访问LVS的VIP，原IP是客户端的，目的IP是LVS的VIP，经过FullNAT转换后，原IP变成LVS的Local地址，目的地址是LVS选择出来的RS地址，这样在RS回包时比较容易，只要路由可达，报文一定会交到LVS上，不需要在RS上做特殊的配置。右面就是DNAT+SNAT转换，报文就可以通过LVS转发回客户端，这种方式主要带来应用场景部署灵活性选择。 通过并行化实现对LVS性能的改善，性能没有办法得到线性提升更多的是因为每条路径都需要访问全局资源，就会不可避免引入锁的开箱，另外，同一条链接上的报文可能分散在不同的核上，大家去访问全局资源时也会导致cache的丢失。所以我们通过RSS技术把同一个五源组报文扔到同一个CPU上处理，保证入方向的所有相同连接上的报文都能交给相同CPU处理，每个核在转发出去时都用当前CPU上的Local地址，通过设置一些fdir规则，报文回来时后端RS访问的目的地址就是对应CPU上的local地址，可以交到指定的CPU上去处理，这样一条连接上左右方向报文都可以交给同一个CPU处理，将流在不同的CPU隔离开；另外，我们把所有配置资源包括动态缓存资源在每个CPU上作了拷贝， 将资源局部化，这使整个流从进入LVS到转发出去访问的资源都是固定在一个核上的本地资源，使性能达到最大化，实现线性提升。 经过我们改进之后，LVS的具体表现如下： 出于对容灾和性能提升的考虑，我们做了集群化部署，每个region有不同机房，每个机房有多个调度单元，每个单元有多台LVS设备； 每台LVS经过优化后，都能达到更高性能，大容量，单台LVS可以达到4000W PPS，600W CPS、单个group可以到达1亿并发； 支持region、IDC、集群和应用级的高可用； 实现了防攻击功能，并在原版LVS上提供了更丰富的功能，可以基于各个维度做管理控制，精确的统计，流量的分析等。   Tengine Tengine在应用过程中也遇到了各种问题，最严重的就是性能问题，我们发现随着CPU数量越来越多，QPS值并没有线性提升；Nginx本身是多worker模型，每个worker是单进程模式，多worker架构做CPU亲和，内部基于事件驱动的模型，其本身已经提供了很高的性能，单核Nginx可以跑到1W5～2W QPS。Nginx往下第一层是socket API，socket 往下有一层VFS，再往下是TCP、IP，socket层比较薄，经过量化的分析和评估，性能开销最大的是TCP协议栈和VFS部分，因为同步开销大，我们发现横向扩展不行，对此，我们做了一些优化。 七层反向代理的路径更长，处理更复杂，所以它的性能比LVS低很多，我们比较关注单机和集群的性能，集群性能可以靠堆设备去解决，单机如果不提升，成本会一直增加，从性能角度来看，有以下的优化思路和方向： 基于Kernel做开发，比如优化协议栈； 基于Aliscoket的优化，Alisocket是阿里研发的高性能TCP协议栈平台，底层是DPDK，它将资源做了局部化处理，报文分发不同核处理，性能非常出色； HTTPS业务越来越多，流量逐步递增，我们采用硬件加速卡方式做一些加解密的性能提升，还有HTTPS的会话复用； 基于Web传输层的性能优化。 从弹性角度看，比如一些公司的应用和用户热点有关，当发生一个社会网络热点后，访问量会急剧变高，我们固有的基于物理机器实现的负载均衡模型在弹性扩展方面是有限制的，对此，我们可以使用VM去做，把反向代理功能放在VM去跑，我们会监控实例负载情况，根据实时需求做弹性扩容缩容；除了VM，还有调度单元，我们可以在不同调度单元做平滑切换，根据不同的水位情况，通过切换可以把负载均衡实例调度到不同的单元中去，改善使容量上管理。Tengine本身也做了集群化部署，我们在一个region里有不同的机房，不同的调度单元，每个调度单元有多组设备；LVS到Tengine也有健康检查，如果一台Tengine有问题，可以通过健康检查方式摘除，不会影响用户转发能力；Tengine具备灵活的调度能力，可以帮助我们应对更多的复杂情况；另外，Tengine也有很多高级的特性，比如基于cookie的会话保持、基于域名/URL的转发规则、HTTP2、Websocket等功能；目前，我们7层单VIP可以支撑10W规格的HTTPS QPS。   高可用 Group 高可用是整个产品很重要的一部分，图为集群内的高可用架构图，可以看到，在网络路径上是全冗余无单点的。具体情况如下： 双路服务器，每节点双网口上联不同交换机，增加带宽，避免跨节点收包 VIP路由两边发不同的优先级，不同的VIP，高优先级路由在不同的交换机上 单机160G转发能力，单VIP 80G带宽，单流 40G带宽 网卡故障不影响转发，上下游路由自动切换 ECMP，VIP路由发两边，通过优先级控制从入口 集群640G转发能力，单vip 320G带宽 会话同步，多播、包触发同步、定时同步 单机故障不影响转发 交换机故障不影响转发，路由秒级切换 用户无感知的升级变更，部分未及时同步的连接重连即可 AZ 每个机房连接两个不同路由器，当一个AZ出现故障之后，我们可以无缝切换到另外一个机房，具体情况如下： VIP在不同的AZ发不同优先级的路由（秒级切换、自动切换） VIP区分主备AZ，不同的VIP主备AZ不同 多个AZ的负载通过控制系统分配 缺省提供VIP多AZ的容灾能力 不支持跨AZ的session同步，跨AZ切换后，所有连接都需要重连 Region 当用户访问域名时，通过DNS解析，可以设定DNS解析到多个regionVIP地址，下沉到某一个Region来看，如果一个机房出现故障，流量可以切换到另一个可用区继续转发，如果流量进到机房发现一台LVS转发设备出现故障后，我们可以切换到另外一台LVS作处理，如果LVS后面挂载的RS出现问题，通过健康检查也可以快速摘掉设备，将流量转换到健康的设备上去。我们从多个维度实现高可用，最大限度的满足用户的需求。   总结 目前，高性能负载均衡应用主要在几个方面： 1.         作为公有云基础组件，为公有云网站、游戏客户、APP提供负载均衡功能，也针对政府、金融等安全性高的客户提供专有云支持； 2.         为阿里云内部云产品RDS、OSS、高防等提供了负载均衡的功能； 3.         负载均衡作为电商平台入口，向淘宝、天猫、1688提供VIP统一接入功能； 4.         交易平台的流量入口也在负载均衡设备上，如支付宝、网上银行。 未来，我们希望有更好的弹性扩展能力，更高的单机处理能力，我们希望VIP主动探测用户，以及网络全链路监控。  [卫峥1]响应

除非另外注明，否则，下面介绍的更改均适用于最新 Chrome Beta 渠道版（Android、Chrome 操作系统、Linux、Mac 和 Windows）。 CSS 网格布局 人们使用从大型 LCD 电视到小型表盘等各种尺寸屏幕访问网站的情况越来越多。在过去，支持所有这些屏幕尺寸需要复杂的标记和 CSS 组合，让代码变得难以维护。为使开发者能够更精细地控制元素的缩放以适合当前屏幕尺寸， CSS 网格布局现已推出。 CSS 网格支持二维基于网格的布局系统，该系统专门针对自适应用户界面设计进行了优化。可指定网格内的元素跨多行或多列。还可以给定位在 CSS 网格中的元素命名，这使布局代码更容易理解。 CSS 网格允许开发者将元素置于网格上的任意位置，并可全面控制元素流、尺寸调整行为和自适应性。 改进了 Add to Home Screen 从早期版本的 Chrome（Android 版）起，用户就可以将网站添加到主屏幕，实现快速而又方便的访问。该功能利用 Android 快捷方式添加图标，这意味着网络应用在整个 Android 系统内的呈现方式不同于安装的本机应用。 从此版本开始，当用户将一个 Progressive Web App 添加到其主屏幕时，Chrome 将其集成到 Android 中时会大幅提高集成深度。例如，Progressive Web App 现在会出现在启动器的应用抽屉式导航栏部分以及 Android 设置中，并且可以接收来自其他应用传入的 intent。长按其通知还会显示标准 Android 通知管理控件而非适用于 Chrome 的通知管理控件。 Media Session API 媒体消费是移动网络最常见的用途之一。在 Chrome（Android 版）中，开发者可以利用新的 Media Session API，使用媒体内容自定义锁定屏幕 UI 和通知。通过向浏览器提供有关所播放内容的元数据，开发者可以创建丰富的锁定屏幕消息，在其中加入名称、音乐人、专辑名称和封面等信息。此外，网站现在还可以响应用户对通知本身执行的操作（例如搜寻或跳过）。 此版本中的其他特性 当一段视频在 Android 设备上进入全屏模式时，Chrome 现在会自动根据视频的纵横比锁定屏幕方向。 现在，如果网站使用连续的 setTimeout()，在使用循环来推动视图外帧动画时将受到限制，从而可为用户改善性能。 Fetch API Response 类现在支持 .redirected 属性，以帮助网络开发者避免不可信响应以及降低开放重定向器的风险。 新增的 padStart 和 padEnd 格式设置工具可实现文本填充，可以简化调整控制台输出或打印固定位数数字之类的任务。 服务工作线程导航预载现在以来源试用版形式提供，让开发者能够并行处理主要资源网络请求与服务工作线程启动。 Payment Request API 可在 iframe 内提供，通过添加 allowpaymentrequest 属性来实现。 PaymentMethodData 现在支持 basic-card，这样一来，开发者不必使用不同数据类型，只需通过单个方法标识符便可引用所有卡类型。 为简化从 HTTP 到 HTTPS 的迁移，现在存储的 HTTP 表单凭据将转移至 HTTPS 版本的网站，Credential Management API 现在支持从匹配的子域名填充凭据。 caret-color 属性让开发者可以指定文本输入光标的颜色。 为与其他 on 属性保持一致，ongotpointercapture 和 onlostpointercapture 现已成为 GlobalEventHandlers mixin 的组成部分。 现已提供对 text-decoration-skip: ink 的支持，以使下划线跳过下伸部分，即字母中延伸到文本基线之下的部分。 新的 text-decoration 属性现已推出，让开发者可以指定线条颜色和线型等视觉效果。 PresentationRequest 构造函数经修改后可通过 sequence 接受多个网址，这是对只能接受单个网址的现有构造函数的补充。 新增的 AudioContext.getOutputTimestamp() 方法让开发者能够将 DOMHighResTimeStamp 与 AudioContext.currentTime 的值同步。 AudioBufferSourceNode、OscillatorNode 和 ConstantSourceNode 现在从 AudioScheduledSourceNode 继承，从而实现了功能合并。 新增的 cancelAndHoldAtTime 函数可以取消未来的 AudioParam 事件，前提是这些事件的时间大于或等于 cancelTime，这样一来，开发者便可直接保留计划时间的值。 开发者现在可以构建 WebAudio-specific 事件，例如 OfflineAudioCompletionEvent 和 AudioProcessEvent。 为提高用户安全性，Chrome 的 XSS Auditor 现在默认情况下阻止整个可疑页面，而不是有选择地滤除页面上可疑的反射 XSS。 弃用和互操作性的改善 已取消对 元素的支持，从而使它不再显示任何控件，也不提交表单元素数据，以便与其他浏览器保持一致。 正如之前宣布的那样，本地可信 SHA-1 证书现在会引发证书错误页面，除非设置了 EnableSha1ForLocalAnchors 企业政策。 fieldset.elements 现在会返回 HTMLCollection 而非 HTMLFormControlsCollection，以便改善与规范的符合性。 移除了 元素，但仍可通过 cursor CSS 属性设置光标图标。 从 HTMLEmbedElement 和 HTMLObjectElement 中移除了一个旧版调用方，因此现在接口会引发异常，而不是让系统以函数形式调用其实例。 usemap 属性现在要求匹配时区分大小写。 所有 -webkit- 前缀的 IndexedDB 全局别名都已移除，这是它们在 M38 中被弃用的后续措施。 自定义消息事件和 client.postMessage(message, transfer) 在服务工作线程中创建的事件现在使用 MessageEvent 来替代 ServiceWorkerMessageEvent，以遵循 HTML MessageEvent 规范扩展。 对 webkitClearResourceTimings()、webkitSetResourceTimingBufferSize() 和 onwebkitresourcetimingbufferfull 的支持已从 Performance 接口中移除，由 clearResourceTimings()、setResourceTimingBufferSize() 和 onresourcetimingbufferfull 取代。 下列 -internal CSS 选择器已弃用：-internal-media-controls-cast-button、-internal-media-controls-overlay-cast-button 以及所有 -internal-media-controls-text-track-list 选择器。 已取消对过时 API webkitCancelRequestAnimationFrame 的支持，由 cancelAnimationFrame 取代。 在 Android 上，默认情况下 wordWrap: break-word 和 -webkit-line-break: after-white-space 将不再于 contenteditable 容器上进行设置，以保持浏览器之间的一致性。 webkit 前缀已从 AudioContext 和 OfflineAudioContext 中移除。 本文来自开源中国社区 [http://www.oschina.net]