对后端系统规模上升的一些思考

随着公司业务的增长,我们的服务器数量越来越多,上面运行的各种服务也越来越多;系统的架构也在逐渐复杂化,一个业务往往需要调用后端的多个服务才能完成,服务间有着复杂的依赖关系。这些给我们的运维带来了很大的麻烦,系统发布、监控、扩容等等都随着服务器和服务数量的上升变得越来越麻烦,遇到故障尤其是整个服务器的硬件故障的时候,恢复时间也越来越长。如果说当前还能忍受的话,那当规模再增长一倍的时候,运维的复杂度就会不可控了。

最近针对这个话题我做了些研究,也有一些思考,还不成熟,但在这里先记录一下。

1. 服务发现

我们当前还是用的最原始的配置文件和 DNS 来做服务发现,Host、端口都是写在配置文件里的,发生变更的时候只能修改配置文件并重启服务。所以当某台机器挂掉的时候,依赖它上面服务的其他系统也都全部会出问题。而应急的步骤都是先在别的机器上运行新的实例,修改配置文件并重启关联的其他系统。这样做费时、费力、且会有一个时间窗口内系统无法提供服务。

当然我们关键的服务是通过 Nginx 来做了负载均衡/主备的。但这样做还是有两个问题:

Read on →

婚了

2014 年 10 月 3 日,我和相恋三年多的女友在老家湖北步入了婚姻的殿堂。虽然我们很早就开始互相称呼『老公』,『老婆』,结婚证也早就领了,但婚礼依然让人感动,婚后彼此也更加亲密了。

我们的蜜月旅行的目的地是塞班岛。在那里我们度过了虽然短暂,但却让人难以忘怀的三天时光;在那里,我看到了这辈子见过的最美丽的夕阳,最清澈的海水,最洁白的沙滩。

我精选了一些照片,全部放在 Lofter 上了。

回顾这一路走来的三年,虽然也经历了一些挫折,但最终我们还是坚持了下来,也对彼此更加信任和依赖。快 30 而立的自己,最大的遗憾就是没能给她一个可以让两人安家的小窝,反而让她陪着我在这霾都漂着,每每想起这些,都觉得十分愧疚,但也坚定了要继续努力的决心。我的人生正在面临一个重大的转折点,如果能把握好这次机会,再坚持两年,要相信美好的未来在前方等待着。

加入 Mac 神教

在每天上苹果团看报价几个月后,我终于下狠心在半个月前下单入了 2014 新款的 Retina Mac Book Pro MGX72。到现在用了半个月,完全用它取代了公司配的华硕笔记本。目前为止的总体感觉非常好,总结起来主要有两点:一是屏幕太棒了;二是硬盘太小了。

总体感受

Retina 屏幕真不是盖的,看着实在是太舒服了。对于每天面对密密麻麻一堆代码的码农来说,一块精细的 Retina 屏幕真是个了不起的福利。有了这么高的分辨率,真是无论用什么字体,什么渲染方法都好看。以前用 Linux 的时候,每次装完一个新系统,第一件做的事情就是折腾字体:安装各种补丁,折腾 fontconfig 配置(P.S. 推荐所有对字体渲染有要求的 Linux 用户尝试下 infinality);相比较之下,用 Mac 就完全无需折腾,直接用就好了。自带的等宽字体 Monaco 非常漂亮,中文的冬青黑也非常不错。我甚至修改了我的 Emacs 配置,只有在 Linux 系统下才设置字体了:

Read on →

Nginx 基于客户端 IP 来开启/关闭认证

前些日子帮助公司在搭建了一个内部资源的导航页面,方便公司员工访问各种常用的系统。因为这个页面包含一些敏感信息,我们希望对其做认证,但仅当从外网访问的时候才开启,当从公司内网访问的时候,则无需输入账号密码。

按照这个需求研究了下 Nginx 配置,发现 satisfy 指令可以很好地解决这个问题。下面贴出来我们的配置:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
server {
    listen 80;
    server_name intra.foobar.com;
    charset utf-8;

    satisfy any;
    allow 192.168.0.0/22;
    allow 111.222.333.1/32;
    deny all;
    auth_basic "Intranet";
    auth_basic_user_file /usr/local/nginx/conf/intranet-htpasswd;

    location / {
        root /usr/local/www/intranet;
        index index.html;
    }
}

其中 satisfy 作用于所有的 access phase handler,参数值有两种:allany,分别代表所有规则都满足和任一规则满足。将其配置为 any,并配合 auth_basic 和 access 模块就可以基于 IP 地址来开启/关闭认证。

以我们的规则为例,192.168.0.0/22 这个内网网段和 111.222.333.1(虚构的)这个 IP 的 Client 是可以访问的,而其他用户则需要进行认证。

