通用分布式任务调度系统设计
目标设计一款可靠、易用、可扩展、轻量的通用分布式任务调度系统。暂且将此系统称为：fusion-scheduler，融合各类业务的调度系统之意。 可靠：采用分布式设计，避免任务丢失，支持对失败任务的自动或手动重试 易用：支持固定间隔、固定延迟、CRON 表达式、API 触发、工作流、MapReduce 等调度方式，满足各类业务需求 可扩展：支持动态添加、删除任务、动态修改任务配置，支持动态添加、删
分类: essay
通用分布式任务调度系统设计
目标设计一款可靠、易用、可扩展、轻量的通用分布式任务调度系统。暂且将此系统称为：fusion-scheduler，融合各类业务的调度系统之意。 可靠：采用分布式设计，避免任务丢失，支持对失败任务的自动或手动重试 易用：支持固定间隔、固定延迟、CRON 表达式、API 触发、工作流、MapReduce 等调度方式，满足各类业务需求 可扩展：支持动态添加、删除任务、动态修改任务配置，支持动态添加、删
proto 3 VS proto 2
proto 3 是 proto 2 的简化版，当前两个版本均处于活跃状态。 常见问题proto 3 和 proto 2 是导线（wire）兼容的：这意味着若在 proto 2 和 proto 3 中构造具有相同的二进制表示，那么它们可以跨版本引用符号，并生成配合良好的代码。 区别存在性（optional） proto 2: 原生支持 optional。新应用中可以使用封装（wrapper）类型来表
微服务：代码分层
本篇是微服务系统的第一篇，我将基于自身的经验和在公司项目中的实践来记录我们施行微服务的过程和方式。
微服务下的用户系统设计
简述微服务下的用户系统从设计与传统单体应用是不一样的，传统单体应用下本质上用户系统是一个模块。用户系统是与整个应用紧耦合在一起的，具体来说，它们共享一套代码、一个数据库、通过代码级的API调用…… 而微服务下的用户系统设计很不一样，因为微服务的特点，各功能都独立成一个Server在运行，那用户系统首先需要支持远程的API调用。基本来说，微服务下的用户系统设计需要满足以下要求： 独立的用户系统：用
ETL里的34个子系统
ETL里的38种子系统和ETL里的34种子系统Ralph Kimball和Joe Caserta于2004年编写的《The Data Warehouse ETL Toolkit》一书系统的阐述了ETL这一概念及建设ETL系统的要点，将ETL从BI的一部分抽离了出来。随后，这本书里的一些思想形成了一篇文章《ETL里的38个子系统》，系统总结了ETL项目要面临的不同任务。我们还可以在网上找到原始的这篇
2015总结暨2016展望
2015已过去，2016到来。展望未来也总结过去。 20152015年到了一家新的公司，是一家做大数据服务的创业公司（准备说是2014年底）。刚到公司时我们只有几人，到现在已经成为一家50人左右的中小型互联网公司了。上半年我们尝试过个人社交、电商、招聘、监控等方向，到现在确定到了企业数据服务上。一路走来，从快速试错到确定目标，还是颇为不易的。 说完公司，再来谈谈个人吧。对于我自己来说，今年还是很有