如何使用SS代理软件流量(macOS)

通过SS可以实现http(s)的协议转换,但是对软件无能为力,如果是手机,ss会模拟一个VPN出来,但是在电脑上并不能实现,针对win系统,方案我之前已经写过一个了,针对macOS可以使用这个方案:

使用Proxifier软件即可实现,相对比较简单,唯一麻烦的是,这个软件需要付费,但是可以试用30天。

如何使用SS代理软件流量

最近有个需求,在不使用VPN的情况下,通过SS代理的方式来访问特定的内网机器,做了诸多尝试,差一点以为SS搞不定4层的网络代理,最后在傅主任的帮助下通过变通方法解决了。

首先,需要一个SS服务器+客户端,然后需要安装一个工具“SocksCap”,通过这个工具来运行RDP,然后实现转换。具体的路径如下:

RDP Client(With SocksCap) – > S client->S server-> Target.

最后实现了内网穿透的效果,相比于VPN的方式,会麻烦一些,但是整体逻辑搞明白其实并不复杂。

容器化Redis开启Auth功能

在Docker里部署Redis的过程中发现一个问题,所有部署的Redis都不含Auth功能,也就是不支持带密码的连接方式,这样导致了很多功能不能正常使用,比如不能用消息队列。

操作以镜像redis:3.2.6为例,只需要在启动时加命令即可,命令如下:

–requirepass 你的密码xxx

(开头为两个半角中短杠,字体原因可能显示为1个短杠)

启动时附加如上命令就可以让Redis开启鉴权模式,也可以通过Dockerfile打包一个新的包,把这个命令含在启动命令里,这样在启动时就可以不附加额外命令了,但是弊端是密码变成固定的了。

“多云”真的有必要吗?

最近总是在各种渠道看到关于“多云”架构的一些思考,正好周末无事,整理整理自己对这件事情的看法。

一、是什么在驱动企业“多云化”?

目前市面上多云架构主要是分为两大类:

第一种是因为各种原因诞生的混合云需要进行多云管理,比如本地私有云(或专有云)与1个或N个公有云打通并混用。

第二种是单纯的公有云之间进行混用,由2个或以上的公有云来共同负担业务的云资源开销。

无论是什么方式的多云,大致是以下的几种原因在进行驱动:

1.数据归属的问题,因为数据不能离开特定数据中心,同时又因为部分业务在公有云上,所以需要通过多云的方式来进行混合管理,将数据放在私有云,而将部分非敏感业务放到公有云,从而实现业务云化。

2.云产品质量导致的差异化部署,比如A云厂商的数据库更优秀,而B云厂商的存储服务或大数据服务更优秀,则企业可能通过多云的方式去部署产品,从而实现“博百家之长”的效果。

3.同样的产品质量、同样的服务质量,但是因为某些云厂商的产品价格更优惠,则成本敏感型的企业同样可能选择多云方式部署产品。

4.最后一部分企业,从可靠性角度出发,业务部署在多个云平台上,从而实现冷热备、异地多活等高可靠架构。

二、多云带来的复杂问题有哪些?

1.运维难度直线上升

每个云平台的产品操作、运维API、运维产品、底层差异都会让运维人员在进行运维时受到更多挑战。

为了提高运维效率,一般会使用一些“多云管理平台”来进行集中维护,但是其只能实现资源级的互通,而且“多云管理平台”也需要部署,增加了单点故障风险,一旦“多云管理平台”出现故障,则很可能出现所有云产品无法正常运维的情况,所以这是典型的为了解决问题而制造了另一个新的问题。

2.产品研发过程中需要额外考虑网络因素导致的业务抖动。

在原本的的单云模式下,业务部署在A云上,只需要考虑几种有限的网络情况就可以了,主要是以下的2种情况:
在A云部署的应用/服务的内部互通链路。
在A云部署的应用至用户的互通链路。

如果业务分布在A云及B云上,情况会变得大为复杂,变成了5种情况:
在A云部署的应用/服务的内部互通链路。
在A云部署的应用至用户的互通链路。
在B云部署的应用/服务的内部互通链路。
在B云部署的应用至用户的互通链路。
在A云部署的应用/服务与B云部署的应用/服务内部互通链路。

