作为一名软件工程师，主要精力都集中在「开发」和「维护」上，特别当项目开展时间足够长，维护所花的精力就更多了。 而人的生命是有限的，为了享受人生乐趣，我们应该在有限的时间内完成更多的事情，想办法能更有效率地「维护」项目。

回想一下我们刚接手一个项目的时候是怎么开始「维护」的呢？ 大概是看 README、看文档了解使用的技术栈，随后我想一定是离不开阅读代码。 按照经验，我们不难得出一个结论，想要「维护」一个项目，那么一定要「读」懂项目代码。并且读得越快，理解得越好，越容易着手维护项目代码。 所以想要让项目更易于维护，我们首先需要写出可读的代码。

今天我将从 Clojure 这门语言入手，谈谈它的可读性，之所以会选择 Clojure 主要是：

1. 过程几年都在维护 Clojure 的项目，有一点小心得。
2. C-like 可读性相关的论述已经足够多，但函数式语言则不多 ...

前言

昨天「去哪儿」开源了自研的 IM Startalk，作为一个在 IM 领域划水了一段时间的人，也想了解下其他人是如何去考虑 IM 设计，所以就开始了源码阅读之旅。接下来会用几篇文章简单分析一下。

本篇分析的是 Cowboy HTTP Server.

结构

基本采用了 Cowboy HTTP 框架实现，路由表保存在 config 中： config/ejb_http_server.config，让我想到 Haskell 的 yesod Orz。 于是整个项目就相对比较清晰了。 下面挑几个感兴趣的 API 来分析。

获取在线用户

http_getonlineuser.erl

从这个 module 可以看到几个点：

1. 在线人数是通过 ets 缓存到 erlang 内。
2. 用户会根据 ...

前言

昨天「去哪儿」开源了自研的 IM Startalk，作为一个在 IM 领域划水了一段时间的人，也想了解下其他人是如何去考虑 IM 设计，所以就开始了源码阅读之旅。接下来会用几篇文章简单分析一下。

本篇分析的是 Search.

介绍

简单浏览了代码，可以看到 IM Search 是基于 Flask 开发的，而且是单例运行的，带有几个全局变量，甚至还运行在 debug 模式下。没有使用 gunicorn 等 Server。

qtalk_search 提供了搜索用户和搜索群组的功能。

搜索用户

搜索用户是通过一次很晦涩的 SQL 查询得出的，核心 SQL （原本不带分行的，格式化了一下...）:

sql = "select aa.user_id,aa.department ...

前言

昨天「去哪儿」开源了自研的 IM Startalk，作为一个在 IM 领域划水了一段时间的人，也想了解下其他人是如何去考虑 IM 设计，所以就开始了源码阅读之旅。接下来会用几篇文章简单分析一下。

本篇分析的是 HTTP 负载均衡.

基于 OpenResty 增加相关能力

核心基于 OpenResty，利用 lua 扩展 NGINX 本身的能力，增加

1. 上游服务探活
2. 用户鉴权
3. 用户级黑白名单
4. 频率限制

上游监控

使用 https://github.com/openresty/lua-resty-upstream-healthcheck 做 upstreams 的探活，并生成报告页面。

鉴权

对 /newapi/ 和 /package/qtapi/ 会做鉴权 ...