官方文档上的说法是 satisfy 支持 ngx_http_access_module, ngx_http_auth_basic_modulengx_http_auth_request_module,不确定对于第三方的认证模块如 ngx_http_auth_digestsatisfy 是否也能工作。

详细的说明可以参考 Nginx 官方文档

Java 服务端监控方案(四. Java 篇)

这个漫长的系列文章今天要迎来最后一篇了,也是真正与 Java 有关的部分。前面介绍了我们的监控方案的 GangliaNagios 及其整合的部分,这一次则介绍如何记录 Java 应用内的性能参数并将其暴露给监控系统。

主要介绍的内容有 JMX 以及将监控 JMX 并发送数据到 Ganglia 的 jmxtrans,同时还会介绍我实现的一个简单的记录性能参数的方法。

Read on →

RHEL/CentOS 5 下 NAT 转发不工作的一个原因

TL;DR 如果你发现 RHEL/CentOS 5 下用 iptables 做的 NAT 转发规则不管用,请用 iptables -L -nv 检查一下 FORWARD 链里的内容,如果里面有一条直接转到 RH-Firewall-1-INPUT 的规则,那么你很有可能跟我们一样被坑了。尝试在 RH-Firewall-1-INPUT 链里把目标端口打开,那些规则应该就可以工作了。

公司的服务器上因为种种原因做了不少 iptables NAT 规则,用于做端口映射。我们发现有的规则可以工作,有的则不然。但这些规则基本都长一个样,除了端口和转发的目标 IP 各有不同以外。

Read on →

小心 Eclipse Java Compiler 编译出来的 Class

本作坊里,不少项目的升级方式都是直接把 IDE 编译出来的 Class 文件打包放到服务器上。虽然这种方式实在是让我无力吐槽,并且我也尝试推动了很多项目往 Gradle 的迁移以实现构建、部署的自动化和规范化,但还有一些历史项目依然用这种方式部署。在项目无法编译成功的情况下,这种做法会带来很严重的问题。

Eclipse 的 Java 编译器会在 Java 源文件有错误的情况下仍旧生成 Class。如果开发者未发现这些错误,并且使用了它生成的这些 Class,那么相关代码会在运行时直接抛出一个 java.lang.Error

Read on →

Java 服务端监控方案(三. Nagios 篇)

最近在为可能改变人生的一件事在努力,所以没怎么有空更新博客,无论如何今天还是抽空把这个系列的第三篇补上吧。

上一次 我介绍了我们监控方案中的核心:Ganglia,而这次我们继续介绍用于告警的 Nagios 系统,以及如何让 Nagios 使用 Ganglia 来作为告警的数据源。

Nagios 原本名叫 NetSaint,是由 Ethan Galstad 和其他一些开发者实现和维护的。它跨平台,可以在主流的所有 UNIX 类操作系统上运行。Nagios 提供一个基于 PHP 和 CGI 的 Web 界面,并包含很多插件,用于监控各种不同的网络服务以及网络设备。Nagios 的基本工作方式就是定期检查用户配置的 host 上的 service,如果发现异常就会产生告警(WARN 或者 CRITICAL 级别),并使用邮件或者短信来通知管理员。

正常的 Nagios 系统需要在被监控的机器上安装 NPRE ,用于远程执行指令来获取监控数据。但我们的方案里已经有 Ganglia 来收集监控数据了,完全可以省略 NPRE,直接从 Ganglia 中获取数据。

下面介绍 Nagios 的安装和配置,以及和 Ganglia 的整合。

Read on →

Java 服务端监控方案(二. Ganglia 篇)

上一篇文章综述了我们的服务端监控方案,本文则继续介绍我们的监控方案的核心:Ganglia。

Ganglia 是加州大学伯克利分校发起的系统监控项目,为大规模高性能计算集群而设计,采用了 RRD、XML 等成熟的技术实现,单节点开销很小,提供了相当靠谱的容错机制,且很容易扩展和加入自定义的 Metric。Ganglia 的一个比较有名的用户是维基百科,可以通过 这里 访问他们的 Ganglia 实例,从上面可以看到维基百科的集群运行状况。

1. 安装

我们的服务器环境是 Redhat Enterprise Linux 6.4 x86_64 版,本文基于这个发行版来介绍安装和配置。其他发行版或者架构也都大同小异。

Read on →

Java 服务端监控方案(一. 综述篇)

换成 Octopress 后,写文章比以前简单多了,博客访问起来速度也快了不少,借这个把过去一段时间的技术积累总结整理一下。作为开始,我准备写一个系列文章来总结一下去年到今年在公司做的一些关于 Java 服务端监控的工作。

对于任何一个服务端应用来说,监控都是至关重要的一环。一个系统在运行过程当中太容易出现故障,网络、存储、系统负载、软件 Bug,任何一个点出现问题都有可能影响到整个系统的稳定运行,因此,监控必不可少。一个完善的系统监控方案要从两个方面帮助我们:

Read on →