一旦参与的云越多,则业务的网络架构会变的更加的复杂,一个业务如果网络架构越来越复杂,则出现故障的风险将会大幅度放大。

最后,即便你解决了网络差异导致的互通链路可靠问题,你还需要解决多云差异带来的网络延迟问题,这同样是一个让人很挠头的问题。

3.多云带来的安全性问题。

由于网络差异及各个云平台层次不齐的安全水平会导致新的安全问题,一方面因为网络环境的差异,多云数据一旦需要交互,则必然带来安全问题的考量,目前主流的方式更多是通过以下几个角度来解决:

1.通过拉专线去互通多个云,好处是相对可靠和安全,延迟也低,但是带宽会非常的贵。

2.通过软交换的方式去互通,比如通过VPN、高速隧道这些方式去互通两个云,好处是相对便宜且业界方案较多,缺点是数据毕竟要从公网走,一方面延迟较高,同时即便是加密了数据也不能保证过程中不会被篡改、窃取、污染。

三、多云是否有必要?

我个人的感受是,混合云多云有其存在的必要性,但是公有云的多云架构其实是伪命题,因为想要真正的玩好公有云多云架构,付出的精力和成本可能远远高于其带来的片面好处。

即便你是想做灾备,我也更倾向于灾备的问题应该由云厂商作为底层基建去实现,而不是我们笨拙的通过多云去构建一个虚假的高可靠。当下的这种多云灾备模式更像是一种妥协,在云厂商大战还未收官之前,对所有云厂商都不信任,从而衍生出来的一种过渡方案。

如果是因为产品差异、价格差异去使用多云,那我觉得这也是阶段性的痛点,因为云厂商总会成长到满足你需求的时候,并且随着云计算产业和5G产业的壮大,云产品价格也会越来越低,这些差异总会被时间抹平的。

所以我认为公有云多云架构这件事是为了解决一个问题而创造了一堆新问题,是时代的过程,而不是结果。

本文仅代表个人对行业的思考,没有商业目的,请勿转载,谢谢!

CentOS7安装SS

1.先安装软件

wget --no-check-certificate -O shadowsocks-all.sh https://raw.githubusercontent.com/teddysun/shadowsocks_install/master/shadowsocks-all.sh
chmod +x shadowsocks-all.sh
./shadowsocks-all.sh 2>&1 | tee shadowsocks-all.log

2.查看或修改配置

vim /etc/shadowsocks.json

3.配置服务器

如果是多用户,需要修改配置为如下:

{
"server":"my-ssserver", "local_address":"127.0.0.1",
"local_port":8888,
"port_password":{
"9999":"password0",
"9001":"password1",
"9002":"password2",
"9003":"password3",
"9004":"password4"
},
"timeout":600,
"method":"aes-256-cfb",
"fast_open": false
}

4.相关命令

#停止
/etc/init.d/shadowsocks stop

#重启
/etc/init.d/shadowsocks restart

#状态
/etc/init.d/shadowsocks status

#清空防火墙策略要求
iptables -F

#关闭selinux防火墙
setenforce 0

#关闭firewall:
systemctl stop firewalld.service #停止firewall
systemctl disable firewalld.service #禁止firewall开机启动
firewall-cmd --state #查看默认防火墙状态(关闭后显示notrunning,开启后显示running)

5.安装客户端

https://github.com/shadowsocks

一个媒体行业Coder的10周年回顾

不知不觉从业小10年了,想想上学那会,刚接触互联网的时候,玩的都是域名、虚拟主机、CMS、肉鸡这些,现在的大学生玩的都是大数据、机器学习这些了,真的有种旧貌换新颜的感觉。

10年前,一边学着编程,一边尝试自己做点东西放网上,那时候主要是接触到都是些很廉价的虚拟主机,而且针对学生也没啥优惠,再便宜一年也要小300块,所以服务器资源都是从饭钱里省出来的,现在学生9.9就能买服务器了,条件比我们那时候优渥很多了,社会在进步~

