企业应用上云过程中系统架构的适应性研究

李旗

【摘要】    在科技时代所赋予的挑战面前，以信息化数字化赋能产业发展，实现企业数字化转型，是各行业的当务之急。企业快速上云，依托智能化手段提质增效，也是企业发展的关键所在。而各领域的企业应用从传统的局域网环境迁移至云上后出现一些新的状况，如经常有用户反馈“本来好好的系统，为何上云后就变慢了呢？”笔者发现企业应用上云的过程中，往往未做详细调研，忽视应用架构的调整适应，在云部署工作中生搬硬套地使用了局域网环境的方法，这会引起意料之外的问题;其中有何需要关注的呢？在本文中，笔者将运用两个实际案例，讲解关注应用架构对优化云业务效率的意义所在。

【关键词】    上云    适应性    企业

一、案例一：某医院业务上云后问题排查

1.1 背景

客户的业务迁移到移动云后，出现较大的延迟情况;客户打开业务系统非常缓慢，之前服务端部署在该医院内网环境中，打开系统只需要1秒;而上云后约要30秒左右才能打开页面，用户严重怀疑移动云网络或主机性能瓶颈，需要移动云管理人员尽快解决该故障;

附：前期排查进展：1.客户侧时延为30ms左右，为安徽-->上海资源池;2.通过fiddler抓到请求，发现客户的应用为CS架构，客户端访问云端的是SQL 数据库业务。

1.2 分析过程

1.2.1网络传输质量评估

从局域网环境中抓包，以及在云环境中提取访问过程的数据，放在回溯系统上进行比较，图1左边是服务端再局域网内的访问过程，右边的视图是用户通过专线访问部署在云上的业务系统的访问过程。

这两组会话，均没有丢包重传，网络延迟也很稳定，访问同一个业务产生的数据报文均为1580个包左右，其中客户端向服务端发送了765次请求，服务端都回复了数据。

这两个唯一的区别，内网的网络延迟为0.8ms，云中的网络延迟为25ms;这点可以从图1 TCP三次握手过程可以看到。

1.2.2交互过程分析

平时访问游戏、主流的网页，网络延迟50ms以下都算不错了;而这个医院用户部署在移动云内的应用，在其访问过程中的网络延迟为25ms，应该属于“优秀水平”。

咋眼看去似乎25ms比0.8ms也没大多少，对吧？其实不然，请看图2。

如图2右边的交互视图中可以看到，从第4个包开始，客户端向服务端发起了第一次请求，每次新的请求，距离上一次应答的时间约为25.9ms至38.9ms之间;而左边的交互视图中，每次的应答时间距离上一次应答的时间约为0.8ms至5ms之间;如此，经过765次的请求和应答后，会话的结束过程如下图3所示。

图3中左边，局域网内传输1580个包，用了1.05秒就完成这个过程;而从右边的视图中可以看到，一次访问需要约765次的请求和应答的前提下，经过每次25ms至30ms的“加持”，总的过程经历了21秒后才完成了相同的过程。

1.3 小结与建议

1.3.1小结

用户的业务采用CS架构：①客户-->② CS客户端-->③SQL服务端，上述②和③之间，每次业务打开和运行的时候均需要有大量的数据交互;当业务在同个局域网运行，其中的延迟用户也许近似无法感知。不过把“③SQL服务端”架设在移动云上之后，用户感受到的延迟就呈现数量级的上升，延迟上升的幅度取决于业务交互的次数。

1.3.2优化建议

1.初步建议用户调整数据库部署的资源池，如果迁移到淮南节点，理论上网络延迟降到10ms之内，用户打开业务的时间，可从20+秒减少至10秒以下;

2.建议用户调整业务的访问逻辑关系，采用BS的架构;或者CS架构中，客户-->应用-->数据库的业务流程中，应用和数据库同时上云，就能彻底解决延迟的问题。

二、案例二：某资源池用户和阿里云间调用postman问题分析

2.1 背景

客户的部分业务迁移到移动云后，出现较大的延迟情况;如下图所示，客户部署在杭州阿里云IP地址为47.xx.xxx.22的业务访问已迁移至移动云雅安节点IP地址为36.xx.xxx.65（tcp）的业务过程中，发现移动云响应杭州阿里这个地址的时候比较慢，达到14.78秒。

网络环境和业务流程：

图4

2.2 分析过程

