3.携程架构实践 --- 用户接入

第3 章 用户接入 
3．1 GSLB 技术 
		xc拥有多个数据中心，每一个数据中心都会提供部分应用程序服务，如何将用户的访问调度到最合适的数据中心是基于gslb技术实现的。gslb是 
	global server load balance 的缩写，意思是全局负载均衡。gslb 调度的规则包括：基于一定比例的负载均衡调度，网站的运行状况和响应能力，
	用户的接入运营商链路，以及数据中心的距离等。

		gslb 技术对于类型xc的多数据中心网站的作用包括：
			1.提升网站可用性
			2.提升网站的扩展性
			3.提升用户访问性能

	3．1．1 GSLB 系统概述 
		典型的gslb技术可以使用智能dns实现，用户在访问网站时，首先需要通过dns解析获得网站的ip地址，通常宽带用户会使用本地运营商提供的Local DNS
	发起dns解析，而使用智能dns发起dns解析，可以根据配置的多种策略灵活的将所请求解析的域名解析到不同数据中心的网站ip地址上，以达到全局负载均衡gslb
	的目的。

		基于智能dns的gslb技术应该具备如下功能：
			1.根据用户的地理位置及运营商线路路由到最合适的数据中心。
			2.监控每一个数据中心的运行情况，计算可用性和负载状况。
			3.使用管理策略控制和优化多数据中心部署。
			4.满足国家/地区特定的限制和监管要求。

	3．1．2 DNS 工作方式 
		典型的用户通过域名访问网站时获取网站ip地址的步骤:
			1.客户端web浏览器尝试使用url连接该网站，并通过本地ISP提供的dns发起域名解析；
			2.本地isp dns 服务器在 Internet的根dns服务器中查询权威dns服务器；
			3.根dns服务器返回ctrip.com的权威dns服务器地址；
			4.本地isp dns服务器查询 ctrip.com 的权威服务器；
			5.ctrip.com的权威dns服务器返回本地isp dns服务器域名 www.ctrip.com 对应的ip地址(从本地isp dns服务器向权威dns服务器进行查询，
			称为递归查询)；
			6.本地isp dns 服务器将查询到的ip地址返回客户端web浏览器，浏览器得到ip地址后，与其建立通信。

	3．1．3 GSLB 工作原理 
		1.客户端web浏览器在本地isp dns服务器查询 www.ctrip.com 域名对应的ip地址；
		2.本地isp dns 服务器在 Internet 的根dns服务器中查询权威dns服务器；
		3.根dns服务器返回 ctrip.com 的权威dns服务器地址；
		4.本地isp dns服务器查询 ctrip.com 的权威dns服务器；
		5.ctrip.com 的权威dns服务器返回本地 isp dns 服务器域名 www.ctrip.com 对应的 cname，如 www.ctripgslb.com(由智能dns提供的Zone)；
		6.本地isp dns服务器通过根dns服务器查询到 ctripgslb.com 的权威dns服务器，并向 ctripgslb.com 的权威dns服务器查询 www.ctripgslb.com的解析结果；
		7.ctripgslb.com 的权威dns(智能dns)，根据预先设置的路由规则，并通过用户isp dns的地理位置(通常用户的isp dns 服务器与真实用户位于相同的
		地理位置)，以及健康监测结果，返回最适合的ip地址作为解析结果；
		8.本地isp dns服务器将查询到的ip地址返回给客户端web浏览器，浏览器得到具体的ip地址后，与其建立连接。

3．2 CDN 
	cdn 是 Content Delivery Network的缩写，意思是内容网络分发，也称为内容传送网络。

	cdn 不托管内容且无法取代web服务器，但它确实有助于在网络边缘缓存内容，从而提高网站性能。它利用缓存减少自身数据中心的带宽消耗，有助于防止服务中断