我毕业后,脑子一热,一脚跨进了媒体行业做研发,10年风雨,一路走来,无论是研发还是企业管理都感触颇多,感触最深的是开源、云化对行业的影响是最深的。

因为我们本身是做媒体行业软件的企业,10年,我们的客户需要花费好几十万去采购一套软件,然后再买上3-5台服务器去部署到本地,之后每次升级再花几万块请技术人员来上门服务。

彼时,传统媒体大兴,没有人觉得这中付费模式和交付方式是一个问题,因为当时的传媒集团都很有钱,然而随着互联网的发达、新媒体的崛起,传统媒体的日子越来越不好过,“一次性付费+本地部署”这种模式就变成了它们的负担,而且新媒体的崛起倒逼着传统媒体要“快一点”、“再快一点”,整个行业的系统服务、软件服务都到了迫切改革的时候,此时我们推出了基于云环境的SaaS化服务,在行业内获得了较好的口碑。这一切的背后既是时代的变迁,也是科技的进步,才让我们以传统厂商10%的成本去运营,1%的周期去交付我们的产品。也正是借着这个机会,我们彻底的拥抱了云生态。

那时候,我们的技术栈主要是SVN+PHP+MYSQL,因为创业初期我们需要更好的迭代效率和更低的招聘成本。

运作一年后,产品也卖的不错,口碑也不错,但是我们收到的运营故障直线上升,处理BUG的效率也大不如前,我们开始反思,是不是我们的技术栈出了问题?是不是我们的运维技术不到家?

后来经过一系列的调整,我们调整了我们的技术栈。

所有基于HTTP的服务,使用Git+PHP+MongoDB进行处理,大数据集的检索使用阿里云的OpenSearch进行管理和供能,日志全量打入SLS中。

所有持久化的服务,使用Git+JAVA+MongoDB进行处理,统一通过阿里云的MNS队列进行调度管理,日志同样打入到SLS中。

所有打入SLS的数据,最终可以通过ODPS(MaxCompute)进行离线计算并输出,为企业提供了一整套的大数据处理方案。

就这样运作了一段时间后,产品的运营、研发没问题了,但是迭代交付和运维开始出现问题,我们做了一个大胆的决定,很激进的把架构层进行了重构,全量依托Docker进行产品的交付、运行,也因此我们成了阿里云容器服务的第一个商业客户。

再后来,我们内部提效升级,把研发工作流改为了阿里云的“云效”产品,彼时它还叫“RDC”,还没有这么洋气的名字。

我们从2010年开始拥抱阿里云,虽然踩过很多坑,走过很多弯路,但是给我印象最深的是阿里云同学的坚韧光芒。

你凌晨3点业务出问题了,阿里云的同学会在5分钟内钉钉或者电话给你处理,问题比较大的情况下可能整个产品部门的同学都会参与,往往是凌晨3点出问题,拉了个钉钉群,处理到天亮发现群里有20个阿里的同学了。

阿里云的产品永远在走向完美的路上,但是这一路上少不了同学们的添砖加瓦、架桥铺路!

因为之前的经历,认识了上百位阿里云的工程师,也为很多产品提出了建议,所以有幸在2017年受邀成为“阿里云MVP”的一员。

加入MVP组织后,觉得最大的感觉是,压力变大了,因为大家的水平都很高,倒逼着你去学习,去成长,去做更优秀的人。

所以我在18年的深圳云栖大会上做分享的时候最后以一句“我见青山多妩媚,料青山见我应如是”收尾,也是希望在我眼中的优秀的MVP们,看我时也觉得我很优秀,算是一种鞭策激励吧~

加入MVP组织后,隐形福利挺多,首先你出的产品出问题后,响应时间更快了。而且提产品建议响应的更好、更被重视。再加上和各种行业大牛的交流机会,更是难得。

