酥仁 发布的文章

锤子和敏捷

用锤子钉钉子是日常劳动的一种,利用惯性让力量集中爆发,从而让要费很大力气的事情变得轻松。

一枚钉子,立在墙上,如果是强行摁,很少有人有力气能将钉子摁进去。

锤子为什么可以呢?因为使用锤子需要有节奏,首先是准备,积攒,然后挥动,冲刺,最后接触钉子,爆发。

其实我想说的是敏捷。

题目里的敏捷,我指的是敏捷开发。大致意思,是以前开发很久才上线,然后又花很长时间开发 2.0,上线,这样的时代已经过去了,应该更早的上线,接触用户,听取反馈,更快更小的改进。

为什么?我的理解是成本的考虑,节省金钱和时间的成本。世界变得太快,今天炙手可热的东西,明天就是一堆垃圾。软件开发也是一样,没人弄得清自己想要什么,没人接受的了大把时间和金钱的投入,换来自己不想要的软件产品。

做做看吧,做出来我才知道自己想要不想要。为了适应这样不稳定,不确定,不靠谱的需求,就有了敏捷。

敏捷有他的好处,它让需求具象化,可以操作可以把玩的产品,比需要想象而不确定的需求,更生动,更容易判断。

敏捷本身无所谓好坏,只是一种工具,但敏捷这种工具,容易丢失节奏。

传统的软件开发流程,比如瀑布或螺旋,有很明显的阶段,这个明显又死板的阶段,客观上把握了节奏。

到了敏捷开发,因为每次修改更容易,更轻量,代价更小,很容易出现对软件系统随意修改的情况。如果开发人员由于松懈,或出于尽快完成的目的,容易将一些本来需要仔细、系统思考的修改,变为不经意、随意的修改,或者说,用不合适的工具,强行完成了任务,而这些任务,本来是需要站在整个系统层面去思考的。长此以往,系统就会出现漏洞,变得难以维护,生产效率降低。

类比敏捷开发和钉钉子,缺少节奏的敏捷开发,过程就是:前几锤子很轻,很有目的,后面不在准备、冲刺、爆发,而是通过锤子摁钉子,花的力气很大,效果确很差。

设计的意义

开始做一件复杂的事情前,第一个动作往往很重要,撸起袖子开干往往费时费力做不好。有经验的人,往往会仔细想想,想想前因后果,想想手中的资源,想想先做什么后做什么,这个想的过程,便是设计。

激烈的篮球比赛里,就能明显分别出喜欢撸袖子和喜欢思考的人,比如威少,年轻有活力,著名的就是干,对立面是老奸巨猾的马刺,各种偷奸耍滑还得佩服它。当然,很多什么都不懂的人喜欢威少,因为热闹。

一个人的设计,代表了这个人对事物的理解能力,对问题的分析水平。好的设计,不意味着设计者在一开始就想到了所有问题,所有可能的情况,而是,这个设计能够包容足够多的情况,有可能很多情况,设计者完全没想到。

大部分建筑设计都不错。同一种房型,不同的人家,不同的家具,不同的习惯,都能适应的很好。徽派建筑中,天井的设计,既解决了采光,又解决散热和保暖的问题。木匠常做的木榫,不用钉子和胶水,就可以将两块木料,牢牢合在一起。

好的设计,往往只解决少量问题。房屋的设计者从不解决装饰的问题,而只是考虑采光,通风,保暖,管道铺设这些基本问题。

好的设计者,往往是好的工匠,反过来却不成立。因为越是优秀的工匠,越容易陷入到细节中。而好的设计师,不仅要知道如何制作,也要关心使用者的需求和习惯,使用的场景,还要关心材料,成本。好的设计往往是各方面妥协的产物,而好的工匠,更容易做出炫技有余,实用不足的物件。

再好的设计,也有局限性。有使用场景的局限,比如南北建筑的设计,在采光、通风、排水方面的考量,有很大的差异。还有材料的局限,比如木榫这样的设计,只能在木头上使用,钢筋塑料很难派上用场。另外也有时间的限制,氏族制度的原始社会,放到发达的今天,一定会成为旅游景点。

设计失效时,一种解决办法,是打补丁,好处是快、成本低,坏处是容易顾此失彼,补丁越来越多时,加了补丁的设计就会成为灾难。另一种是推倒重来,重新思考问题,重新组织资源,当然会有阵痛,但每一次技术飞跃,思想革命,最后胜利的,往往都是重新设计。

《五月花号》读后感

这本书从英国人的角度,叙述五月花号乘客,为什么前往美洲大陆,如何定居,如何与印第安人打交道,如何一步步侵占印第安人的土地直至从北美大陆上赶走印第安人。从英国人的角度,阐述美国的来源,以及美国精神的来源。

书的内容,大致如上。不过我看到的,则基本是高等级文明如何蚕食消灭低等级文明的过程。美洲大陆印第安人的命运,从被哥伦布发现美洲大陆后,就决定了。

五月花号的乘客,不是哥伦布以后,第一批与美洲土著打交道的欧洲人。书中没有详细说,五月花号之前,欧洲大陆已经有船只不定期与美洲大陆开展贸易,或者殖民。五月花号上的清教徒们,由于不堪忍受英国国内的宗教压力,想办法到美洲大陆定居。

印第安土著,对欧洲大陆的文明成果,有着深深的崇拜与渴望,比如工业品和火枪。这些产品,不仅直接提高他们的生活质量,也提高了生产和战争的效率。而他们能拿出来交换的,只有珍贵的动物皮毛和廉价的原材料,这些资源注定会由于获取效率的提升,以及需求的扩大,而慢慢枯竭,于是土地就成了最后的资本。当土地卖尽,印第安人失去了最后的生存机会,战争的爆发,就变得不可避免。

