1. 中心化日志记录架构(译)

    原文:Centralized Logging Architecture

    译者:youngsterxyf

    中心化日志记录一文中,我介绍了几个工具,用于解决中心化日志记录的问题。但这些工具一般仅能解决这个问题的一部分, 这意味着需要综合使用几个工具来构建一个健壮的解决方案。

    你需要解决问题的这几个主要方面:收集传输存储、以及分析。某些特殊的应用场景下,也许还希望具备告警的能力。

    收集

    应用程序以不同的方式产生日志,一些是通过syslog,其他一些是直接写到文件。考虑一个运行在linux主机上的典型web应用,在/var/log目录会有十几个甚至更多的日志文件, 如果一些应用指定日志存放在HOME目录或者其他位置,则这些目录下也是如此。

    如果你正在运营一个基于web的应用,开发人员或者运维同事需要快速地访问日志数据以便对线上问题进行排错,那么就需要一个能够近乎实时监控日志文件变化的方案。 如果使用基于日志拷贝的方式 --- 文件以固定的时间间隔拷贝到一台中心服务器上,那么仅能检查与复制操作频率相同的新增日志数据。当站点已经挂掉,而你正在等待相关日志数据的复制, 那么一分钟一次的 rsync cron 任务也许还不够快。

    从另外一个角度来看,如果需要分析线下日志数据,计算各种度量指标,或者其他批量的工作 …

    Tagged as : 翻译 日志 架构
  2. 某运营平台架构调整

    之前在运营开发规范化一文中提过工作中涉及一个运营平台。曾有段时间我一直吐槽该平台的代码实现有多烂,各种功能的逻辑有多“野蛮”,应尽快改造,但也许“worse is better”,我的吐槽只能仅仅是吐槽而已了。

    最近该平台终于频繁出问题了。原因是上线了一个新功能---生产系统的模块之间每发生一次模块调用,就会调用该运营平台的API上报一次数据,该API的逻辑是将上报的数据存入Redis中。API由PHP实现,服务器以Nginx + PHP-FPM的方式处理API调用请求。当生产系统的业务量增大,模块直接的调用次数频率增大直接导致API调用的频率增大, 加上该平台所在服务器各种cron任务等的影响,导致在某些时候,PHP-FPM子进程数量飙升,跑满CPU,并且PHP-FPM子进程的数目持续不降(原因不明)。这样导致一方面用户无法访问该平台---服务器响应502(Nginx接受请求,但PHP-FPM无法处理该请求),另一方面更多的数据上报API调用无法完成,造成大量数据丢失和误告警。 用户怨声载道,领导也很头疼,要求尽快搞定该问题,但迟迟没人挑起这个活。

    为了开个头,上上个周末的一天我绘制了两张对比图(如下所示),尝试给出建议方案。

    operation_platform_old_arch

    operation_platform_new_arch

    这种方案的时间成本较低,无需改动对外API,也无需大量修改代码。

    Tagged as : 架构 笔记
  3. 学在腾讯:简而美的微信后台架构

    注:公司分享讲座的一点笔记,不保证准确性。

    问题

    极致的业务特性

    • 流畅的消息收发
    • 及时的通知
    • 省电
    • 省流量
    • 瘦客户端

    困难的后台-终端同步

    • 同步多样数据:账户信息、通讯录、消息、朋友圈等
    • 及时通知与同步
    • 移动网络下的可靠同步
    • 省流量与电量

    方案

    极简的同步协议

    • 后台与终端只需要沟通一个数字,后台即可知道终端缺失的所有数据。
    • 变更序列号/版本号:
      • 后台对用户数据的每项变更,都赋予一个单调递增的序列号,即用户的每项数据都有一个全局递增序列号。
      • 后台每次给终端发送数据都会带上所发送的所有数据的最大序列号。
      • 终端每次请求数据时都会带上已经接受到的最大序列号。

    高效的通知机制

    • ios Apple Push Network Service
    • Android等-长连接
    • GPRS/EDGE信令风暴优化
    • 自适应心跳间隔调节

    三层后台架构

    Arch of weixin backend

    统一的RPC框架

    • 根据ProtocolBuffer定义生成服务器框架和客户端
      • 服务器:开发人员填充接口实现
      • 客户端: 应用方本地调用客户端提供的接口函数
    • 屏蔽网络细节
      • 支持基于TCP/UDP的网络调用 …
    Tagged as : 腾讯 微信 架构
  4. 从URL监控问题谈网站Web架构

    之前工作中实现了一个对站点进行URL监控的功能。原理是:

    • cron脚本定时从一台Nginx服务器上获得Nginx配置文件(包括upstream配置),在解析配置得到:域名->upstream名(可能有多个)、upstream名->属于该upstream的服务器ip列表,存入数据库;

    • 用户通过Web界面配置URL监控项,配置过程为:

    • 输入要监控的URL,如http://www.sample.com/test.php ,前端JS解析出域名部分www.sample.com,向后端发送AJAX请求,得到该域名相关的upstream;

    • 用户选择正确的那个upstream(Nginx可以将对不同URL的请求转发到不同的upstream后端机器);
    • 然后填写监控告警信息接收人等其他配置信息,提交即可。

    • 另一个cron脚本定时地:

    • 从数据库中读取URL监控项数据;

    • 根据监控项中的upstream名,从数据库中读取属于该upstream的ip列表;
    • 逐个使用ip列表中的ip替换URL的域名部分,将域名部分作为HTTP请求头的HOST字段的值;
    • 使用libcurl库或curl命令发出请求(如使用curl命令:curl -H "www.sample.com" http://192.168.1.1/test.php);
    • 如果响应码非200或非3xx等 …

Page 1 / 1