最让我高兴的是,可以提前体验各种阿里云的内测新产品,比如我最近就领了一套阿里云的物联网开发套件进行体验,虽然我不是IoT方向的开发人员,但是玩玩树莓派还是很有乐趣的。

10年来,作为一个技术人,云计算一定是对我影响最大的事件,阿里云作为中国云计算领域的佼佼者在我的技术生涯中是举足轻重的。

阿里把一整套阿里的能力对外输出,把曾经阿里踩过的坑和得到的经验都毫无保留的告诉了全世界,给了我们技术人员一盏指路明灯。

这种思想上的传递,是我觉得阿里云如此重要的原因!也正是因为众多的技术人、公司吸收了这些思维火花,才创造了如此多的奇迹。

玄奘之旅——道路在脚下,修行在心中

从敦煌回来已经有一周了,总的来说,这次戈壁行收获满满!

回想刚开始阿里的同学邀请我作为MVP代表参与本次戈壁行的时候,我还有点犹豫。有点担心100多公里,3天半我能不能走下来?后来想了想,走路我也没怕过谁,毕竟也是靠运动减了50斤肉的男人,就这样毅然决然的踏上了前往敦煌的路。

南京直飞敦煌,大约5小时,在快到敦煌的时候透过窗户看地面,大地只有一个颜色——土黄,作为一个从小生长在江南的人感觉很惊奇,也很感慨造物神奇。images出了机场坐车90分钟后到了据说是榆林县最豪华的酒店——榆林宾馆,办好手续入住。

这天晚上,阿里的HR同学和玄奘之旅线路的栋哥给我们做了动员,也和我们讲述了 “沙克尔顿”的故事,其内涵就是:作为一个团队,一个都不能少!

作为6队的一员,我们一起制作队旗,构思口号,这一刻我们的凝聚力开始酝酿!(PS:队长金童,灵魂画手)

从这个故事开始,戈壁之行就蒙上了一层非凡的色彩,让我从心里明白,前方的路不好走,这不是一次旅游、散心!这是一次大自然对你的考验,也是一场走进心灵的修行。

那一晚,我睡的不太沉,也不知道是对新环境的不适应,还是对第二天的憧憬……

到达敦煌的第二天,也是戈壁行的第一天。

早上起来后,用早饭。大家各自背包,在背包里装上3公斤的水,带上一袋干粮,领上GPS、对讲机之后就准备出发了。出发前我是这样的造型:

images

其实不论男女,每个人的包至少都有5公斤的份量,我看着本次活动仅有的几个女同学,真有点替她们担心,心里还想着是不是在她们不行的时候帮衬一把,展示一下我的绅士风度。

大巴90分钟,到达了戈壁行的起点,感觉良好,微风拂过还蛮舒服,太阳也不是很大,一切都预示着这是一个良好的开端。大家把装备穿戴整齐,在起点合影后就出发了。

我不仅和6队的同学拍了合影,还和其他几位阿里云MVP合影留念了,毕竟这也是MVP团体第一次深度参与到阿里云的团建活动中,意义非凡。

images

一路走走停停,聊聊天,靠着郊游心态,不知不觉的我们队就排在了最后,反正风和日丽,体感舒适,谁在乎快慢呢?还看到了当地的野生滋补品——锁阳。

images

但是,意外很快就出现了,走了快2小时的时候开始起风了,并且越来越大。这时戈壁上尘土飞扬,路开始有点难走了。

勉强走了30分钟后,我们遭遇了本次戈壁行最艰辛的8公里,整整逆风顶着沙尘暴走了3个小时。用一句阿里云风格的话概括就是:“6队全体成员全量承接了本次沙尘暴的所有流量”。其他队因为走得比我们快,只被沙尘暴蹭了一下,倒没什么大碍。

这就是戈壁给我的第一课,也许前一刻看上去风平浪静,但是下一秒就是黄沙漫天。想到自己刚跨到了金融行业,又何尝不是如此,市场瞬息万变,没有永远的晴天。

放张图,给大家感受一下沙尘暴:

images