和提供安全性。
	
	CDN 中有几个重要的概念：
		1.Edge Server(边缘服务器)
			用户直接请求的服务器，此服务器会缓存用户大量请求的内容，往往这类服务器离用户特别近。边缘服务器尽量和访问用户处于同一网络，同一地理位置，
		以达到最高的访问速度。

		2.Middle Server(中间层服务器)
			或者称为Parent Server(父节点服务器)，这类服务器的特点是存储容量特别大，在边缘服务器上无法缓存的内容，会缓存在中间层服务器中，而这类
		服务器和边缘服务器会通过优化的网络进行通信，以保证通信质量，从而快速获取内容。

		3.Origin Server(源站服务器)
			真正提供内容的服务器，即在用户请求的内容，而边缘服务器和中间层服务器都没有缓存内容时，用户的请求所最终到达的服务器。

		4.Last Mile(最后一公里)
			用户到边缘服务器的通信距离。

		5.First Mile(第一公里)
			源站服务器到cdn的第一服务节点的通信距离。

	3．2．1 CDN 静态加速
		CDN 静态加速 是指将目标内容缓存在cdn边缘服务器和中间层服务器来提升用户访问性能的机制，这些内容主要是静态的html页面内容，js文件，css文件，
	图像文件，音频文件，视频文件和可以下载的内容等。

		cdn判断是否对内容进行缓存主要是基于http协议中的头信息定义的，其中最终要的是Expires和Cache-Control。

		Expires是指缓存过期时间，超过这个时间就代表资源过期了。Expires是 http/1.0 的标准，现在更倾向于使用 http/1.1 中定义的Cache-Control，
	如果二者同时存在，则Cache-Control的优先级更高。

		Cache-Control 由多个字段组合而成，主要有几个取值：
			1.max-age
				指定一个时间长度，在这个时间段内缓存是有效的，单位是秒。例如，Cache-Control:max-age=31536000，缓存1年。
			2.s-maxage
				同max-age，覆盖max-age,Expires，但仅适用于共享缓存，在私有缓存中会被忽略。
			3.public
				表明响应可以被任何对象(发送请求的客户端，代理服务器等)缓存。
			4.private
				表明响应只能被单个用户(可能是操作系统用户，浏览器用户)缓存，是非共享的，不能被代理服务器缓存。
			5.no-cache
				强制所有缓存了该响应的用户，在使用已缓存的数据前，发送带验证器的请求到服务器中。
			6.no-store
				禁止缓存，每次请求都要向服务器重新获取数据。

		对于缓存在cdn的数据而言，在max-age规定的时间内发生变化，cdn都会发生刷新缓存的服务，频繁的使用刷新服务本身对于cdn系统并不友好，所以通常的
	做法是，在用户访问的url时使用基于版本的query string方式定义不同的url，cdn会根据query string进行不同的缓存。

	3．2．2 CDN 动态加速 
		CDN 动态加速是对访问的网站的速度进行优化的网络技术。cdn静态加速将文件缓存在于用户距离"最后一公里"的边缘服务器上，而cdn动态加速主要通过优化
	cdn内部网络链路，优化tcp/ip协议栈参数，内部使用专线互连等技术手段，在用户请求达到边缘服务器后，经过cdn内部网络快速达到源站服务器，并将源站服务
	器的响应返回给用户。

		CDN 动态加速的主要技术手段如下：
			1.智能选路
				通常用户访问源站服务器时，会经过isp的运营商网络，isp运营商网络因多家网络互连而有多条路径，所以出于成本考虑或者链路带宽的考虑，用户
			直接访问源站服务器不一定是最优路径。智能选路是指cdn在去除"最后一公里"和"第一公里"的内部网络中，不断使用检测手段，计算出网络的最快路径，
			并将用户请求通过最快路径传送到源站服务器。

			2.长连接
				在用户和边缘服务器建立连接后，cdn内部网络会建立一个tcp长连接通道，并复用这个连接和源站服务器进行通信。

			3.tcp优化
				cdn内部网络是高效网络，会对tcp协议栈中针对弱网络的参数进行优化。

			4.专线连接
				对于特殊场景而言，在cdn内部网络中会使用特殊的网络通道，避免Internet网络拥塞。

		cdn动态加速主要解决源站部署在单一运营商网络的情况，而xc面对的是互联网上不同运营商加入的全球用户。

	3．2．3 CDN 动态域名切换 
		针对不同的地区，不同的网络环境，各种cdn的性能表现可能是不同的。比如，一些cdn服务提供商针对国内用户的性能提升比较出色，而另外一些cdn服务
	提供商针对国外用户的性能提升更有优势，所以出现了一种被称为"融合cdn"的概念，用于针对各家不同cdn服务提供商进行优势互补，以及在特定服务提供商出现
	问题时提供备选方案并快速切换。

		传统的cdn服务是通过业务域名dns指向cdn服务提供商提供的cname实现的，所以在切换cdn服务提供商时，就需要调整dns。这种方式会收到dns ttl的
	影响，导致生效时间较长，并且gslb是根据用户的Local DNS 定位用户的地理位置的，可能会因为用户的Local DNS 配置不正确，造成偏离用户真实的地理
	位置的情况发生。

		针对这个痛点，xc自主研发了一套动态域名切换方案，其实现原理是用户请求basepage时，由服务器根据用户的ip地址进行判断，选择用户所在区域的最合适
	的cdn服务提供商，并在basepage中动态生成对应的资源域名。

		具体来说，对于中国用户而言，在basepage中生成的资源域名可能是：
			https://cn.static-ctrip.com/foo.js

		对于欧洲用户而言，在basepage中生成的资源域名可能是：
			https://eu.static-ctrip.com/foo.js

		其中，cn,eu 分别指向不同的cdn服务提供商，在出现问题时候，可以通过修改basepage中对应资源域名的方式进行快速切换，并且这种切换对用户立即。

