石器时代单机改装lua，石器时代单机手机版

有网友提问：石器时代单机修改lua,今天小编来回答一下

如果你对答案不满意，不妨看小编为你推送的这篇文章

注：本文首次发表于CSDN。转载请注明出处。

前言由于海外购物是最近一两年的另一个热点，很多团队进入市场，竞争变得激烈；HIGO是美妆的创新产品，目前仍在快速发展。鉴于目前的特殊时期，为了避免泄露公司的敏感信息，关于系统架构的细节不会确切，架构演进带来的性能提升会成倍加强。

众所周知，随着电子商务的发展，获取用户的成本越来越高。正因如此，形成了一个不成文的共识：不推广，不销售。在运营层面，HIGO也是以每月一个推广，每周一个推广，每天一个话题的节奏进行。复杂多变的业务场景对系统架构是极大的挑战和考验，这也验证了互联网系统架构的铁律：架构不是一成不变的，而是随着业务需求不断演进的。HIGO的架构自诞生以来发生了非常重大的变化，以2015.08年为时间节点。但大体上是一致的，都是基于Linux操作系统，通过成熟的LNMP架构和开源的高性能服务组件实现，具体使用场景所涉及的变化也很明确，都是碰巧适应业务，其中开源软件必不可少。

《原力石器时代》2015年8月之前简单的说就是服务器提供标准的HTTP接口，响应客户端的请求，返回结构化的JSON；业务端主要用PHP开发，使用公司自主开发的一套基于PHP5命名空间的轻量级MVC框架。来自iOS和Android应用程序的客户端请求首先到达四层负载均衡器LVS。LVS将请求转发给一组高可用的nginx应用负载均衡器“nginx配置了fastcgi缓存”，然后根据不同的服务转发给后端的php-fpm集群，响应特定的服务并将结果返回给客户端。在具体的业务层，PHP会根据实际情况与cache (Redis)和storage (MySQL)进行交互。在1.0版本中，缓存使用单Redis“主从”，使用VRRP协议实现高可用性；数据库交给美利主站维护，一主一从。App中的IM模块采用开源node.js框架meteor，图片服务简单使用NFS文件共享，挂载到php-fpm节点。这种成熟的架构长期承受了用户快速增长和业务快速迭代带来的压力。

1.0版本的架构有一个明显的单点，就是基于NFS的图片服务。但由于架构足够，加上公司购买了商用CDN服务，并未出现大的问题，所以直到改版前，并未在这方面花费精力。这里不得不说一个小插曲，由于海外买家不断反馈App响应速度慢，IM聊天消息经常无法正常收发。当时架构团队决定把机房搬到。。。虽然当时买家的抱怨减少了，但是后来的实践证明之前的决定是错误的。8月架构升级时，机器搬回了北京。

图1 HIGO架构图

以下是一些实际问题和解决方案：

6月初的一天，热身大促。突然，在线服务速度极慢。在预上线环境下人工检查确认后，发现所有界面基本都超时了。通过商业和自有监控系统发现，MySQL链接数量过高，早已超过DBA设定的阈值。php-fpm中单节点进程数量已经飙升到近2K，系统处于挂起状态。通过多方调查，确定由于Redis的配置问题和。。机房网络抖动，Redis有两个master，意味着缓存层完全无效，所有请求直接渗透到MySQL；更糟糕的是，由于业务时间限制比较紧，PHP的业务层存在大量的慢查询，表结构没有合适的索引，索引不合适，子查询和联合查询等。这进一步扩大了问题，并最终导致服务无法响应

由于公司战略层面的原因，DBA对HIGO业务重视不够。但是MySQL的一主一从一直存在从库的同步延迟超出可接受范围的情况，迫使技术团队在存储上妥协，放弃从库，只使用主库。结果就是主库的压力一直压下来，读写分不开，性能瓶颈一直在存储层。“xhproy做过性能分析，这个结论成立”。

Redis缓存和持久化的混用，使得缓存系统部署无法分布式，内存利用率不高，问题不易排查。

现阶段主要压力不是来自线上流量，而是产品和商家的需求压力；主要目标是快速迭代实现产品功能。我们的上线频率很高，不可避免的会有一些bug被引入到上线的生产环境中。可见，团队的主要矛盾是随着公司的业务发展而不断变化的。

梅说，她大手笔买了跑男的冠名权，HIGO将迎来一波流量爆发，预计增速超过10倍。1.0版本的架构显示不足以支撑，架构升级势在必行。

铁器时代“从2015年8月”开始。我们面临的主要问题是流量飙升，而且是峰值明显的流量。我们需要全面升级系统架构，解决各种单点和系统性能瓶颈，以应对外部流量对我们的压力。v2.0架构主体继承了v1.0，侧重于小的优化和改进。一些具体做法如下：

借鉴淘宝，在LVS和nginx之间增加层流量控制，用Nginx Lua“open resty”实现，可以根据不同的规则对服务进行降级，减少对核心业务的影响，保证服务可用性。

根据业务场景分开使用Redis:对于KV cache，使用twemproxy代理进行分布式部署，以便横向扩展；对于计数器、队列、集合等需要持久存储的数据，单独部署高可用性Redis持久存储。升级后，请求将被分散，减少单个节点的压力；第二，业务层根据不同的需求选择不同的方案会更清晰。

php-fpm集群架构保持不变，可以根据业务随时增减节点。完全可扩展，无需多做介绍。

DB层使用公司自主研发的一套dbproxy，可以自动实现读写分离、数据库和表划分、SQL审计等。同时，业务层根据具体情况实现了数据库分离和子数据库，如拆分成用户、商品、订单、优惠券等系统。不同的业务调用对应的数据库，跨业务调用通过公共lib库进行，不允许直接访问数据库，尽可能做到高内聚低耦合，降低系统间的耦合度。这样做的好处显而易见，但也引入了不和谐因素，最直接受影响的就是统计，数据分散到不同的数据库，汇总统计无异于噩梦。我们对这个问题采取了温和的解决办法。DBA每12小时导出一次所有数据库，然后汇总到离线统计数据库中，以牺牲统计的实时性，降低在线服务的复杂度。

曾经的单点图片服务，用的是曲线救国的思路，叫主站现成服务。IM也是，由主站专业团队维护。

目前v2.0的大部分功能已经上线。目前效果已经达到了预期，这也让我们对经营好男士的流量有了信心。

未来架构向文明时代的演进随着人员和业务的不断扩大，对系统模块服务的需求越来越明确。之前我们尝试过服务，但是因为各种原因没有普及，但是我坚信未来服务会提上日程。

在未来，其他模块和服务将继续引入我们的系统，但我们将尽力保持架构简单明了，减少系统之间的耦合，并构建一个高可用、可扩展和高性能的

至于升级前后的性能对比，因为后端接口的复杂程度不一致，只看某个接口的QPS意义不大。我参考QA同学的接口压力测试报告，给出升级前后单个节点的平均性能对比表：

表1:升级前后单个节点的平均性能比较

注意：单个php-fpm节点，不是精确值，仅供参考。

助力系统使用的开源组件介绍：杨永杰，HIGO公司高级架构师，基于LNMP架构专注互联网技术的全栈架构师。

(编辑/钱曙光，关注架构与算法领域。如果你想举报或投稿，请发邮件到qianshg@csdn.net，也可以加微信qshuguang2008讨论。请注意公司的立场。)

“CSDN资深建筑师团”，成员包括SDCC 2015建筑讲师等众多知名互联网公司大牛建筑师。想入群请加微信qshuguang2008申请加入，并备注公司职位。

关于石器时代单机修改lua更多网友观点如下