应用性能优化记录之一——应用往云上迁移所带来的新挑战

        年前接手了一个项目，因为刚接手，业务熟悉等花去了必定的时间。因此很长时间没有写

博客了。又是一年大促季，再加上公司新建机房，应用往云上迁移的时机已经来了。从4月中开

始，就开始了这苦逼的填坑生活。 这其中遇到了不少问题，所以把这些填坑方法记录下来，分

享给你们。

         该系统是一个网络IO开销类型的应用。日访问量较高。最开始的请求应答架构示意图以下：

 

       

 

       分析一下这个请求--应答过程。首先一个请求过来，前端CDN会挡住一部分流量。若是离用

户最近的CDN有数据，由CDN直接返回数据。CDN做为系统的第一层公用缓存来使用。

       假如CDN没有数据。那么CDN将回源站获取数据。在应用和CDN之间，咱们搭建了一层私

有缓存层来减轻后端应用的压力。这一层的方案采用nginx+lua来实现。同时在这些前置机上自

建redis。 为何要在本机建redis呢？ lua读取redis的时候，由于redis在本机，这样作会减小网

络IO开销。提高吞吐量。当请求过来的时候，CDN没有，回源到前置机，若是前置机lua读取本

机redis有数据，那么就直接返回数据，请求将再也不继续往下走到应用服务器。这一层，做为整

个应用的第二层缓存来存在。

       那么假如第二层缓存依然没有数据，怎么办呢？？

       这个时候，请求会继续回源到应用服务器，由应用层响应该请求。同时在前置机的redis把

最新的响应结果写入进去，有效期默认设置为10分钟。10分钟缓存的设置，是由于假如后端数

据有变更的话，须要回到应用层拿到最新的数据。10分钟的缓存，在咱们的可接受范围以内。

       这就是以前的整个访问架构。该套系统日处理PV可达亿级。能应对较大的风险。但在接手

系统以后，就遇到了一个棘手的问题：根据公司须要，应用所有往私有云上迁移。

       首先是基础服务的迁移。其实这些都还好。由于是有专业的运维人员，因此像用到的

mysql、jimdb等都顺利迁移。等到应用往云上迁移的时候，问题来了。前置机上的nginx+lua环

境部署好了。redis也搞好了。可是整个系统测试发现，因为docker容器的不稳定，致使常常lua

读取不到数据，异常。一时间你们都傻眼了。由于以前是性能杠杠的物理机，这套系统也好好

的没有出什么错。没想到一往云上迁移，就出问题了。

       好吧，遇到问题也没辙，联系docker、云专家等反馈问题。获得的答复就是：不要在容器

上本身装redis使用。这样的话，就意味着系统架构要发生变更。

      这TM简直是晴天霹雳好吗？怎么办呢？请听下回分解