3．3 App 端接入 
	app 端接入的场景有以下几个特征：
		1.用户的网络接入环境更复杂，更多变，不仅需要考虑 宽带，3g，4g网络，还需要考虑由于 网络漫游 和用户不断移动而 切换基站 的场景，同时dns劫持
		的现象也是比较严重的。
		2.连接的协议选择性更大，不同于浏览器以http/https协议进行访问，app端可以直接使用tcp建立长连接，并且可以控制连接的目标数量。

	xc 在app端用户接入上的主要实现方式为 "配置下发+性能探测"，并以域名解析作为保底方案。app端会预置一份服务端的ip地址列表，并在建立连接时对地址
列表中的ip地址进行性能探测，从而选择性能最好的目标建立长连接，同时在建立长连接后，会不断的监控性能和可用性指标，一旦发现指标不够理想，就重新进行探测
并建立连接。

3．4 负载均衡 
	3．4．1 负载均衡器工作原理 
		负载均衡器作为网络设备，主要功能是将收到的客户端数据包进行修改并转发到后端真实服务器，以实现负载均衡的目的。数据包的修改方式与负载均衡器和
	后端真实服务器所在的网络环境有着密切关系，主要分为以下3种：
		1.路由模式
			路由模式，或称为网关模式，会将到达负载均衡器的数据包的目的ip地址改变，然后转发到后端服务器。这种部署方式比较常见，这是因为后端服务器
		指向负载均衡器，能获取用户真实的ip地址。
			缺点是，会对已有的网络架构进行比较大的改动，使后端服务器所有的流量都经过负载均衡器，当同网段服务器访问vip时，需要在后端服务器上配置
		主机路由。负载均衡器无法对此模式启用连接复用。

		2.单臂模式
			单臂模式，又称为全NAT模式，会将到达负载均衡器的数据包的源ip地址和目的ip地址都改变，然后转发到后端服务器。这种模式较为常见，它对现有的
		网络改动最小，只有访问vip的流量才会经过负载均衡器。
			缺点是，后端服务器无法获得用户的真实ip地址。

		3.DSR模式
			DSR模式，或称为三角传输模式，会将到达负载均衡器的数据包的目的MAC地址改变，然后转发到后端服务器。这种模式下，后端服务器响应数据不经过
		负载均衡器，适合请求数据量小但响应数据大的情况，如 数据库查询，视频点播等，后端服务器能获取用户真实的ip地址。
			缺点是，后端服务器需要配置回环网卡，并禁用回环网卡的ARP广播，配置比较复杂；后端服务器响应数据不经过原来的路径，会产生路径不一致的问题，
		需要在网络中特地设置防火墙；和路由模式一样，负载均衡器无法对此模式启用连接复用。


	3．4．2 负载均衡优化手段 
		对http应用进行优化，主要由5大手段组成：
			1.tcp连接复用
				tcp连接复用可以将前端多个用户的http请求复用得到后端与服务器建立的一个tcp连接上。这种技术能够大大减小服务器的性能负载，缩短客户端
			与服务器之间建立tcp连接所造成的延时，并最大限度降低客户端对后端服务器的并发连接数，减少服务器的资源占用。

			2.内容缓存
				内容缓存技术可以将应用服务器中的一些常被用户访问的热点内容缓存在负载均衡的内存中。

			3.tcp缓冲
				tcp缓冲技术可以解决后端服务器与客户端网速不匹配所造成的服务端资源浪费问题。由于服务器与负载均衡器之间的网络带宽速率高，时延短，
			因此将服务端的请求缓冲在负载均衡器的缓冲区中，可以防止客户端较慢的网络连接速度和较长的时延造成的服务端的连接阻塞问题。

			4.http压缩
				http协议在v1.1中新增了压缩功能，如果客户端浏览器和服务器都支持压缩功能，则通过客户端和服务器进行协商，对客户端的响应内容进行压缩
			处理，可以大幅节省响应内容在传输时所需要的带宽，并加快客户端的响应速度。但是，压缩算法本身需要消耗大量的cpu资源，因此，负载均衡器对http
			压缩功能进行支持，可以减少web服务器的资源消耗，提高其处理效率。另外，由于负载均衡器一般采用硬件的方式进行压缩，因此，压缩的效率更高。

			5.ssl加速
				在ssl通信中，首先采用非对称密钥技术交换认证信息，并交换服务器和浏览器之间用于加密数据的会话密钥，然后利用该密钥对通信过程中传输的
			信息进行加密和解密。

				ssl是一种需要消耗大量cpu资源的安全技术。目前，大多数负载均衡器均采用ssl加速芯片进行ssl信息处理。这种方式与传统服务器的ssl加速
			方式相比，可以提高ssl的处理性能，从而节省大量的服务器资源，使服务器专注于业务请求的处理。另外，采用集中的ssl处理，还可以简化对证书的
			管理。

	3．4．3 负载均衡算法 
		1.轮询算法
		2.加权轮询算法
		3.最少连接算法
		4.加权最少连接算法

	3．4．4 负载均衡会话保持
		会话保持，又称为 粘滞会话(Sticky Sessions)，是指负载均衡器的一种机制，可以识别客户端与服务器之间进行交互的前后关联性，在实现负载均衡
	的同时还可以保证有关联的访问请求尽可能被分配到同一台后端服务器上。

		负载均衡器有以下几种会话保持方式：
			1.用户源ip地址会话保持(四层)
				用户源ip地址会话保持 就是将同一个用户源ip地址的连接和请求作为同一个用户，根据会话保持策略，在会话保持有效期内，将这些来自同一个
			用户源ip地址的连接和请求都转发到同一台服务器上。缺点是，当用户在企业网络内部访问互联网资源时，需要通过代理服务器访问；一些移动终端采用
			4g方式访问互联网资源时，运营商会通过代理网关访问互联网资源。但无论是通过代理服务器还是通过代理网关，发起连接请求时的源ip地址都是固定的。

			2.http cookie 会话保持(七层)
				在http cookie的模式下，负载均衡器负责插入cookie，后端服务器无需改变。当用户第一次请求时，用户的http request(不带cookie)会
			进入负载均衡器，负载均衡器会通过负载均衡算法选择一台后端服务器，并将请求转发给该后端服务器；后端服务器的http response(不带cookie)
			会被返回给负载均衡器，负载均衡器会在将http response返回给用户的同时，按照算法添加后端服务器信息并插入cookie中。

				当用户再次请求发生时，http request会携带上次负载均衡器插入的cookie信息，负载均衡器会读出cookie里面的会话保持数值，将http 
			request(带有与上面同样的cookie)发送到指定的服务器中，然后由后端服务器进行请求回复。

				http cookie 方式对非http协议无效，如果用户禁用了cookie，也会无效。

			3.http url 哈希会话保持(七层)
				在http url 哈希模式下，用户请求的url会根据某个哈希因子及后台存在的服务器数量计算所得到的结果，选择将请求分配到哪台服务器。http
			url 哈希会话保持的特点是在后台服务器健康状态不变的情况下，每一个特定的哈希因子被分配到的服务器是固定的。http url 哈希会话最大的优势是
			可以没有会话保持表，而仅仅根据计算的结果确定将请求分配到哪台服务器，尤其是在一些会话保持表的查询开销已经远远大于哈希计算的开销的情况下，
			采用http url哈希会话保持表可以提高系统的处理能力和响应速度。

				http url 哈希会话保持通常用于采用cahce服务器的应用场景。

