Tengine

前言 前阵子有网友询问，如何优化网站？这个问题真的很大，跟他简单的聊了一下，随便说了几点，觉得有必要整理一篇文章出来，正好前阵子在做爬虫博客，于是把大体思路分享出来，与大家互通有无，共同进步。 优化 版本一 系统开始是这样子的，一个 Tomcat 拖着一个 MySql 服务，跑在一个 2C 4G 的Linux服务器上，所有的请求都走 Tomcat，所有的查询都走 MySql，看起来像一句废话？ 资源是有限的，那么如何有效的利用资源，提升服务性能？Tomcat 号称能抗住数十万并发访问，但是这事也得分场景，还得有足够牛逼的机器。 Tomcat 优化 Tomcat支持以下三种模式： BIO：一个线程处理一个请求，缺点：并发量高时，线程数较多，浪费资源，Tomcat7或以下在Linux系统中默认使用这种方式。 NIO：利用Java的异步IO处理，可以通过少量的线程处理大量的请求。Tomcat8在Linux系统中默认使用这种方式。Tomcat7 必须修改Connector配置来启（conf/server.xml配置文件）： <Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" connectionTimeout="20000" redirectPort="8443"/> APR(Apache

「微服务开源生态报告」 ，汇集各个开源项目近期的社区动态，帮助开发者们更高效的了解到各开源项目的最新进展。 社区动态包括，但不限于：版本发布、人员动态、项目动态和规划、培训和活动。 非常欢迎国内其他微服务领域的开源项目将近期的社区动态，投递给我们，我们将一同发布。 以下是 第 10 期「微服务开源生态报告」 的内容。 Apache Dubbo Dubbo 开发者日活动 @上海 8月17日，Dubbo开发者日上海站成功举办，报名人数 685 人，线上观看人数达 6000+ ； 社区向 Apache 董事会提交了 8 月份月度社区活跃报告，开发者日活动收到董事会的积极肯定； dubbo-go 1.1.0 release目前社区正在投票中； apache/dubbo-go-hessian2 社区展开对Java包装类型支持的讨论； dubbogo/gost 增加queue队列支持； apache/dubbo-go 修复和优化了使用Zookeeper为注册中心时内存过大的问题； apache/dubbo-go 增加了 forking 类型的集群策略支持； apache/dubbo-go 瘦身去掉了单元测试需要的jar包等二进制文件，单元测试前需要通过脚本从网络拉取； 涂鸦智能基于 dubbo-go 的对外平台级网关服务已经发布到生产环境，服务两百个接口，业务各项指标以及资源使用平稳，是对 -

用淘宝改良的Nginx（Tengine）提供web服务 今天在本博客上顺利把Nginx换成了Tengine；并启用了动态加载模块 mod_concat，对本博客使用的 知更鸟 主题各个页面head模板中大量调用的多个CSS,JSS请求进行了合并，即客户端浏览器只需通过一次http请求，即可从服务器返回所需要的多个CSS,JS文件；下面是配置步骤： 编译安装Tengine 1，停止web服务，备份原来的Nginx目录（我是lnmp一键安装的，所以直接备份/usr/local/nginx目录即可） service nginx stop cd /usr/local mv nginx nginx.old 2，下载tengine源码包，编译安装tengine（标准安装，指定安装路径和原nginx一致，编译启用 TLS SNI support cd /usr/local/src wget http://tengine.taobao.org/download/tengine-2.1.0.tar.gz tar zxvf tengine-2.1.0.tar.gz cd tengine-2.1.0 ./configure --prefix=/usr/local/nginx --with-pcre=/usr/local/src/pcre-8.37 make make install 3

