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

         接上回，既然docker中安装redis有各类各类的问题，短期内专家又解决不了的话，那么

考虑以后，只能变动当前系统的架构

第一种，舍弃掉前置缓存层，以下图：

        

 

   舍弃掉这一层以后，好处就是应用往云上迁移的工做基本就完成了。可是更大的问题是坏

处。没有这一层以后，全部请求只要穿透CDN，直接就会打到后端应用上，形成应用不小的压

力。一番衡量以后，以为仍是内心没底，放弃。

 

      第二种方案，沿用以前的架构，放弃每一个前置机docker自建redis的作法，lua去远程redis集

群中获取数据。这种作法，虽然相比以前的物理机时代增长了网络IO的开销，可是尽可能最小的

改动原有的架构，可使应用平滑迁移到云上。这是改过以后的架构：

 

    

      注意图中蓝色部分，前置机链接的缓存集群和后端应用使用的缓存集群是一个。 这里采用

公司本身包装的redis中间件-jimdb。lua脚本经过AP方式链接jimdb。

        当请求穿透CDN时，仍然是前置机lua去jimdb缓存拿出数据，如取到数据，就直接返回；

取不到数据，回源到应用层，应用层响应以后，把数据写入缓存。

      这样改过以后，应用终于迁移到云上了。大出一口长气。然而接下来针对单机房整个应用的

性能数据显示。集群最高TPS为2000+每秒，远远没有达到咱们6000+的预期指标。

      此时此刻，咱们仍是有信心的，既然达不到，那就优化吧。因而决定继续对整个系统代码和

架构作一些调整。到底怎么作的呢？请听下回优化详解