走完了沙尘暴,我们还经历了下雨,虽然雨不大,但是小概率事件全让我们遇上了也是奇葩。就这样,磕磕碰碰,我花了10个小时,赶在晚上6点前到达了营地。看到营地的那一刹有种热泪盈眶的感觉。在夕阳下,搭好了自己的帐篷,大家做做活动,拉伸拉伸。

images

images

拉伸完,大家开开心心吃了顿晚饭,伙食不错,羊肉不限量供应,烧的又好吃。酒足饭饱之后,回到帐篷里,就休息了。

这里晚上9点钟,太阳还在头顶,而早上6点天就亮了,所以白天时间很长,夜晚很短,稍微有些不适应,加上大家的帐篷太密集,半夜呼声震天,在戈壁的第一晚,睡得并不是很好。

戈壁第二天,6点就吹集结号喊起床了,大家的状态都不如第一天好了,加上第二天的公里数最长,有将近33公里,所以大家脸上的笑容也逐渐消失。

惯例每人三公斤水,一包干粮就上路了。

当天要走33公里,我以为已经很糟糕了。

更糟糕的是,太阳很大,温度极高。

最糟糕的是,早上我忘记带干粮了!

所以,走到16公里休息站的时候,我靠着大伙和工作人员的施舍勉强填饱了肚子。很感动!

感动不是他们给了你一个苹果、几块个牛肉干、半个饼。感动的是他们也是负重前行,带着食物走出十几公里,却毫不犹豫的分享给了你。

最后4公里,是沙漠。回来的同学都说,这是整个行程里,最不好走的路。地面很烫,脚会陷进去,尘土大,没有遮阴休息的地方,沙丘林立看不见导向旗,体力消耗大。

images

我却觉得,整个行程最有意思的就是这4公里。

你,孤身上路。

你,弹尽粮绝。

你,只能行走,不知终点何处。

这一刻我感觉,人生种种,不过如此,整个人突然之间很豁达。

以前遇到事情的时候,总是困在心里走不出去,这一刻我抬头看万里晴空,低头看茫茫沙漠,淡然一笑,原来,也不过如此。

我找到了,戈壁给我的第二课,就是我一直欠缺的心境,一种乘风破浪,直面苍穹的勇气。

images

最终花了12个小时整,到达营地。到了营地之后,我还在想,起初还想着路上有条件照顾一下几个女同学,没想到我走了2天从头到尾连她们影子都没看见。她们连续3天都进前三甲,普遍在前十名,啪啪打脸。

这是戈壁给我的第三课,不要小瞧任何人,越是不可能,越是创造不可能。

晚上,还有一个插曲,因为当天没有手机信号,只有在一个小山的山顶上才有微弱的信号可以打电话。有位同学,走了一天回到营地不仅没休息,又爬上了这座山,到达山顶后,不是为了看山下的风景,而是为了有手机信号开一个电话会议。

这一刻,我看到了阿里人身上的光芒!

戈壁第三天,穿过一片绿洲,感觉还是很神奇的,茫茫戈壁,土黄土黄的山脉中居然藏了一片净土,真的是造物神奇,钟林神秀。

戈壁第四天,也就是最后一天,早上4点30就起床了,因为今天是个人赛,会分别给男女前三甲发放奖牌,所以很多人提前一晚就开始摩拳擦掌了。

因为我这几天状态都不错,完全没感觉到特别累,脚也好好的,没起泡没受伤,出发前有一刹那我甚至在想,要不今天拼一把夺个名次?直到我看到哨声一响,有几个人和兔子一样快跑前进时,我就放弃了这个不切实际的想法。

我们6队有一位队员,第一天就伤了膝盖,每天都是以大毅力走回营地,坚决不上车。虽然每天名次不高,但是能这样坚持下来,我们都觉得非常不容易,所以我们全队决定个人赛放弃名次,我们要发扬“沙克尔顿”精神,一个都不能少!我们要全队到达终点!

所以我们沿途都是这样走的:

images

对受伤走不动的队员,我们就用登山杖拉,用手推着爬坡,用肩膀托着下坡,就这样我们不仅把本队的伤员带回了终点,甚至还把5队的伤员也一起带回来了。

