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

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

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

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

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

　　推荐阅读：计算机信息管理在企业中的应用