为移动图片和传统图片搭座桥
传统web应用图片不适合为手机用户服务，因为手机用户不需要大图，不想花太多的流量；<br>另一方面我们传统的图片保留下来的有xT，不可能在未知那些图片的情况下，把所有可能的图片<br>做一个转换。<br> 所以需要为现有无线应用和传统图片搭一座桥，这桥的作用是：在手机用户访问的时候<br>实时进行图片转换。面临的问题是：现有的web server是一个进程服务一个用户，那它是忙不过来；<br>另一方面现有的转换图片的工具(<span style="font-weight: bold;">imagemagick</span>)比较耗能，所以这次新架构主要客服这两方面<br>的问题。<br><br>简单架构图：<br><div align="center"><img src="http://blogimg.chinaunix.net/blog/upfile2/110526140430.jpg" onload="javascript:if(this.width>500)this.width=500;" border="0"></div><br><!--><xml><w:WordDocument><w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel><w:DisplayHorizontalDrawingGridEvery>0</w:DisplayHorizontalDrawingGridEvery><w:DisplayVerticalDrawingGridEvery>2</w:DisplayVerticalDrawingGridEvery><w:DocumentKind>DocumentNotSpecified</w:DocumentKind><w:DrawingGridVerticalSpacing>7.8</w:DrawingGridVerticalSpacing><w:View>Normal</w:View><w:Compatibility></w:Compatibility><w:Zoom>0</w:Zoom></w:WordDocument></xml><!--><p class="p0" style="margin-bottom:0pt; margin-top:0pt; "><span style="mso-spacerun:'yes'; font-size:12.0000pt; font-family:'宋体'; ">Nginx：进行分派作用，先暂时做URL Hash；</span><span style="mso-spacerun:'yes'; font-size:12.0000pt; font-family:'宋体'; "></span></p><p class="p0" style="margin-bottom:0pt; margin-top:0pt; "><span style="mso-spacerun:'yes'; font-size:12.0000pt; font-family:'宋体'; ">IMG-SERVER：把任务放进队列中，并肩负通知Nginx；</span><span style="mso-spacerun:'yes'; font-size:12.0000pt; font-family:'宋体'; "></span></p><p class="p0" style="margin-bottom:0pt; margin-top:0pt; "><span style="mso-spacerun:'yes'; font-size:12.0000pt; font-family:'宋体'; ">IMG-Worker：从队列中取出任务，进行处理，并将处理到的数据传送会Nginx相应的Root；</span><span style="mso-spacerun:'yes'; font-size:12.0000pt; font-family:'宋体'; "></span></p><p class="p0" style="margin-bottom:0pt; margin-top:0pt; "><span style="mso-spacerun:'yes'; font-size:12.0000pt; font-family:'宋体'; ">HttpSQS：任务队列，进行队列的存储。</span><span style="mso-spacerun:'yes'; font-size:12.0000pt; font-family:'宋体'; "></span></p><br><br><br><br>简单架构概况：nginx->image-server->httpsqs->worker<br> nginx : 利用其url hash 尽量保持到后端image-server中的url唯一；<br> image-server： 接受用户的请求，维护着与用户的链接，与worker进行通信；<br> httpsqs：存储任务；<br> worker:进行图片处理或其它工作（例如：进行redis写入）。<br><br>为了一个进程能服务多个访问用户，使用一个异步的动作，这异步是利用jetty 异步servlet进行<br>（tomcat和resin 4.0以后 都支持了这个异步servlet -- servlet 3.0）<br>httpsqs：已队列形式进行存储任务。<br><br>简单架构图：<br><div align="center"><img src="http://blogimg.chinaunix.net/blog/upfile2/110525102052.jpg" onload="javascript:if(this.width>500)this.width=500;" border="0"></div><br>nginx把请求发到一个内嵌jetty的server，jetty server把相应任务存进队列中后继续服务其它用户。<br>worker从httpsqs中读取任务，从相应的地方把图片拿回来然后进行处理，处理完后通知回jetty server，<br>server中相应的服务线程会唤醒与用户的通信，如果处理中出现问题则向用户返回default.jpg。<br><br><br>代码流程图<br><div align="center"><img src="http://blogimg.chinaunix.net/blog/upfile2/110525101636.jpg" onload="javascript:if(this.width>500)this.width=500;" border="0"><br><div style="text-align: left;"><br>从左往右看：用户->ImgServlet.java->TaskManaget.java->httpsqs;<br> worker(从httpsqs取出任务)->systemshell.java->AdminServlet.java->TaskManager.java-><br>ImgServlet.java->用户<br><br>上面为应用层的架构。<br><br>下面是对处理图片进行性能提升。<br><br>主要将三个功能进行合并以下为每个处理图片方法的性能数据：<br>convert 单线程 16.47分钟 6进程并发 30分钟 imageMagick load 22左右<br>python 脚本 单线程 15.38分钟 6进程并发 3.8分钟 python gil load 11左右<br>gm convert 单线程 13.46分钟 6进程并发 28分钟 g imagemagick load 22左右<br>econvert 单线程 10.5分钟 6进程并发 2.5分钟
exact-image load 7左右<br><br><br>为啥要将三个结合使用？<br>econvert 没按比例缩放功能<br>（<br>查看起源码，应该是有的，但估计因为性能上的问题，所以取了不少功能。<br>如代码中所示（exact-image-0.8.4/codecs 中头文件定义Codecs.hh --c++）<br> virtual bool scale (Image& image, double xscale, double yscale);<br>）<br>没有对png和gif处理的功能。但耗能低，速度快，质量能保证。<br><br>convert<br>能满足我们的所有需求，质量能达到要求，但耗能高，速度慢，这在实时应用或大批量转图的情况下会成为瓶颈。<br><br>python gil<br>能满足我们大部分功能需求，操作简单，速度可以，也是低耗，但质量不能满足（和具体算法有关）<br><br>虽然以前有接触过图片处理，但功力不够，力不从心，要再做也达不到convert和econvert的质量效果；<br>另一方面每个东西身上都有我们需要的东西，那不如把这三个结合起来使用，python gil（做计算为了<br>避免要另起进程），econvert做jpg处理，convert做gif（因为在我们网站中gif和png数量加起来才<br>是总量的2%，所有用户convert处理问题很不大）；<br><br><br><br></div></div><br>
页:
[1]