一年前装自信的挖了个坑 为啥我要从阿里离职 今年来填一下坑。

Docker 的出现使开发测试生产环境的统一变得更加容易，然而在使用 docker 搭建这一整套流水线之后，却发现它运行的却不能像丝般润滑，总是感觉没有直接本地开发测试来的效率高。为了能达到一个高效流水般的持续构建，我们来看一下这个过程中 docker 的使用以及 docker 自身存在着哪些问题，我们又该如何克服这些问题，达到如丝般的润滑。

Borg 是在传说中流传已久的 Google 内部集群管理系统，现在火热的 Mesos 和 Kubnetes 都是源自于 Borg。今年 Google 把论文放出来了，第一遍读感觉通篇细节没有什么太多值得玩味的，在这个行当干了一阵再读发现细节是魔鬼，每个细节都对应这一个实际中难解的问题，再读第三遍，不得不做一些笔记了。

为啥我要从阿里离职？

本来想起个宽泛点的标题，这个标题感觉太像要爆大料了，但是关注我的人应该也知道我在哪个厂，所以也就无所谓了。相对比来说估计大多数人其实不太关注我而是关注阿里这个公司，那我就先说说我眼中的阿里好了。

我眼中的阿里

阿里没有在外面自己宣传中好的那么妖孽，也没有各种传言消息中坏的那么邪乎，总体来说还是个互联网大公司的模样，大家有的优点也都有，大家有的通病也少不了。在我接触的厂外人中既有把阿里当成天堂，无论如何什么岗位都非进不可的；也有黑起来黑的暗无天地，明天就要关门倒闭的。我想说的是没有必要过分神话或者黑化阿里，阿里是个普通的大公司，需要理智和清醒的看待。我也试着从不到一年的供职经历谈一下我的感受。

阿里并不是一家技术导向型的公司，这几年随着双十一以及引入的一批业界大牛，阿里的技术口碑传的神乎其神，但说到底这还是一家业务为主导向的公司。这点倒是没有什么问题，企业还是要靠业务吃饭的，而技术也只是解决业务问题的手段。而阿里的强点在我看是在销售、运营、公关以及整体战略方面，技术目前看还算不上核心优势。在阿里这个体量下技术的选择和使用也是趋于保守的，再加上诸多的历史遗留因素一些外面很火热的新技术以及新的技术管理工具在阿里内部推广还是有一定阻力的。毕竟很多情况下稳定是第一要素，技术选型以及使用上不会像小公司和创业公司那么灵活。在大数据和云计算领域，阿里有着很好的先发优势以及知名度，但是历史包袱也很多，现在要和国内一水的创业云计算公司竞争，技术角度的优势没有明显到可以秒杀的地步。当然这里面还是有各个领域大量的技术大牛在压场，技术优势还是有的，但是工程师文化和技术导向，在这里其实并没有广泛的提倡。

阿里的福利待遇没有那么妖孽，50个月工资什么的肯定不是普遍现象，很多关于薪资的新闻其实是抓眼球罢了。也有不熟悉的师弟师妹，上来就问我股票为什么不给了，薪水是不是低了点之类的。毕竟阿里上市了，很多机会窗口也关闭了。而且我印象里阿里一直是以抠门著称的，不知道为啥这几年都觉得阿里应该薪水高一个档次。阿里的工作强度和其他一线互联网公司应该也不分伯仲，同样薪水也差不了太多。不过阿里前几年的效益不错，所以奖金红包之类的比较丰厚，上市老员工又有一部分股票加持，但是对于现在大多数人来说想轻轻松松躺着赚大钱是不太现实了。话说回来，五道口一带的两个钱多活少的公司不是最近也关门了么，对于那些关门又去 IBM 的就只能祝好运了。而且在我看来尽管阿里待遇不妖孽，但是打工来说已经很不错了。至于免费水果零食、丰盛的工作餐、过年过节各种礼品什么的这个就不用想了，这个真没有，感觉阿里是把这部分钱省出来去发年终了。