能和6队的兄弟分在一组,我倍感荣幸。特别是在行程结束后,这种感觉更强烈了。

也许,我们6队在这次戈壁行中成绩不是最出彩的,但是我们一定是最团结,最富有“沙克尔顿”精神的团队!

很感谢阿里巴巴提供了这样的一个机会!最后献上我们6队的一张合影,和我在沙漠中的囧照!

images

从戈壁回来后1个礼拜,我时常在想,当年玄奘法师的成就究竟是得自佛国经文,还是源自西行之旅的一路修行。所以,也就有了这篇名为《玄奘之旅——道路在脚下,修行在心中》的游记,至终将西行的你。

巧用RDS全家桶搭建亿级新闻源仓库

我们的业务,有一个实时新闻源库,初始大概有3000万数据,现在大概有上亿条数据了,我们在起初的处理方式比较简单粗暴,直接购买了3台8核16G的SSD版本的ECS,组成了一主双从的机组,从库只读。

业务是单库,但是具体的内容是分表的,比如:

article_content_01一直到article_content_200或更多,业务系统会在满足要求后实时创建新的表,每张表的数据量大概在100万左右。

我们在2013/2014年开始遇到各种各样的问题,也算是一些经验教训吧:

1.使用ECS组建的数据库集群,可用性不是特别特别的高,主要受限于IO、网络同步速率。甚至遇到过从库意外关机,然后影响业务了。

2.我们把所有的读取SQL放到了从库进行,但是问题来了,我们的开发语言是php,所以它没有办法像JAVA那样做一个连接池来处理请求,一开始我们使用一个随机算法来分配每次读请求所使用的从库,导致当我们的并发很大的时候,从库的连接分配策略会出现不平均的问题,从而导致某个从库满载。虽然最后通Haproxy完成了从库的负载均衡,但是也带来了额外的运维负担。这个谈不上是坑,算是一个经验教训,想当然的以为随机算法可以替代负载均衡了。

3.风控的问题 ,有的时候一些不应该发生的低级错误就是这么堂而皇之的出现了,比如,测试库只有3000万数据,而正式库有3亿数据,有些逻辑代码在测试库的响应正常并不代表在正式库也是正常的。如果你不能敏感并及时的去处理慢查询,那业务基本也就凉了。

4.监控的问题不提了,直到最后都没找到一个称心如意的MYSQL监控解决方案。

5.审计的问题,我们永远处于有日志,而没办法审计的状态,有事没事假装看看罢了。

6.备份就讨厌了,需要手动这先不说。备份时机、锁表、备份后的归档处理、定时清理老备份、备份文件的校验,这些都是事儿啊,对运维人员来说,都是很低级但是不得不做的工作。

7.有的时候,你的Web服务器抗住了流量,但是不幸的是你的数据库没能坚持下去,这种突发的流量往往没办法预测,或者出现后需要最短时间内修复,我们出现过大概3次,每次大概2小时时间去扩容,会影响一部分我们用户的体验,表现为卡顿、页面报错等。

8.硬成本和运维成本问题,3台高配ECS+1个全职运维人员的成本,一年下来少说也要几十万。

问题应该有很多,但是只能想到这些,先记下来吧。其实有很多问题不是MYSQL的问题,属于架构层面或者开发层面的问题,但是我们谈一个具体技术细节的时候不能只谈它本身,没有场景和实践,那是耍流氓啊。


然后我们从15年开始,实在是不行了,这种方式已经让所有人都接近崩溃,所以我们考虑切换到RDS上去,当时只是先切换了几个不重要的业务库,试试看效果。然后一发不可收拾,总结一句话,这产品除了价格,简直完美。

首先RDS for Mysql解决了我之前提到的几个问题:

1.托管式的服务,动态弹性的升级,不需要关心运维的问题。

2.可以动态的添加只读库,方便。

3.控制台对慢查询很敏感(虽然这个是近2年才有的功能),而且可以做报警。

4.阿里云现在这一版的控制台看监控还算是比较舒服,也能看的全。

