几个月前部门内容组织了一次系统设计的议题，分到我们头上的题目是设计一套灰度发布系统。嗯，然后我们就精心设计(参考公司现有系统)了一番，不过鉴于滴滴现在大部分的人都是百度来的(误，所以这种系统大概也都是差不多的思路实现而来的。所以感觉应该算是一种通用系统吧~
为什么要有灰度发布系统？灰度发布是现代互联网公司比较必然的一种需求，像滴滴这种规模的公司，千万级的司机和亿级的用户，如果不经小规模实际业务场景测试(代码本身的测试流程先不算)就对线上流程贸然修改、重构并且上线，必然会造成群体性事件，影响到公司的形象，伤害到终端用户，并最终波及到码农可怜的年终奖。而灰度发布能带来什么样的好处呢？可以让你少伤害一部分用户啊~如果出了问题，回滚或者对影响到的用户进行补偿都很方便(毕竟钱能解决的问题都不是问题，但规模太大的时候补偿手段就不好使了。
实际上在一个系统的灰度策略执行期间，老的逻辑和新的逻辑的代码在线上系统都是存在的。这样说的话可能有些人会提出异议，我们在做代码发布的时候先发布一台机器，然后再发布十台，
beanstalkd是一个使用还算广泛的开源消息队列，由c语言编写。因为本身功能简单，代码也不多，所以阅读可以帮助我快速复习一下网络编程，并且麻雀虽小，五脏俱全，一个c语言项目的方方面面它也都包含了。
---入口
万事先从main函数开始：
int
main(int argc, char **argv)
{
//用来存储服务端生成的socket的fd
int r;
//job的链表
struct job list = {};
//程序名字
progname = argv[0];
//设置为行buffer模式，具体参见man手册，遇到换行即发送到目标
setlinebuf(stdout);
//解析输入参数
前段时间前同事找我看了这么一段代码：
(new Pipeline($this->container))
->send($passable)
->through($middleware)
->then($destination);
是laravel框架里看起来很直观的一段调用逻辑，把container注入到Pipeline对象，然后将passable(其实一般是$request对象)发送通过一连串的中间件，最后到达目的地(最终的processHandler之类的函数)。
看起来很不错是不是，再看看laravel内部的实现，代码在Illuminate\Pipeline下：
class Pipeline implements PipelineContract
{
protected $container;
/**
* The
其实有了那篇服务开发总结，这篇看起来没什么必要了，不过作为纯技术的总结还是发出来吧。
在前几篇中说到了es的jdbc工具，这个工具确实挺好，可以满足一些不想要开发量的小公司的要求。
但从我们使用的过程中也看出了这个工具的一些缺陷：
1.方案强依赖于数据库表的时间戳。
不靠谱，你不能要求你的业务RD或者老的遗留系统能够满足你的这些规范方面的要求(刚从dc出来的时候感觉很多规范方面的事情是应该做的，但根据工作经历来看，设计技术方案最好还是要考虑到最坏的情况)。
2.这个工具每一个脚本只能执行一条sql语句。
这是一个比较重大的缺陷，因为工具本身是java写的，这就意味着每个脚本都是在独立的jvm里跑。而jvm，你懂的。基本一台64GB的机器跑个七八个脚本，再加上es本身，内存就快要爆掉了。而实际上这件事情本身不应该需要这么大的硬件成本。
3.读写分离问题导致的数据延迟问题。
这条其实是1衍生出来的，同样考虑最坏的情况，主从延迟如果到了一定程度，那么在脚本运行期间内会导致时间戳前进之后，有旧数据入到从库。那么脚本的逻辑就会产生数据丢失。
前几天在公司做了一次分享，其实是类似于工作汇报的东西。。。顺便记了一些东西，整理一下吧：
这个服务完成了的事情
1).独立的es集群
目前线上正在运行的版本是1.7.3
三台机器，总数据量大概在100G左右(算上分片的冗余)
集群上安装有head、bigdesk、ik分词器等插件
存在的问题：
es版本其实已经有点老了。。官方在2.1和2.2又加入了一些新特性，这些特性在老版本里我们享受不到，当然现在的接入功能也比较简单，也不一定用得到。但不升级自然就享受不到官方版本升级带来的红利：新功能，新bug
2).在es之前封装了一层web服务
用golang的web框架gin
> https://github.com/