在阿里很开阔视野，呆了一年技术和业务的视野都开阔了很多，毕竟阿里在国内电商、大数据和云计算还是处于领先的地位。以前想到大数据只知道个 hadoop、spark 在阿里有幸接触到了这个链路和生态，现在的认知已经完全不一样。以前想到的客户就是普通消费者，现在看到的都是 2C、2B、2医疗、2金融、2部委、2央企，看到了不同的类型，看到了更广阔的市场。一开始提到这些客户都感觉要死人了，之后感觉也就这么回事，这份经历恐怕只有在阿里这个平台才能让我体验。各种八卦、江湖流言、政治斗争、传奇故事也着实让人开眼。

言论还是相对自由的，我对言论自由的限度是可以自由表达观点但是不能有人身攻击和阴谋论的揣测，这点来看内网风气还是基本符合的，一些批评和建议都能得到很好的反馈。但是除了有几根高压线悬着的地方不能公开讨论外，内网总感觉笼罩在所谓的价值观阴影下有种自我阉割和自我审核的感觉。当初把知乎上传的沸沸扬扬的校招 hr 的事情转到内网，那个问题影响有多大学生们应该很清楚，在内网也热帖了很多天。这期间也没人来找我麻烦，还有负责校招的 hr 来承担责任。但是下面回帖的居然有质疑我价值观的，说我不该转发的我也是崩溃了，外面的事情都不能让内部人知道了，是要给阿里人也竖一道墙么，不带这么自我阉割的，这要是价值观也能扯上，这公司就不用呆了。传闻阿里对外的公关很厉害，由于总感觉在职期间公开讨论公司好坏不太合适，索性这一年阿里的好坏两方面消息我都不怎么宣传也就没啥机会体验这些公关。不过鉴于我这个小P也没啥影响力可能说了也不会有人来找我。

hr 问题没有那么恐怖，由于阿里十八罗汉中就有两位 hr，所以 hr 在公司中的位置还是很重的。阿里最近的风波在我看来是一个主管失误，hr失误，开发失误之后公关和管理又连续失误把一个雪球越滚越大，陈年旧账新仇旧恨全滚起来了，hr 的问题只是其中一环，整条链路都出现了问题。不过上市后这种全链路的问题出的太多了，加之阿里的任何事情现在都会有放大效应，就闹得感觉阿里人间地狱了。事情实际的真相、官方的真相、传言的真相以及每个人心里所希望的真相已经千差万别了。对我来说离职面谈和 hrg 感觉还是颇长见识，很后悔之前没有机会多聊一下，离职评语信息泄露的 bug 我也赶上了，至少对我的评语正常到让我都没看第二眼。过了快两周才通过这个风波发现原来那些评语是我不该看的……

总体来说，我的感受阿里并不在童话中，也不在地狱中，就是现实中的一个正常公司。如果有公关想改变我的文章倾向，那我告诉你我是有节操的人，你必须给大钱才行。

我为啥要离职？

入错行当，算是被当年招聘的职位给忽悠了，做的事情和想象中差距大了些，这是个主因。应届生校招总会有这个问题，就是对职位信息不了解，而校招时应届生对有份工作，有机会进个公司的饥渴度超过了一切，而忽视了职位和方向的信息。我见过有的人找我内推，先是说算法完了又研发，听说我在运维又问运维有没有坑，一副只要有机会进来就行的感觉。这种我都会让他再好好想想方向是比公司重要的，校招其实就是个入行的过程，只要行当和你路线相符之后有的是机会，公司待遇都是个次之的因素。这也是我为啥一年工作经验都没满就要转的原因，因为我已经感受到了之后求职的时候别人都会根据你前一份方向来划定你的范围，之后会越来越窄，所以宁可扔掉阿里的 title 和待遇也要再重新入一次行。So，如果是应届生选工作的话建议还是要更关注方向和做什么事情上，不要脑子里只挂着公司和待遇。