5.日志审计这一块,通过最新版本的阿里云DMS已经可以比较简单的完成了,它还有个收费版,没用过,没有发言权,但是现在这个免费的版本也挺不错的。

6.备份不提,阿里云RDS的备份已经做得很好了。

以上的问题,除了突发流量暴库的问题不能通过RDS直接解决,其他都能很好的解决了。而且相对于3个ECS的成本,单独购买RDS的费用也还在可以接受的范围内。

下面说一下,我们如何解决突发流量的问题,阿里云有个比较好的产品叫DRDS,但是这个产品属于好用,但知名度不高的一个状态,可能是小客户用到的概率不高吧。

DRDS扮演了一个类似负载均衡器的角色,当然了,比普通的负载均衡更高级一些。它不仅仅是Haproxy这种基于网络点的负载均衡,还可以针对SQL进行负载均衡,这一点在处理超大表检索的时候特别好用。而且它的后端是一个个的RDS,对于低成本突破连接数限制有非常大的帮助,同时弹性增减扩容,只需要购买按量RDS就可以了。

在高并发的场景下,数据库遇到的问题主要在于连接数限制、IO限制、锁、并发读写等问题,这些问题通过RDS/DRDS几乎都可以很好地去进行处理,有些高级应用需要做一点点开发上的让步。


阿里云的RDS实例其实也经过变迁的,起初是只限制内存和连接数,后来才出现“CPU核数”这个概念,所以也导致了我这种老用户一度很难适应,毕竟老版本2400M内存的RDS就默认8核了,而现在购买一个8核的RDS价格还是比较高的。我有个骨灰级的实例,可以截图给大家看下,现在买不到啦:

有一段时间,时不时也会收到短信提示,RDS发生主备切换云云,起初是比较紧张的,担心阿里云的技术不硬从而影响我的业务,后来切换过多次之后,发现真的没出过问题,从此也就安心了,小顾虑罢了。


最后一部分说一下,我们如何解决全文检索的问题,因为有分表的原因,所以很难通过程序去完成全文检索,而且因为量大Like语句基本不可能使用。在这种情况下,我们开始尝试使用第三方的工具去完成,比如Sphinx 。但是我们很快又遇到了问题:

1.成本问题,因为Sphinx 不写磁盘,一切读取到后都存在内存,所以几亿数据对内存的要求就高了,买ECS的时候就要买高内存的配置。

2.Sphinx一次性读取数据到内存这个过程,可能对业务产生一定性能影响,但是不严重。

3.Sphinx 的运维问题及配置问题。

然后我们偶然的发掘了阿里云的OpenSearch产品,支持RDS一键同步并且可视化的创建表、索引很舒心,还提供了SDK和各种好用的函数。唯一的问题在于,价格感人,特别是数据量大且每天并发检索高的用户来说,这个成本很可观。但是优点也很明显:

1.除了一开始的创建,几乎不需要你运维。

2.所有数据都打平到一层,检索速度极快。

3.支持分表结构,支持多个实体表,支持主外键关联,万物皆可查询。

4.对数据源几乎没有任何影响,即便你源库挂了,检索服务依旧可用。


就先写到这里了,都是些经验教训,谈不上太高深的技巧,主要还是要结合场景去做一个适合自己业务的架构。现在我们关系型数据库用RDS for Mysql,NoSQL数据库使用RDS for MongoDB,一路走来也都挺好的,虽然某个阶段它有这样那样的问题,但是一个持续迭代的产品必然会有更高的生命力和稳定性。

 

K8S部署时镜像相关注意事项

最近部署K8S应用时发现一些小细节,记下来做个备注。

 

1.默认的部署只能pull到公库镜像,如果想要pull到私库镜像,需要进行额外配置,在spec节点下新增 以下内容:

imagePullSecrets:
– name: 私库字典Key

 

2.部署应用时,默认不会每次都拉最新镜像,所以需要在containers节点的resources节点下新增或修改一下内容:

imagePullPolicy: Always

代表每次部署都拉取最新镜像