基于OpenResty的架构实现
在这样的背景下，我们打造了马蜂窝广告数据监测平台ADMonitor，希望逐步将其实现成一个稳定、可靠、高可用的广告监测服务。
设计思路
为了解决老系统中的各种问题，我们引入了新的监测流程。主体流程设计为：
在新的监测服务(ADMonitor)上生成关于每种广告独有的监测链接，同时附在原有的客户链接上;
所有从服务端下发的曝光链接和点击链接并行依赖ADMonitor提供的服务;
客户端针对曝光行为进行并行请求，点击行为会优先跳转到ADMonitor，由ADMonitor来做二段跳转。
通过以上方式，使监测服务完全依赖ADMonitor，极大地增加了监测部署的灵活性及整体服务的性能；同时为了进一步验证数据的准确性，我们保留了打点的方式进行对比。
技术选型
为了使上述流程落地，广告监测的流量入口必须要具备高可用、高并发的能力，尽量减少非必要的网络请求。考虑到内部多个系统都需要流量，为了降低系统对接的人力成本，以及避免由于系统迭代对线上服务造成干扰，我们首先要做的就是把流量网关独立出来。
关于C10K编程相关的技术业内有很多解决方案，比如OpenResty、JavaNetty、Golang、NodeJS等。它们共同的特点是使用一个进程或线程可以同时处理多个请求，基于线程池、基于多协程、基于事件驱动+回调、实现I/O非阻塞。
我们最终选择基于OpenResty构建广告监测平台，主要是对以下方面的考虑：
第一，OpenResty工作在网络的7层之上，依托于比HAProxy更为强大和灵活的正则规则，可以针对HTTP应用的域名、目录结构做一些分流、转发的策略，既能做负载又能做反向代理；
第二，OpenResty具有Lua协程+Nginx事件驱动的「事件循环回调机制」，也就是Openresty的核心Cosoket，对远程后端诸如MySQL、Memcached、Redis等都可以实现同步写代码的方式实现非阻塞I/O；
第三，依托于LuaJit，即时编译器会将频繁执行的代码编译成机器码缓存起来，当下次调用时将直接执行机器码，相比原生逐条执行虚拟机指令效率更高，而对于那些只执行一次的代码仍然可以逐条执行。
架构实现
整体方案依托于OpenResty的处理机制，在服务器内部进行定制开发，主要划分为数据收集、数据处理与数据归档三大部分，实现异步拆分请求与I/O通信。
结束语：以上就是关于基于OpenResty的架构实现的应用的全部内容，更多内容请关注学步园。