IzIy's Files

web项目通常由于需求紧，任务重，在上线初期，通常不会考虑太多架构性以及可靠性的问题。因此在业务稳定增长的过程中，大多都存在一个持续优化的过程。

这里记录一下前段时间，因某业务需要，对其持续优化的过程。

业务包括两个数据部分，一个负责实时数据上报的client，一个是负责数据接收以及实时数据展示的web系统。

优化目标有两个，一个是保证实时数据从收集到展示的延迟尽可能短，另一个是提高业务的可扩展性，保证业务的吞吐量不被一台服务器瓶颈所限制。

主要的操作包括静态资源加速，数据上报通道优化，服务器分布差异导致的延迟问题等。

web服务原始架构：

Client为安装在客户终端设备中的一个程序，浏览器为客户的其它带屏终端。Web Server为部署的服务器。

登录：

Client ==(认证信息)==> Web Server ==(返回服务URL)==> Client显示

授权通过后，Client开始收集数据并上传，客户通过Client显示的URL，在浏览器中加载完素材后，便有如下数据流。

Client ==(post提交)==> Web Server ==(Get阻塞轮询)==> 客户浏览器

在上线初期，我仅用了一台1c2g的服务器完成了这些业务流程。

带来的问题可而知，

带宽消耗型资源与延迟敏感性资源同时访问时产生冲突，容易造成实时展示效果短暂性中断，业务的不可扩展性导致分布式应用无法展开。

在第一步的优化中，将大量静态资源通过CDN网络进行加速，也是对带宽消耗型资源进行分离。

这样减轻了对服务器的带宽消耗。

第二步，增加数据上传通道，由于post提交包含HTTP/TCP的链接，握手，数据打包传输，下发反馈等过程，不利于快速数据交换。因此，在服务器端另开UDP服务，使得数据上传更加快速。

数据流变成如下所示

客户A/B浏览器   <===静态数据===  (CDN服务器)
-------------------------
ClientA ==实时数据==>(post提交) \                                   / 客户A浏览器
                               〉==> Web Server <==(Get阻塞轮询)==>
ClientB ==实时数据==>(UDP上传)  /                                   \ 客户B浏览器

第三步，分离数据通道，实现分布式架构。

由于Client之间的数据互不关联，互不影响。多个Client可使用不同的Server来实现数据交换。此外，不同Client位于不同地域，在合适的地域建立的Server，使得数据链路在物理空间上尽可能的短。

因此，通过分离Login与数据交互功能，形成LoginServer与DataServer便有了如下新的架构，

Client ==(认证信息)==> LoginServer ==(返回服务URL与DataServer)==> Client显示
在此背后，LoginServer ==>(认证信息)==>DataServer(1or2)

ClientA ==实时数据==>(post提交) ==> DataServer1<==(Get阻塞轮询)==>客户A浏览器
ClientB ==实时数据==>(UDP上传)  ==> DataServer2<==(Get阻塞轮询)==>客户B浏览器