背景

过了年leetcode的用户量渐渐起来了，1台服务器已经有点吃力，当高峰的时候经常有些请求超时。而且为了防止服务器的单点问题，需要部署多个replica以保证高可用性。之前的架构已经是在kubernetes集群上了，因此扩容相对而言比较容易。整个webserver的架构如下图所示：

背景

kubernetes中的集群发现有两种方式，一种是环境变量，还有一种就是dns服务。对于环境变量，在使用上有一些限制，它依赖于svc和rc的启动顺序: 如果rc先于svc启动，那么pod里面就没有相关svc的环境变量，这种方式违背了kubernetes的理念，即资源之间是解耦的。推荐的方式是使用dns的服务，这篇文章主要关于部署skydns的过程以及其中遇到的问题和采用的方式。

背景

去年年中我使用ansible给项目部署了一个小型的kubernetes集群，部署源码可以在这里找到:contrib。随着业务的发展，目前的集群规模很有可能在明年迎来瓶颈，因此需要 扩容.当然可以继续通过之前的contrib去部署，不过有几点担忧：

1. 目前的系统稳定地提供着服务，ansible脚本可能会对集群产生不可逆的影响
2. 对于contrib的代码不是特别熟悉，不清楚它具体做了哪些步骤，总体来说还是不放心

同时，作为一个system admin，对于集群必须了如指掌才行。因此，在这里做一次演练，手动为已有集群添加节点，增进了解，也为今年的扩容做好准备工作。

背景

最近我操刀了leetcode的论坛迁移，整个过程持续了几周的时间，总算暂时告了一个段落。常使用leetcode论坛的用户应该已经发现论坛已经大变样了吧~
期间遇到了不少坑坑洼洼，将来也还会有好多问题等待去一一解决。关于这个迁移过程中的收货，这篇文章中就不细说了，有时间再另开一篇博文。这篇文章主要关注在url-mapping以及它的性能问题。

问：url-mapping的问题从何而来呢？
旧的论坛和新的论坛是两个不同的discuss框架。前者是phpbb，现在是nodebb。两者的 url routing 完全不一样，比如说同一个topic，
在原来的url是:
http://hostname/discuss/<topic_id>/<topic_name>
在新的论坛中是:
http://hostname/topic/<topic_id>/<topic_slug>
(这里就不讨论两者甚至连topic_id都不一样的问题了)。
而在广袤的互联网海洋中，旧论坛的url可能到处都存在。我们不希望在论坛迁移后，用户点那些链接就失效了。我们希望的是用户访问旧的url可以被重定向到新论坛的某个地址。所以就产生了url-mapping的问题。

前言

这篇文章其实主要是记录我在安装kubernetes集群时遇到的坑，然后是如何解决的。关于kubernetes的概念，以及安装kubernetes的详细流程将不在本文涉及。

问题背景

我已经在Digital Ocean成功部署了一个小型的kubernetes集群，包含一个master和一个slave。部署的方式是使用ansible，这里有一个项目可以参考contrib，按照里面的配置配一下，就可以一键部署集群了。

由于linode机器比DO的机器性价比高一点($40/month这一档前者是4核的CPU，后者只有2核)，所以想把集群迁移到linode上。然而在使用脚本部署的过程中总是报错，查了一下发现kubernetes的flannel网络层插件始终起不来，查看了systemctl的日志，发现flannel无法初始化vxlan的网络，具体症状可以参考这样一个issue。

题目链接: https://code.google.com/codejam/contest/32016/dashboard#s=p1

分析:

注意到每个customer最多只能有一种奶昔是”malted”的，这点是解决这题的关键。可以推出以下结论:

1. 如果所有用户至少有两种喜欢的奶昔，那么必然有一种是”unmalted”，那只要保证所有奶昔种类都是”malted”就解决了。
2. 如果有部分用户只喜欢一种奶昔，如果该奶昔是”unmalted”的，那么可以不用管它。
3. 如果有用户喜欢一种奶昔，且”malted”，那么需要处理

背景

这两年go语言比较火，尤其是在服务器并发方面表现很好。一直想学一下，但是拖到现在。最近正好有这个机会，把go语言算是入了个门吧。

前言

去年有一段时间一直在研究各种python协程框架，包括gevent, asyncio, tornado。阅读tornado的源码还是两个多月前的事了，一直想写一篇文章出来整理整理，但不知道从何处开始下笔。如果贴上一段段源码，然后通过语言来描述各种流程，这种类型的文章网上也有不少，况且这样子的讲解对于读者来说可能会比较乏味。

背景及介绍

最近接触一个项目，用到了celery, 故对其作一个学习和了解。celery是一个基于Python开发的并行分布式框架，在github上可以找到。

又是两周没写博客了，圣诞夜来水一发~
今天稍微看了下async的源码，感觉很简短精炼，总共也才1000多行代码，好多值得学习的地方。主要看的是waterfall模块，由于源码中有好多不同接口公用的部分，因此看完waterfall这个接口的整个流程，差不多就cover了一半的async源码了。