摘要 最初的秒杀系统的原型是淘宝详情上的定时上架功能，由于有些卖家为了吸引眼球，把价格压得很低。但这给的详情系统带来了很大压力，为了将这种突发流量隔离，才设计了秒杀系统，文章主要介绍大秒系统以及这种典型读数据的热点问题的解决思路和实践经验。 一些数据 大家还记得2013年的小米秒杀吗？三款小米手机各11万台开卖，走的都是大秒系统，3分钟后成为双十一第一家也是最快破亿的旗舰店。经过日志统计，前端系统双11峰值有效请求约60w以上的QPS ，而后端cache的集群峰值近2000w/s、单机也近30w/s，但到真正的写时流量要小很多了，当时最高下单减库存tps是红米创造，达到1500/s。 热点隔离 秒杀系统设计的第一个原则就是将这种热点数据隔离出来，不要让1%的请求影响到另外的99%，隔离出来后也更方便对这1%的请求做针对性优化。针对秒杀我们做了多个层次的隔离： 业务隔离。 把秒杀做成一种营销活动，卖家要参加秒杀这种营销活动需要单独报名，从技术上来说，卖家报名后对我们来说就是已知热点，当真正开始时我们可以提前做好预热。 系统隔离。 系统隔离更多是运行时的隔离，可以通过分组部署的方式和另外99%分开。秒杀还申请了单独的域名，目的也是让请求落到不同的集群中。 数据隔离。 秒杀所调用的数据大部分都是热数据，比如会启用单独cache集群或MySQL数据库来放热点数据，目前也是不想0.01

一、背景 随着互联网的快速发展、需求频繁变更、内容数量的俱增、时间的持续增长，图片数量也会越来越多。在实际需求中，会出现在若干个页面或同一个页面不同位置，展示同一条信息以及其缩略图。在这时，如果使用 CSS 控制图片显示的大小，对于那些与该位置不成比例的图片，缩小后就会出现图片变形。也不可能让编辑人员，对所有的图片进行 PS，这时候就产生了强烈的自动化裁剪、缩放图片的需求，来适应不同规格的缩略图。 Nginx 虽然有自带的 image filter module 也能实现此功能，但是有弊端： image filter module 使用的是 GD，GD 性能、效率、处理后的图片质量不如 GraphicsMagick image filter module 没法真正生成裁剪/缩放后的图片，而是通过 Nginx 直接输出的，这样每次请求或缓存过期后都需要重新裁剪/缩放，这样无疑会增加 Nginx 负担 二、系统环境 操作系统 CPU 内存 磁盘及分区 三、软件准备 Tengine： https://github.com/alibaba/tengine Lua： http://www.lua.org/ftp/ LuaJIT: http://luajit.org/download.html libjpeg、libjpeg-devel libpng、libpng-devel giflib

背景 网络延迟是网络上的主要性能瓶颈之一。在最坏的情况下，客户端打开一个链接需要DNS查询（1个 RTT），TCP握手（1个 RTT），TLS 握手（2个RTT），以及最后的 HTTP 请求和响应，可以看出客户端收到第一个 HTTP 响应的首字节需要5个 RTT 的时间，而首字节时间对 web 体验非常重要，可以体现在网站的首屏时间，直接影响用户判断网站的快慢，所以首字节时间（TTFB）是网站和服务器响应速度的重要指标，下面我们来看影响 SSL 握手的几个方面： TCP_NODELAY 我们知道，小包的载荷率非常小，若网络上出现大量的小包，则网络利用率比较低，就像客运汽车，来一个人发一辆车，可想而知这效率将会很差，这就是典型的 TCP 小包问题，为了解决这个问题所以就有了 Nigle 算法，算法思想很简单，就是将多个即将发送的小包，缓存和合并成一个大包，然后一次性发送出去，就像客运汽车满员发车一样，这样效率就提高了很多，所以内核协议栈会默认开启 Nigle 算法优化。Night 算法认为只要当发送方还没有收到前一次发送 TCP 报文段的的 ACK 时，发送方就应该一直缓存数据直到数据达到可以发送的大小（即 MSS 大小），然后再统一合并到一起发送出去，如果收到上一次发送的 TCP 报文段的 ACK 则立马将缓存的数据发送出去。虽然效率提高了，但对于急需交付的小包可能就不适合了，比如