不能责怪高等级文明的欺骗,也不能责怪低等级文明中出现叛徒或带路人。这是文明的战争,人做不了什么,只能站队或怨恨自己站错队。

和文明的战争无关,最后摘录一段书中的文字:对敌人不是深恶痛绝,而是试图尽可能地向他学习;不是杀死敌人,而是要尽力使他按照你的思维方式行事。

Mongo Ops Manager 部署

Mongo 作为 Nosql 的代表,对开发来说,提供了很大的自由度,但对于运维来说,就非常难受。比如没有图形化的监控工具,比如永远他的投票机制和文档上不一样,比如他的备份方案。

当然,他有数据接口,里面有所有和运维相关的数据,也有现成的监控工具,利用这些工具也能还行。但是,但是请和 ES 比一比...

大约 Mongo 自己也意识到了这个问题,在 3.0 发布的同时,也发布了一个管理、监控和备份的服务 MMS。无法理解 MMS 这个服务,难道要把内网的数据库对公网暴露吗?难道 Mongo 希望别人用一个公网的服务做监控,和 管理 以及 备份?这安全性和速度(数据备份和恢复)怎么保证?

还好 Mongo 将 MMS 背后的工具也 免费 发布了,这里,说的就是我部署的过程。

基本概念

Ops Manager 其实就是 MMS,只是可以自己部署,官方文档在这里

MMS 由 3 大块组件构成

  • MMS HTTP Service
    • 用于监控和管理
    • 需要有一个既能访问 MongoDB 服务,又可以访问 MMSS HTTP Service 的代理
    • 自身需要有一个 MongoDB 服务保存信息
  • Backup HTTP Service
    • 用于备份
    • 备份对象不能是 Standalone 的(独立的,没有做 Replica 或 Sharding,因为它通过 oplog 工作)
    • 需要一个和 MMS HTTP Service 类似作用的代理
    • 需要一个和 MMS HTTP Service 类似作用的 MongoDB 服务
    • 需要磁盘空间保存备份对象的快照(Snapshot)
    • 有一个独立的 Backup daemon 进程,用于生成快照。
  • Backup Alert Service
    • 用于通知,没有详细研究

MMS 服务本身需要使用 MongoDB,这个数据库的版本大于等于被宿主数据库的版本即可。但,备份服务需要有一个和宿主数据库相同的 Mongo 程序放在指定位置,后面会提到。

管理/监控和备份服务,各需要一个代理,这 2 个代理会访问宿主数据库,传递数据,对宿主数据库来说,他们相当于不可见的 Secondary。

数据库备份的快照,最快 6 小时生成一次,不能更快,也无法手动生成。

数据库的恢复,详细文档可以看这里,大致过程,是从 MMS 管理网页上,选择快照(Snapshot),下载,按照文档文档提示一步步恢复,期间 不能 相应请求。快照的时间间隔决定最多会有 6 小时的数据丢失,为了解决这个问题,MMS 有一个机制:如果是恢复一天内的,可以指定精确的时间(精确到分钟),但这样 MMS 需要一定的时间生成恢复文件下载链接,而且MMS 服务器需要额外的磁盘空间。

部署

为了方便测试,MMS 提供了测试部署方案,也就是把所有 HTTP 服务,MongoDB 服务,备份 Daemon 服务放在一台服务器上,具体可以看这里

可能是没考虑轻量级用户的需求,Mongo 提供的方案,都是可以容纳几百个 MongoDB 服务(每个服务是一个完整 Sharding 或 Replica)的,要求高可靠性,高性能,因此文档上对机器的要求都比较可怕。对轻量级需求,用一般的服务器就可以了,CPU 内存问题都不需很好,硬盘大一点就可以了(看宿主 Mongo 占用的磁盘大小)。

MMS 强制要求两个数据库都有 Primary Secondary 和 Arbiter 至少一个,否则在启动服务时,会报错。

详细的部署文档在这里。说几个我遇到坑:

  • 如上面所说,至少要一个 Secondary,我没配,MMS 服务没启动起来;
  • 启动 Backup daemon 时,文档写 27017,我觉得文档肯定写错了,将数据库配成了 27018,也就是备份服务用的数据库,启动服务不成功,/opt/mongodb/mms-backup-daemon/logs/daemon.log 里一直有 The application version is unknown. Ensure that the MMS HTTP Service of version XXX was started up before the Backup Daemon. Stopping. 的错误。正确的的配置,应该用 MMS 数据库,也就是 27017,27018 这个数据库,是在 MMS 的网页控制台里配置的。
  • 备份服务需要保存快照,配置文件 rootDirectory 的设置,默认存在这里 /var/lib/mongodb/backup/,但这个地方要有足够的空间
  • 我配置好所有服务和代理后,oplog 传完了半天,都没有开始建 Snapshot,以为要到指定的时间,但是也没有。查了 daemon.log,一直有 Could not find mongod matching major verison 2, minor version 4, and maintenance version >= 9 in /opt/mongodb/mms-backup-daemon/mongodb-releases/这样的提示,按照这里的提示,下载了宿主 Mongo 服务对应版本的程序,放到这里,才开始正常建快照。

搭建好服务后,就可以访问控制台,需要注册账号(竟然还要注册..),按照提示添加代理就可以了,添加代理的过程是最舒服的,完全傻瓜化操作,复制粘贴命令就行,也有验证的按钮可以用。

MMS 是比较新的服务,做的还是不错,问题不多,但有问题时,也很难 Google 出来。

最后,最好不要将这个服务放到公网上,不知道有什么漏洞,一定要放的话,务必限制好端口的访问。