兴趣使然，一方面外企，国内互联网大公司都见识过了，也想看一下小公司是不是传说中的小而美，也算是一种新的体验。此外自己在 docker 这块关注了一年多，一直觉得这是个机会，尽管总会有下一个机会，但还是按耐不住要去试试。之前只是在外围看看代码写写文章，只是业余时间搞搞感觉和大家的水平越拉越大，现在既然有机会去玩真的就去真刀真枪试试，大不了回头再写个我为啥从小公司离职之类的拉流量。趁着年轻再出去闯闯，实在不行回来专攻博客写科普写软广讨口饭也行。

然后我要回帝都了，求帝都的大爷们包养收留，剩菜剩饭、不要的旧衣服、矿泉水瓶、纸盒子什么的留点给我。

欢迎大家理智的讨论，人身攻击或者阴谋论的我是会删的。

最后欢迎分享链接到微博朋友圈各种地方。转载要和我商量，要是不和我商量就拿走我是要去告你的。

最最后插个软广，我司在做 Docker 镜像构建挑战赛，学着写 dockerfile 还有奖品拿，还在等什么 http://event.alauda.cn/，现在报名还来得及。有意加入我司的也可以邮件联系我，你到底是要看浪还是要冲浪？

机房断电后各种服务该怎么恢复呢？

首先当然是恢复供电机器重启，但是上面的服务该怎么办，派人去手工重启么？

一个服务还好，但是一个机房这么多服务敲命令要累死了，怎么办？写个脚本执行启动命令，放到开机启动脚本 rc.local 里好了。

可是掉的不止你一个服务，可能你启动依赖的服务也掉了，启动的还比你晚，启动根本就起不来怎么办？

一个简单粗暴的方式，不断重试就好了。在 cron.d 下面放个任务每分钟执行一次，一看服务进程不存在就尝试重启。一方面不考虑依赖问题，另一方面还顺道解决了服务 crash 后的自恢复。

可实际中有的服务在依赖没启动时是可以起来的，但是工作会不正常，而且不能再依赖启动之后自动恢复，还是需要手动重启。严重的时候不正常的服务还会导致依赖它的服务异常，这该怎么办呢？

看样子似乎是无法摆脱依赖顺序而随心所欲的启动程序。那么就只能所有的服务各自汇报自己的服务上下游给一个人，然后那个人画一个启动流程图，告诉大家先干这个，再干那个么？嗯，一个如果机房里业务固定还好，如果不固定，今天加一个新应用，明天减一个旧应用，那么图就要改一遍。应用改个依赖，图又要改一遍，而且要这个画图的人时刻了解服务依赖的变化，想想就头疼。那么就没有个自动化的方法么？

可以先参考一个类似的问题，systemd 是如何解决单机上开机程序之间的依赖问题。程序之间的依赖本质上来讲就是需要进行进程间的通信，而开机程序的进程间通信主要是通过 socket 和 dbus 来完成。systemd 的做法是预先建立好这些 socket 和 dbus，这样当一个程序发起通信时即使依赖程序还没启动完成，至少 socket 是打开的，可以先把请求 queue 住。这样发起请求的程序就会等待，而等依赖就绪就会处理这个请求，源程序就可以继续运行。这样理论上讲大多数情况下我们都不需要考虑程序间依赖，只需要把所有程序启动起来就好了。

实现一个分布式的 systemd 还是有些困难的，但是这种思想很有启发。我们可以脱离集中化控制的思想，把分布式系统的重启任务分布式的解决。分布式服务之间的依赖本质上也是进程间通信，而且绝大多数都是 tcp/udp 请求。简单的来说一个服务只需要判断他的上游服务是否 ready 来判断自己要不要启动，每个服务只需要在自己的机器上验证这个条件，不断地重试，整个服务就可以自动的按照顺序自发启动。

这样的话我们就无需一个集中式的管理，每个服务自己梳理自己的依赖来进行自启动即可。除了简单的 tcp 探测也可以对 web 服务进行 http 的探测来进一步保证依赖的可用性。

在 github 上新建了个项目可以简单的通过一个 yaml 配置文件描述进程名，依赖和启动脚本，即可自动生成自启动脚本，大家有兴趣的可以去尝试一下 https://github.com/oilbeater/Autoheal。

把 README 抄录入下

Autoheal

A simple script that auto restart distribute service from power cut or service crash.