背景 网络延迟是网络上的主要性能瓶颈之一。在最坏的情况下，客户端打开一个链接需要DNS查询（1个 RTT），TCP握手（1个 RTT），TLS 握手（2个RTT），以及最后的 HTTP 请求和响应，可以看出客户端收到第一个 HTTP 响应的首字节需要5个 RTT 的时间，而首字节时间对 web 体验非常重要，可以体现在网站的首屏时间，直接影响用户判断网站的快慢，所以首字节时间（TTFB）是网站和服务器响应速度的重要指标，下面我们来看影响 SSL 握手的几个方面： TCP_NODELAY 我们知道，小包的载荷率非常小，若网络上出现大量的小包，则网络利用率比较低，就像客运汽车，来一个人发一辆车，可想而知这效率将会很差，这就是典型的 TCP 小包问题，为了解决这个问题所以就有了 Nigle 算法，算法思想很简单，就是将多个即将发送的小包，缓存和合并成一个大包，然后一次性发送出去，就像客运汽车满员发车一样，这样效率就提高了很多，所以内核协议栈会默认开启 Nigle 算法优化。Night 算法认为只要当发送方还没有收到前一次发送 TCP 报文段的的 ACK 时，发送方就应该一直缓存数据直到数据达到可以发送的大小（即 MSS 大小），然后再统一合并到一起发送出去，如果收到上一次发送的 TCP 报文段的 ACK 则立马将缓存的数据发送出去。虽然效率提高了，但对于急需交付的小包可能就不适合了，比如

linux 安装tengine tengine是什么 tengine是由淘宝网发起的Web服务器项目。它在Nginx的基础上，针对大访问量网站的需求，添加了很多高级功能和特性。Tengine的性能和稳定性已经在大型的网站如淘宝网，天猫商城等得到了很好的检验。它的最终目标是打造一个高效、稳定、安全、易用的Web平台。 Nginx是异步框架的网页服务器，也可以用作反向代理、负载平衡器和HTTP缓存。 安装必要依赖 依赖 gcc openssl-devel pcre-devel zlib-devel 安装： yum install gcc openssl-devel pcre-devel zlib-devel -y 切换为root用户 [shaofei@hadoop137 tengine-2.3.1]$ su root 密码： [root@hadoop137 tengine-2.3.1]# [root@hadoop137 tengine-2.3.1]# yum install gcc openssl-devel pcre-devel zlib-devel -y 完毕！ [root@hadoop137 tengine-2.3.1]# exit exit [shaofei@hadoop137 tengine-2.3.1]$ whoami shaofei 上传安装文件到linux服务器

导读 ：本文主要介绍了高德在服务单元化建设方面的一些实践经验，服务单元化建设面临很多共性问题，如请求路由、单元封闭、数据同步，有的有成熟方案可以借鉴和使用，但不同公司的业务不尽相同，要尽可能的结合业务特点，做相应的设计和处理。 一、为什么要做单元化 单机房资源瓶颈 随着业务体量和服务用户群体的增长，单机房或同城双机房无法支持服务的持续扩容。 服务异地容灾 异地容灾已经成为核心服务的标配，有的服务虽然进行了多地多机房部署，但数据还是只在中心机房，实现真正意义上的异地多活，就需要对服务进行单元化改造。 二、高德单元化的特点 在做高德单元化项目时，我们首先要考虑的是结合高德的业务特点，看高德的单元化有什么不一样的诉求，这样就清楚哪些经验和方案是可以直接拿来用的，哪些又是需要我们去解决的。 高德业务和传统的在线交易业务还是不太一样，高德为用户提供以导航为代表的出行服务，很多业务场景对服务的RT要求会很高，所以在做单元化方案时，尽可能减少对整体服务RT的影响就是我们需要重点考虑的问题，尽量做到数据离用户近一些。转换到单元化技术层面需要解决两个问题: 1.用户设备的单元接入需要尽可能的做到就近接入，用户真实地理位置接近哪个单元就接入哪个单元，如华北用户接入到张北，华南接入到深圳。 2.用户的单元划分最好能与就近接入的单元保持一致，减少单元间的跨单元路由。如用户请求从深圳进来