艺龙h5酒店业务架构问题以及调优策略

现有问题

  历史

            艺龙网h5酒店业务线自成立到现在，经历了几番较大调整，部分技术人员也是从.net转到java，由于技术人员的资历和公司对业务进度的追求，导致技术严重落后。

线上问题层出不穷，例如：线上抛出异常，redis宕机，tomcat宕机，qps过高导致响应问题，代码质量差导致模块加载速度差等等。

  压力分析

           项目由于业务性质问题，流量多集中于周五，周六，以及个节假日。qps常态为400——500，流量高峰为800——1500。流量不是惊的吓人，但却迫切需要高可用性。

 

            用户行为多以查询为主，真正到支付成单的量要少一些。所以，在集群部署上支付平台要比h5后端少5倍。

  待解决问题

           由于用户查询行为要多于事务行为，所以要想真正为后端减轻压力，合理并多多使用缓存。目前项目中虽然集成并使用了redis，但是并未对页面的数据接口做拆分分析，没有真正的用起缓存服务。另外，从页面请求静态资源的304码来看，似乎使用了cache-control，但是对后端接口每一个都为真实请求（并没有在后端数据不发生变化的时候走缓存），可以断定页面上静态资源的缓存为cdn缓存起的作用。再加上每一个请求都为https，在高请求下，速度怎么能快起来。

  现有架构

          elong现有的架构是存在一定问题的，比如，上面所说到的缓存使用问题，通过监控系统观察到nginx负载不均衡问题（在高请求量下，tomcat集群环境，明显受中不均），甚至更没有timeout  设置  nginx——》tomcat（每次tomcat宕机，都需要运维手动踢出），tomcat裸跑，还有无法容忍的就是项目臃肿至极（几个业务线耦合在一起）。

初做调整

          在有限的时间内和条件下，首先做了代码级别的优化（之前的文章有，不再赘述）。

          后来为了摒弃掉项目的不断臃肿，我初步决定按渠道进行垂直拆分，之后分成了wxqb（微信钱包）、wxxcx（微信小程序）、hotelfx（酒店分销其他渠道），这样做各部分代码业务不但清晰起来，更可以分开部署从而把流量分开，按照流量制定集群机器数量。

 

        另外，像tomcat也做了初步的调优，主要有线程连接池，最大连接数，nio模型，ddos流量预防等等。当然，jvm调优也做了一些，调整了内存空间和分代垃圾回收策略。

架构希望

          理想状态下，希望平台业务可以向后端下沉，客户端直接有mapi提供服务，而各服务要彻底垂直切分成，首页服务，列表页服务，详情页服务，支付平台，订单平台等等。

 

           这单独抽离拆分后，更加节省服务器，更容易针对业务特点做优化。而且，通信层也更少了，避免了网络耗时。

           最好在，前端有一个前端静态数据系统，可以利用lua或者是node.js去把一些常规数据之间返回，这样一方面屏蔽了java系统支持网络通信的耗时，另一方面也会吸收掉部分流量，从而使得性能真正的提高起来。

           通讯协议方面，我们现在的系统级别交互普遍还是http协议，我们都知道http为短链接，一次请求完成后就会断开，所以，要利用tcp封装一套rpc的通讯框架，可以选择诸如protobuf、kryo、fst等高效序列化方式。或者直接使用开源的，像dubbo、motan rpc等等。配合zookeeper项目的管理，注册发布，轮询调用等等，更是提高了性能，可用性和可扩展性。

           docker管理部署是一个高可用的互联网项目必不可少的，一个动态的虚拟容器，可以带着整套环境动态的部署项目。它给微服务管理提供了更便捷的运维方式，甚至可以配合脚本语言做弹性计算的部署。

          大数据平台是大型互联网项目的标配，主要作用在于收集用户日志，分析用户行为，生成响应的业务报表，从而制定出更符合用户口味的活动和产品。