Where it come?

All services will crash after a power cut.When power comes back, services recovery may face these problems:

1. No auto restart and service will not work
2. Service restarts before dependencies getting ready and restart may crash.
3. Service restarts before dependencies getting ready and the service can not work correctly.

What we want is ordered restart.But as more and more services connect together,it’s complex to find and maintain a global order. What we provide here is a simple way to deal with th problem.

How it work?

A centralized restart system may hard to implement,but same effect can be achieved by other method.Let’s have a look at how systemd deal with the process dependency at startup time.

Processe dependency is caused by inter-process communication (IPC) in essence. Socket and dbus are two main way of IPC during startup time.What systemd dose are pre-create these sockets and dbus,parallelizd all process and queued the request before corresponding process get ready.The process will be blocked when dependency is not ready and continue work as dependency starts to work and finishes the request.By this way most time no order need to be explicitly pointed out.

Inspired by systemd, we can deal with distribute services restart distributly.Every service checks its directly dependency and start as they are ready.No more global order is needed,different service can restart automatically.Most service are connected by tcp socket or an application layer http protocal,Linux command nc and curl can be used to check these services.

This program Autoheal provide an easy way to generate a script combining checking process liveness,checking dependencies and restarting process together. # Running

1. Installing the pyyaml dependency

    sudo pip install pyyaml
   

2. Writing conf.yaml as following example:

    nginx:                                                                # process 1
        pname: nginx                                                      # use progess name to check process exist
        script: sudo -u admin /home/admin/cai/bin/nginx-proxy -s restart  # restart the process
    web_service:                                                          # process 2
        pid_file: /home/admin/web_server/conf/.web_server.pid             # use pid file to check process exist
        dep:
            - name: nginx                                                 # check tcp dependency
              host: 127.0.0.1
              port: 80
            - name: middleware                                            # check http dependency
              url: http://middleware.host.com/check.htm
        script: sudo -u admin /home/admin/web_server/bin/startup.sh
   

3. Generate the restart script:

    sh generate.sh >> restart.sh
   

4. Add a cron task to run restart.sh regularly.You can create a file in /etc/cron.d like this

    * * * * * root sh /home/admin/startup.sh > /dev/null 2>&1
   

   Note about the user privilege to start the process correctly.

统计一下 2014 年博客的整体情况，顺便夹带写如何用第三方服务和推广的私货。虽说不能和知名博主们去比，不过能看到成长总是欣慰的。

致谢

首先要感谢这些为我的博客提供服务的兄弟们。

感谢 Gitcafe 提供的 page 服务以及域名映射，你们的服务很优秀，尽管除了这神奇的土地上独有的问题，但是你们的应对使事情变得可控。

感谢七牛提供的存储及图片外链服务，几经辗转终于在国内找到优秀靠谱的服务。

感谢 Google Analytisc 为本片博文提供的数据，以及长久来的统计服务。

感谢 dnspod 的域名解析，你们的切换速度越来越快了。

还有 Godaddy 的域名，已经打算继续打赏你们了。

流量分布

尽管用了百度统计插件做 backup，但由于是中途用的，全年完整的数据只在 Google Analytics 上有。通过两者的对比发现 Google 统计的数量要低一些，对此只能亲切问候长城作者了。

由于今年有几篇投机取巧的文章，再加上恬不知耻的四处推文章，日均 pv 居然过百了。不过访问深度连 2 都没到，很多人都是点进来看了一下就走了，没有吸引人去看其他文章，可见博客的质量还有待提高。

流量已经覆盖到了南极洲外的所有大洲，不过当然主要还在亚洲，不过看到有非洲的兄弟们还是很新奇。

流量来源最多的国家，当然是伟大的社会主义中国了。不过黑暗的资本主义国家已经能占据接近 14% 的流量了，尤其是万恶的美帝居然爬到了第二的位置。

下面再来看一下中国各个城市所占的比重，这也是我最喜欢的一张图能反映很多社会状况。