1.从移动云的回溯系统中调取数据，经分析后可见用户反馈访问慢的时间段内，移动云和阿里云IP为47.96.119.93的地址间产生了接近300KB的流量，峰值流量约为200Kbps，持续了15秒左右，如图5所示。

2.从22：23：27开始，看到阿里云IP 47.xx.xxx.93向移动云内网IP 10.xx.xxx.17 POST了164次http：// yunnan.xxxxxxxx.com：81/zsa/......的请求，移动云每次均回复200 OK，服务端回复的延迟都很快，均低于0.01秒;最后一次访问过程的结束时间为22：23：41，从第一次开始访问至末次访问结束刚好14秒多。（图6）

3.而在这164的请求响应过程中，每次请求间隔大约为0.09秒，从图7中的“日期时间”可见。

4.进一步分析每次访问的过程，这些请求响应表现相近，均如图8所示。

图8

关于图8中的三次握手和四次挥手，稍微延伸解释一下，端到端的通信过程中为了建立TCP连接，通信双方必须从对方了解这些信息：1）对方报文发送的开始序号。2）对方发送数据的缓冲区大小。3）能被接收的最大报文段长度MSS。4）被支持的TCP选项。因此双方通过三次TCP报文实现对以上信息的了解，并在此基础上建立一个TCP连接;而通信双方的三次TCP报文的交换过程，也就是通常所说的TCP连接建立實现的三次握手（Three-Way Handshake）过程。

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。这就是通常所说的“四次挥手”的过程。

因为篇幅关系，关于三次握手和四次挥手的交互细节，在本文中笔者不展开讲述。

如之前的会话交互所示，建立会话时间和结束会话的总时间为0.08秒左右;会话各环节的时间占比如右图所示：

三次握手和四次挥手，均和网络延迟有关，从阿里云到移动云之间的网络延迟为39ms左右。（图9）

每次请求都需要新建一次TCP会话，每次新的会话都需要等上一次的会话结束才能开始。

2.3 小结与建议

2.3.1小结

从上文的分析过程可得，在现有的应用架构中，每次的业务操作，需要分解为很多次的HTTP短链接，而短链接状态中每一个会话持续时间0.09（秒） X 164（次） = 14.76秒，这就是导致部分业务迁移到移动云后，调用阿里云接口慢（14.78秒）的主要原因。

2.3.2优化建议

根据交互内容，建议应用采用长连接，减少不必要的网络建链和拆链过程，可有效降低时延。

2.3.3说明

在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这段代码：Connection：keep-alive;在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

2.4 优化后效果评估

经管理人员与研发人员讨论后，对业务模式做了调整，用户采用了长连接的会话方式调用移动云;后续对该业务进行跟踪分析， 如图10所示，修改后无数据交互时，阿里云IP47.xx.xxx.22和云主机10.xx.xxx.123之间，每隔4.95秒进行一次数据同步，维持会话的长连接状态。

图10

有业务产生的时候，客户端直接调用移动云接口时，会通过47.xx.xxx.22的9333端口直接访问移动云主机，这时候，只有两个TCP会话产生数据产生。（图11）

阿里云IP一次性把所有数据传到移动云主机。（图12）

这样的调用效率高，所以延迟就比较低，用户体验明显提升，而记录到的时间延迟也大幅度降低了（从14.78秒减少至1.479秒）。（图13）

三、结束语

在前文章节中的两个案例，笔者作为主要分析人员参与了故障定位与优化的过程，从而体会非常深刻，网络延迟从局域网的“1毫秒”到互联网的“30毫秒”，虽然只是增加了29毫秒，然而这短短的“29毫秒”，经过交互次數的乘法后，对业务的开展影响竟然如此巨大。

本文案例一让我们明白，“客户-->应用-->数据库”的流程中，“应用”和“数据库”必须同时上云，通过减少长距离的交互次数，可有效降低业务延迟，如图14所示。

本文案例二让我们明白，业务拆分或者部分应用上云后，如果拆分部分的交互次数较多的情况下，应用的连接方式需从短链接长连接，通过减少不必要的网络建链和拆链过程，可有效降低业务的整体时延。

两个案例产生的根因是相同的：多次交互+单次延迟增加。

笔者建议企业应用在上云的过程中，做好调研工作，特别需要关注业务的逻辑关系和产生数据的交互过程，必要的情况下，适度调整应用架构以适应云环境的使用。