3．5 软负载系统SLB 
	3．5．1 SLB 的产生背景
		问题的根源是 应用间的解耦，最好的方案是单机单应用。对于基于http/https协议的单机多应用来说，区分同一台服务器上不同的应用依靠的是请求中的
	path和domain。

	3．5．2 SLB 的架构设计 
		slb 的架构设计，分别从 总体架构，系统架构，建模，生效流程。

		用户请求先到硬件负载均衡器，硬件负载均衡器转发到slb，slb负责将请求转发到具体的应用服务器上。前面是tcp，后面是http协议。

		slb的用途可以抽象出几个核心的功能：
			1.路由
			2.负载均衡
			3.健康监测
			4.集群管理

		slb由4个子系统构成，具体如下：
			1.Nginx
				负责根据策略接收请求和转发请求。
			2.Agent
				和nginx在服务器上进行配对部署。agent负责接收外部策略，并将其转换为nginx可以理解的Conf，控制nginx生效，同时负责收集日志，聚合
			信息，管理ssl证书，更新waf规则等。
			3.SLB API
				对外负责提供api，通过api方式接收请求，将请求转换为元数据存储到DB中；对内负责和agent通信，通过api调用告知agent需要执行的指令。
			4.SLB Portal
				图像管理界面。

		建模对任何一个产品都至关重要，可以说是一个产品的灵魂所在，这是因为后续产品的构建的所有操作和产品可以提供的功能都是由数据模型决定的。数据模型
	还决定着产品质量，灵活性和可扩展性。DevOps 不是让所有研发都成为专业的运维，而是让研发人员可以进行运维。

		为了达到这个目的，需要将slb的数据模型和研发人员的现有知识体系进行融会贯通。同时将这个模型转换成nginx conf。

		研发：访问入口 => 协议+域名+端口+uri => 一组机器
		SLB：模型 => SLB => VS => Group => Member
		Nginx：Nginx Cluster => Server => Location => Upstream

		将研发人员熟悉的 应用，域名，URI，Path，服务器集群映射到slb的数据模型上:
			1.SLB ：一个具体的slb集群
			2.VS：Virtual Server，协议+域名+端口，代表一个vs实例
			3.Group：一个应用在slb中的一个投影，即一个应用在slb的所有配置构成的一个Group实例
			4.Member：Group 下面的一个成员节点，可以接受请求，对应一组服务器中的一台服务器。但这是一个逻辑概念，比如，一台服务器上部署了多个应用，
			就会在多个Group中产生多个Member，虽然它们对应同一台服务器，但在slb中它们互不影响，也没有任何关系。


		构建slb的数据模型建模原则：
			1.抽象出slb的核心模型：slb,vs,group
			2.Group是一个应用在slb中的一个投影
			3.slb中所有的操作抽象为对Group模型的操作
			4.slb中不同的Group之间的更新操作互不影响

		用户绝大多数的操作会转化为对Group对象的操作，而这些操作如何在nginx上生效呢？设计了 多版本化，操作日志，两阶段提交机制。
			1.多版本化
			2.操作日志
			3.两阶段提交

	3．5．3 SLB 实现的几个难点 
		1.配置文件变更效率问题
			nginx的配置基于一个文本文件，如果要变更配置，就需要更改此文件的内容，然后重新加载。同理，对Group配置进行的变更，最终会转化为对此文件
		的写操作。

			为了实现Group变更不影响，并确保所有的Group变更操作在一个稳定的返回时间内，slb确定了核心业务流程：
				1.将一段时间内(2s)的所有Group操作缓存在一个任务队列中；
				2.对任务队列中的所有操作进行合并，最终只对nginx的配置文件进行一次更新。

		2.健康监测瓶颈问题

		3.多用户运维冲突问题
			多状态机制：
				1.为每种角色分配一个服务器状态
				2.一种角色对一个服务器状态进行了失效操作，就只能由该角色对其进行恢复操作
				3.slb在所有角色都认为这台服务器有效时，才会认为这台服务器可接入流量