可以看到北京这个超级点处于明显的统治地位，那里是互联网和 IT 人士最多的地方。接下来就是长三角区域以上海、杭州为首的大点，南京、苏州、合肥次之的中点，带着宁波、无锡、徐州等一众中小点密密麻麻的挤满了长三角。可见长三角区域是一个地域的整体发展而不是像北京那样的方圆百里唯我独尊。接下来就是珠三角区域了，如果把香港加进来的话，珠三角区域有着香港、深圳和广州三个大点，但是明显存在着断层，没有中点，直接就掉到中山、佛山、东莞这样的中小点了。

整体来看点在东部沿海比较密集，而中部地区就只有成都，西安和武汉三个中点也是各个地区的头牌城市了。在广阔的西部真的就是稀疏的可以忽略了。还好拉萨的兄弟给面子让我在这一年成功覆盖到了中国所有的省份、直辖市以及自治区。在 Google 的统计里，香港、澳门和台湾都属于地区和国家是并列统计的，所以不要再问我为什么台湾没点，和我没关系。

流量来源

下面是访问次数最多的页面

可以看到访问次数最多的是当时写的和阿里大数据竞赛相关的文章。由于我的好为人师加上投机取巧，拉住了一帮人来看，顺便带动了其他页面访问量的上升。而之后的什么是 Docker 又借着 docker 的风口被吹了一把，还被 csdn，infoq 的转载。而这些年计算机学生路总结资料 以及从输入 URL 到页面加载完的过程中都发生了什么事情 都算是我的呕心之作，虽然没站在风口上，也取得了不错的成绩。可见博客要想被人接受，要么站在风口上，要么就要呕心沥血出质量。

接下来就是很多有独立博客的人都关注的流量来源了

排名第一的居然是 direct 的方式……这个是最让人头疼的，因为无法判断是怎么来的，我的猜测就只能是一个人看到后发现不错就把链接发给另一个人这样了，如果真是这样的话说明我还是有文章打动人的。

之后就是互联网交际花冯大辉的 startup news 了当然域名是奇怪的 news.dbanotes.net。尽管流量很高但是最近上面文章的质量实在是不敢恭维啊…… 下面 aliyun 论坛那个就是阿里大数据竞赛那一阵风吹得，以后估计就没了。

在下面 I love Google。google 对我博客的收录和关键字 rank 都很友善。反观百度我就无力吐槽了，排名靠前的都是那些抄袭我文章的网站。不然的话很难想象国内为主的博客的搜索来源比重 google 居然是百度的近 4 倍。

在下面的 weibo 是今年中点发展的一个来源，在博客内加上微博秀后，微博的粉丝数从年初的 80 多到现在居然过 700 了，虽说现在的比重还不大，不过是个很好的让老用户再来关注的方法，如果能再多认识几个朋友那就心满意足了。

再往下就是往各个收录博客的网站去推了，主推的也就 csdn,jobbole 和 toutiao 了。其中居然又一次被码农周刊给推荐了让我不胜荣幸，当然后来发现过来的流量也不是很大……不过码农周刊还是很不错的博客资料聚合的网站，推荐大家关注。

展望

上面就是我这一年连蒙带骗赚流量的故事。这半年工作缠身没有太多精力来打点博客，接下来一年争取能做到一月一更到两更，希望新老读者有兴趣的可以持续关注。去年的文章还是有几篇偏水，不过你们要相信我会严格要求把控自己的，质量绝对是有保证的。方向的话有可能还是偏网络和系统方面的一些初内容。太深入的可能还欠火候，但是读过我之前文章的朋友应该知道我保证能要你读明白，不无聊而且有收获（求大牛们轻虐）。也希望能和大家进行更多的讨论和交流。

作为一个 nginx 的初学者记录一下从零起步的点滴。

一直对 docker 提供的容器感到好奇，不知道究竟是如何实现隔离和保证安全的，之前 docker 本来是用 lxc 来提供容器功能的，但是由于对内核代码有一丝恐惧没敢去看，后来听说 docker 为了实现跨平台兼容自己实现了一套 native 的容器就是 libcontainer 。既然是新项目那么代码量和复杂度应该都不会太高吧，抱着这个想法我就翻看 libcontainer 的代码读一读。