guiyumin 发布的文章

其实在上一篇文章里说的开关,有一个更正式的名字:Orthogonality,翻译为中文是正交

这个的细节以后再补充。

首先,编程本身是工程,不是科学。这就意味着条条大路通罗马,没有一个放之四海而皆准的东西。所以说,其实很多人争论的代码风格,哪个语言最好,哪个框架好,这都其实都是哲学问题,因为没有统一标准答案。

代码风格,纯粹是个人喜好,只要能通过编译,这些所谓的风格在编译后都会丢失。简单来说,编译器不在乎。当然,如果你非要抬杠说某种写法性能更好,那就是针对性能做优化。但如果无所谓性能,但着重考虑可读性和可维护性的时候,又是另一种看法了。

语言和框架更是,都是为了解决某个特定类型的问题而开发出来。你写个小博客,用不着C++,用又笨又重又慢的WordPress就挺好,杀鸡用不着牛刀。

尽管如此,在一般情况下,或者某些特定情况下,还是有最佳实践的。比如说,最近发现一个写代码的思路,就感觉很高明,非常高明,据说微软在用,而且也有v站网友提出来,感觉真的非常高明。

这个思维就是开关

也就是说,你新增任何一个feature,都要同时提供一个switch,就是开关,而且必须做好充分的测试,确保你的软件在这个开关的两个状态下都能工作正常。而切换状态就用配置文档,最后的结果就是一套代码 + N 套配置文件的方式,让不同的人按需获得自己的feature

这个高明的思维,首先是看知乎上有个问题,问的是为什么Office软件体积那么大,有人说Office要有开关的,而且做好了充分的测试,所以软件的体积大。当时我就觉得这个思路很牛逼,但是也仅限于感慨而已,因为这个是Office的开发模式,那我这小菜鸟能比吗?后来看到v站上有一个人提问,给一百多个医院写一套软件,但这么多医院,每个医院用不同的模块,而且对每个模块的具体功能的需求也不完全一样,怎么办?最傻的方式当然是复制N份代码,当然这后果肯定是灾难性的,无论是成本角度还是维护角度。然后就有不止一人提出用代码+配置的方式,也就是说,每个feature都是可关闭的。这样就完美解决这个难题。

其实这个思维方式,也应该用在很多其他软件上,比如有一个按理说应该很好的电商程序fecshop。这个fecshop或许真的很不错,但推广受阻,我自己也是勇敢的尝试了一次就再也没用过了。

不是这个电商程序不好,而且这个程序的定位出了问题。在第一次安装的时候,这个程序要装3个数据库,mysqlredismongodb。可怜我当年还不会用wsl,在Windows系统上装这三个数据库简直是不能更痛苦了。勉强跑起来了之后,感觉太强大了,不敢改代码。当然,也可以用docker来装,但到今天我还不会用docker。

所以问题出在哪里呢?定位。
第一,这是一个开源电商程序,必然会有各个层次的程序员来使用。考虑到95%的程序员都是CRUD Boy(我也是),这个电商程序的学习曲线未免太陡了。
第二, 还是定位。假如我就三个商品,比如Github这么大网站,也才3个商品,因为会员就三种,免费的,个人收费版,企业版。用得着这个吗?大量卖服务的小公司,就是5种以下的。
好,假如你是卖小商品的,比如,卖衣服的,就一个有点个性的小店,可能你的商品数量也就是一两百种,撑死三五百种,这样的一个小店,用得着三个数据库吗?
再次,就算用得着这么复杂的一套数据库,一开始用得着考虑性能问题吗?一开始MySQL一把梭,就可以解决问题,包括队列服务,都可以用MySQL。至于其他高级功能,就慢慢上呗,这个时候真的就需要开关这个思维方式了,每加一个新feature,就新增一个配置即可。如果一开始就是奔着大网站去的,注定是门槛太高,曲高和寡。
最后的最后,如果真的是大网站,为什么不用JavaMySQL够用吗?这些问题的答案是显然的。

好,说完了这个开关的思维,再复习一下UNIX哲学,其中一条是Do one thing and do one thing well。这个思维方式是第一个震撼到我的思维方式。

现在有很多云服务供应商,比如AWS、阿里云,提供消息队列服务。我一直有个困惑,所以就去提问了,有几个回复很不错。

Q:
首先,大家使用消息队列的原因有很多,其中一个常见的原因是稍后处理耗时任务,比如发邮件,短信等。这个是很基本的,就不多说了。
那么,这个处理的核心是,快速把任务加入到队列里, 比如保存在 mysql 或者 redis,缩短用户的响应时间,然后快速把 response返回给用户。
所以,快速,就是关键。毕竟发送邮件需要好几百 ms,写入到 redis 也许 10ms 就够了。但现在很多云服务推出消息队列的功能,我猜测,你要调用 他们的api 的,这个 api 肯定是 http 请求啊,这个请求会很耗时吧。这样使用一个云端消息队列有何意义呢?和在 localhost 或者内网搭建消息队列相比,云服务的消息队列有什么更值得使用的理由?

网友回复摘要:

- 阅读剩余部分 -

好几种方式:

// No. 1
mysql -u username -p < data.sql

//No. 2
mysql> CREATE DATABASE myDB CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;   
mysql> use myDB;                  # 使用已创建的数据库 
mysql> source /path/to/data.sql   # 导入备份数据库

感觉第二种似乎挺不错的

部署好了,有一个专门的数据库,然后用cron来每10分钟执行一次。
crontab是这样写的:
*/10 * * * * /usr/bin/php /path/to/queue/script > /dev/null 2>&1

终于把worker部分写完了,当然了,应该再做一些处理,比如即便有很多人留言,我也可以只请求一次Server酱或者发送一次邮件,毕竟这个小脚本每5分钟运行一次。也要加一个done_at的列,好知道什么时候已经处理过了这个job

好,这里有一个重要话题:耗时。

- 阅读剩余部分 -