[TOC]
坐在家里的书桌前，晒着新年的第一缕阳光，闻着老妈拿手菜的香味，开始了《我的2016》系列的第二篇 – 工作上让我引以自豪的两个项目。
还记得年前有一次和室友教授一起讨论关于工作加班的看法，室友是做APP后台开发，处于业务的前线，每周或者两周都会有版本更新任务，且经常受PM各种方案频繁变动的困扰，处在一种每天都很忙的状态，并且据他所说有时会重复性劳动，所以加班频频。
而我是做相对偏底层的存储开发，在团队两年多跟PM打交道甚少，所以并不能深刻理解室友说的“PM烦恼”，自然而然我就跟室友说起了我在公司团队的工作内容和状态，现在回想起来其实就是16年我自己最喜欢和热爱的两个项目。
数据流动 – Flow
为什么需要流动？
大家都知道我是做云存储相关开发，上游产品就是常年IOS效率榜第一位的百度网盘，各位上传到网盘的数据（图片／视频／音乐／文档…）最终都会落到我负责的这一层来，由我们进行相关的数据整理后并实现磁盘存储落地。
但是随着网盘的用户越来越多（亿+），用户的数据也呈爆发式增长，而我们将用户的数据存储在多个城市的机房中，多地存储有这么几个原因：
- 防止单个机房出现问题，整个服务不可用。
- 中国太大，华东华南华北华中等不同地方的网络差异太大，为了更好的用户体验，所以不同地方的用户访问尽量就近。
- 配合公司整体机房部署的安排。
但是这里有个问题，就是我们的数据不是说存在某个机房就永久不再动了，有时候也会因为机房退租，昂贵机房数据迁移附近廉价机房，冷热数据分离等原因，需要将我们的数据挪一挪地方，怎么实现呢？ – 那就需要我们有一套自动化数据流动系统，让我们的数据能够在全世界机房间自由的穿梭。
我们想要的是什么？
其实15年年底，我就已经实现了一个流动demo，可以将指定的数据从一个源地址搬到目的地址，并能够保证安全／可靠／一致性。但是实现完后还是有一些让人不爽的地方：
- 触发流动这一步，需要通过部署各种脚本来实现，过程麻烦且维护成本较高，经常因为机器变动／性能不达标等原因，各种改改改！任务少还好，一旦多起来真会让人疯掉。
- 流动完成后，做成功校验也是麻烦事，需要用脚本去check数据库中的状态，来确认是否流动成功。
- 流动过程中不清楚进展如何，完成了多少，成功多少，失败多少，这些都是在全部结束之后再做一轮统计之后才知道。
- 核心处理模块虽然已经具备搬迁能力，但是和上下游联动较差，新人接手或者同类型任务启动，需要重走一遍这些复杂的流程，横向展开成本较高。
所以基于以上原因，15年过完农历新年回来之后，我就重新思考了一下整个数据流动。就是回答“到底想要把流动做成一个什么样的系统?”这个问题。
其实一直以来我对好项目的理解是：简单可依赖！
何谓“简单” ，首先重复的东西能用流程化的程序替代尽量不要用人工一遍遍redo；其次不需要或者不太重要的尽量不要加，好的程序都是尽量做减法，而不是加法；平台化很重要，尽量让横向扩展更容易。
那么什么算可依赖呢？其实就是结果和质量的保证，这涉及到程序的算法，性能，以及各环节如何更好的契合。
想好了我们的流动要做什么样子之后，我开始从上到下梳理各环节：
Producer -> Flow Core System -> Sinan -> Result Check
(生产者 -> 流动核心系统 -> 进度展示平台 -> 结果校验平台)
梳理完各环节之后，我开始写各环节的整体方案，并且在思考有没有可能和其他团队已有的平台合作。
- 生产者：之前我们的任务触发都是脚本完成的，而我们团队有一个team是做Hadoop和Spark数据处理的，并且最近他们也正在做平台化支撑的事情，所以当时就萌生了利用他们将来的平台来做些事情，替代脚本反复这样搞来搞去。
和数据组的同学聊过之后，我发现其实我们的Producer需求在他们那边可以很简单的实现，而且只需要学习一下简单的Spark Python，就可以自主开发部署运行，qps并发量／CPU核／启停等这些平台化操作，快速上手简单运维。
规划好Producer之后，核心系统这块准备计划将PHP架构迁移到Go，提高程序本身的并发能力；同时重构的时候，在将代码中非必要的复杂功能尽量砍掉，用其他的方案替代。
由于我们是做数据迁移系统，所以进度监控是必不可少的，而平时工作中了解到QA团队经常会有一些日志统计和数据安全校验任务，他们也许做过相关研究。抱着试试看的心态我去找了他们QA的技术负责人聊了聊，没想到一拍即合，他们今年正有规划要过类似这样的平台，就这样我写了一个需求方案提给了他们，希望和他们合作完成一套相对通用的监控平台，造福整个云团队。
终于走到最后一块了，其实在想好前面的1/2/3之后，结果校验其实就很好做了，不用脚本去一次次请求校验了，直接将搬迁前后，我们数据库中的数据导出来做join，一对比之后就知道哪些成功哪些失败了，而join工作就可以交由强大的Spark计算完成，这也是Spark最擅长的技能了。
天时地利人和
其实一个系统顶层设计往往花费的精力最大，但是这一步至关重要，成也它败也它！所以在把各个环节想好之后，我拿出一张白纸，将一份最原子的数据文件流动过程画一遍，验证上面4个模块是否能够上下联动齐心合力完成任务，并且简单可依赖！
在得出的结果是 ** Yes **之后，我便将每个子系统的milestone详细列出来，并周期性地和各负责人沟通&&听取他们的反馈，一点一点像推并排的箱子一样跟进，Push着整个项目往前行走。
随着时间进度条的移动，Q2结束的时候，Spark集成平台Horus终于问世了，作为第一个吃瓜的小白，在向技术负责人取经后，便将我们的测试任务部署在Horus平台上了。在联调的过程中，根据我们的场景需求Horus开发了一些通用及人性化的功能，而Flow也在不断的打磨。差不多两周过后，基本达到了当初的设想。
PS: Horus问世后，我在上面花了几周的时间熟悉玩转，发现真是一大利器啊，特别适合我们这种需要大规模计算的场景。所以，我便在不同的场合和聊谈中，向兄弟团队们大力推荐，并邀请了Horus的负责同学做了一场公开分享，好技术好平台，大家用起来说好才是真的好哇！
Horus能用了，Flow ready蓄势待发，Sinan也传来了好消息，16年的 Q1+Q2 是POMS Flow从 ** 设想 -> 推敲 -> 实现 -> 问世 ** 的元年，而这中间真的是天时地利人和的结果，缺一不可，真的很幸运，我见证了你的诞生。
后记
Flow上线正式运行之后，偶尔下午茶的时候，看着各平台上运行的任务，脑海中不自觉的就浮现出我们的数据在全国各地到处穿梭旅行的画面，从北到南，天际遨游！
有时也会去找之前合作的各模块负责人小聊一下当下运行的状况，以及他们各自平台之后的规划和想法，话语之间还能想起那段合作Flow的时光。
我又不自觉的想感谢一些同学了，哈哈哈～！
Horus之父的彬彬同学，是你让Horus“输出能力，不输出人力”，为我们打造了一款即使是Spark小白也能够轻而易举得使用其强大的计算和统计技能。
Sinan的梦想家，熙熙和娅静同学，为我们庞大的数据系统团队，带来了一盏指明方向的灯塔，照亮航行的路线。
当然还有我们可爱的POMS兄弟们，为你们点赞！没有你们，就不可能有Flow。
资源管理 – Capricus
其实做云方面的开发很有意思，就是它的数据量会很大并且在不断增长，我们都知道量变会引起质变，所以我们的系统需要不断应对庞大数据量带来的各种挑战！
当我们的POMS能够独当一面的时候，其实还是面对一些Challenge：
- 资源需求差异化大：在线／离线／单次／批量；
- 资源多样化：底层文件存储资源／DB资源／计算资源／网络资源／Cache资源；
- 资源审计难：对资源的使用情况缺失审计环节；
- 资源分配合理性差：业务无优先级概念，当资源不足时，无法保证高优先级业务的资源需求；未区分低峰高峰时段，低峰时段资源利用率低；
- 系统稳定性风险高：各业务各自为战，不顾及大局，单业务耗光某个底层资源时，拖垮整个系统。
还有一种说法，做云系统 “运维”是关键，当然这里的运维不是单纯的机器运维，还包括资源的整体调度和协调，各方各面都要相互配合，在一个大池子下完成更多事情。
我们的愿景
- 各层次资源全局统一调度：审计、分配、使用、回收；
- 各业务逻辑划分优先级，资源分配的时候考虑优先级因素；
- 各层资源利用率最大化。
POMS的未来在无限的远方，Resourcer的征途是星途大海。
名字的由来
做系统的同学都有一个共同的感受，就是每当遇到给新系统取名字的时候，就比较犯愁了。因为名字一方面要好记，另一方面也要跟系统的功能和定位有关，所以每每起名字都是一件技术活啊。。
为了解决这一困扰了我们很久的难题，无意一次我在维基百科中看到了宇宙中关于星座的划分，就这样我们可以根据各自系统的角色，在茫茫天际中找寻与之匹配的那一颗星座了。
最终给我们的资源管理系统敲定了Caprinus，来源于Capricornus一词：
Capricornus: 摩羯座亮星组成一个倒三角形结构，古人将其称为“神仙之门”，认为从地上各种名利是非解脱出来的人，其灵魂就可以通过此门登上天国。用此星座代表着二级组件通天入地的连接一级组件和POMS各个模块，守护着我们的底层各类资源。
TODO
目前系统还处在开发阶段，后续上线之后，再来聊一聊开发过程中遇到的那些事，尽情期待…