3．6 API Gateway 
	API Gateway 负责几乎全部的用户请求，包括来自移动app，H5站点，微信，支付宝，小程序，合作伙伴的请求。

	3．6．1 API Gateway 的架构设计 
		API Gateway 的优点：
			1.内外网分离
				即外网客户端和内网服务解耦，在保持外网客户端不变的情况下，可以通过这个中间层调整内网服务的实现，如多版本比较，服务升级，服务拆分
			合并，还可以对请求进行加工，如增加Header等；

			2.规范化
				由于请求是 API Gateway 统一接收和分发的，会促使客户端在发送请求和接收请求时实现规范化，并且各部门采用相同的技术，有助于服务治理，
			降低复杂度，统一开发人员技术栈，降低人力成本；

			3.安全
				由于API Gateway 具有收口的作用，所有的安全问题可以在此集中解决，从而保护内网，如集成反爬功能和认证功能；

			4.限流，熔断
				在API Gateway 上实现限流，熔断，限流可以避内网被突发流量压垮，熔断可以在服务出现问题时给与服务恢复的机会；

			5.监控告警
				可以在API Gateway 上进行流量监控和流量告警。

		API Gateway 的核心功能：
			1.路由分发
			2.反爬，认证
			3.请求加工
			4.跨域处理
			5.限流，隔离，熔断
			6.监控告警

		1.SOA协作集成
		2.Filter机制
			1.Inbound(预处理) : 用在向后端服务转发请求前，如反爬功能；
			2.Route(路由) : 将请求向后端服务转发的执行者，如限流，熔断功能；
			3.Outbound(后处理) : 用在向后端服务转发请求后，开始接收响应的阶段，如在响应中增加一些Header;
			4.Error(错误) : 在上述阶段发生错误后，跳转到此阶段进行处理。

		3.动态部署

	3．6．2 API Gateway 在携程的使用 
		API Gateway 7大网关：
			1.HTTP Gateway：核心网关，用于处理用户的http api 请求，如h5站点；
			2.TCP Gateway：核心网关，用于处理用户的tcp请求，如移动app;
			3.PCI Gateway：支付网关，用于处理和支付相关的高安全性请求；
			4.Ctrip Group Gateway：xc集团网关，用于处理xc集团分公司之间的api请求；
			5.WebSocket Gateway：小程序网关，支持 websocket 协议，用于处理微信，支付宝的小程序api网关；
			6.Affiliation Gateway：同盟商网关，用于处理公司合作伙伴的api请求；
			7.Message Gateway：消息网关，可以将消息通过订阅的方式暴露。

		API Gateway 的一个重要功能是构建访问标准；另外一个重要的功能是性能优化。为了提升请求速度，成功率，稳定性，API Gateway 和无线框架一起
	构建了app请求的tcp隧道，将http请求包装成私有的tcp请求在app和API Gateway 之间进行传输。

		app请求的tcp隧道的工作机制如下：
			1.前端开发人员在移动app中通过一个ajax方式发送一个http请求；
			2.无线框架会劫持这个请求，将其包装成一个私有tcp协议请求，并发往tcp Gateway；
			3.tcp gateway 在接收到请求后，会将请求剥离，还原成一个http请求，并发往目标服务；
			4.目标服务在收到http请求后，会处理并返回一个http响应；
			5.http响应经历相同的包装和剥离过程。

		以上可以看出，前后端开发处理的都是http请求和响应，而网络通信使用的是tcp私有协议，整个过程对开发没有增加工作。此机制的3个优势：
			1.可以避免dns劫持
			2.提供性能，因为省略了dns解析且使用率可控的长连接
			3.可以提高请求成功率，因为完全接管了网络通信，可以进行灵活多变的路由选择并使用重试。