聊一聊云端的“备、增、活”架构

又是一年“双11”来了,看到形形色色的应用在这几天蓬勃而出,为了商家和消费者们而忙碌。作为一个架构师、技术管理人员,你是否担心过“双11”用户激战正酣时,你的应用挂掉或系统宕机导致业务中断?这些可不仅仅是担心,而是已经发生的事实。

在全球范围内主流云厂商的故障时有发生。例如亚马逊AWS在2017年2月,就曾因一条错误指令引起宕机,影响了包括Slack、Quora和Trello在内的很多企业平台,停机4小时。去年9月,微软Azure数据中心还意外遭雷劈发生故障。

凡是IT都有故障概率,相对于传统IT单机,云计算已经通过大规模调度降低了故障率,大多数云厂商都声明可用性在99.9%-99.999%之间,且多数在故障后恢复很快。

所以无论你是否基于云构建业务,备份也尽量考虑与云贴合,原因是云厂商拥有更强的基础建设及可靠性服务。云厂商基本已提供完善的容灾架构设计,包括冷备、热备、同城双活、异地多活等策略,可以针对系统可用级别与成本、效率综合考虑。

下面和大家分享一下我对云端备份架构设计上的一些拙见。

一、云端备份(单云与多云)

如果你已经使用了某一家云厂商的服务,或者你的业务存放在某个云上,比如“阿里云”,一般通过以下的方式来完成备份:

1.云产品一般都自带备份功能,比如阿里云的数据库类产品RDS均自带备份及回滚功能,ECS服务器也具备快照及恢复能力。这些产品的备份是比较省心的,也不需要太多额外的成本,一般来说费用都包含在产品的购买费用中了。

2.如果需要备份的数据不是云产品,而是自建的业务系统中的数据,那么一般来说分为两种方式进行备份。

第一种是“非结构化备份”,通过一些同步工具将数据文件(数据库文件、图片、附件等)存储到文件系统中去,比如:ECS自建FTP、OSS、NAS等。

 第二种是“结构化备份”,通过一些同步工具将数据(泛指数据库中的数据)投递到特定的归档平台中去,比如:自建ES、SLS、ODPS等。

多云备份与单云备份的区别是存储的目的地不同,或者使用冗余备份模式,多云同时存储备份副本,以达到最可靠的数据安全性。

二、增量备份

 有时候我们希望备份是“实时”或者“准实时”的,这样一来就要求备份副本从原来的“孤岛式”变成“堆叠式”,孤岛式备份是最容易的,因为只需要手动或定时执行一次备份任务就可以了,但这种模式只能满足比较低级的业务需求,无法满足连续性的业务需求。

比如,我们需要通过备份在5分钟内生成一个立即可用的数据库用来分流线上数据库的压力,此时通过孤岛式备份无法满足业务需求,因为备份数据是不是最新的。

在这样的情景下,我们会考虑通过一些手段去完成实时增量备份,同样分为2种方式。

第一种是“非结构化备份”,增量方式主要通过脚本HOOK文件/目录异动来完成,大部分的同步备份软件都具备了这样的功能,只要网络带宽、磁盘IO满足要求几乎可以实现实时增量备份。

 第二种是“结构化备份”,数据库类的增量备份需要用到一些特殊的脚手架,以Mysql为例,可以通过开启数据库的binlog来完成准备工作,然后可以通过DataX或者阿里云的数据集成产品来完成数据的同步投递,因为是通过binlog完成增量,所以这是实时的。同时,通过binlog投递到ES也可以完成全文搜索功能,提高数据的全文检索能力,也被作为实时分析的一种手段。其他数据库也可以通过类似方式实现,总之一句话,要么花钱买云产品,要么善用开源。

三、业务多活

前面分别介绍了常规备份、增量备份的工作思路,但是它们仅仅是备份而已,永远是最后的手段。无论你是CTO还是运维人员,你一定希望这些备份永远都用不上,这才是最完美的状态。

那么这就要涉及到“多活”的概念了,一般分为“同城多活”和“异地多活”两个主流方式,对应不同的业务场景。因为多活比较复杂,我们仅以“无状态”应用为例,“有状态”的应用可能会更复杂一些,下次再聊。

同城多活,以杭州为例,通常都会在杭州市的两个机房架设一条专线直连,这样即便机房A出现故障,B机房也可以顶上去承接业务。

优点是,同城多机房通过专线直连,延迟非常非常小,切换分流非常简单,运维简单。

弊端是,A机房或者B机房可以有任意一个出现故障,但是整个杭州市的网络及电力不能出现问题。

异地多活,以杭州与上海为例,业务分别完整的部署一套业务在杭州与上海的机房,同时通过一些方式保证上海与杭州的数据是强一致的,或者有第三方的数据中心用来存数据,上海和杭州从数据中心拉取最新数据也可。

异地多活最重要的架构部分其实是“前端承接调度”这个模块,由它来决定每一个业务请求被送往上海还是杭州,常见的方案可以通过Nginx做7层转发、HAProxy做4层转发,在转发时做好心跳识别,一旦转发器发现某个城市失联,则摒弃此节点。理论上来说只需要你部署的城市足够多,业务可用性会更高。

转发也可以通过用户的网络延迟进行择优转发,以便于通过多活地域提供更好的用户体验。

以上是我对业务备份与多活的一些拙见,可能下次会再开一篇把多活展开说一下,或者对比一下各种同步工具的差异。从业界产品来看,阿里云的很多产品还是很好用的,数据同步工具很健全,比如:DataX、Canal、数据集成、混合云数据管理HDM、DBS等都是很好用的工具,虽然这些工具不能让你省略架构工作,但是他们能让你更快速和可靠的搭建自己的备份、多活架构。

祝大家双11愉快~

Ubuntu16.04升级OpenSSH 8.0

最近在做等保,扫描后发现很多的linux服务器有高危漏洞,一看都是OpenSSH版本过低导致的,所以写了个脚本对linux进行批量升级,只针对ubuntu16.04,其他系统类似。

#更新并安装所需要的依赖

apt install -y build-essential libssl-dev zlib1g-dev

#下载openssh8.0

cd /tmp && wget https://citycloud.oss-cn-hangzhou.aliyuncs.com/openssh-8.0p1.tar.gz && tar xfz openssh-8.0p1.tar.gz && cd openssh-8.0p1

#测试及编译

./configure && make

#安装并重启服务

sudo make install && systemctl daemon-reload

MySQL Workbench如何导出特定版本的SQL文件

最近在用MySQL Workbench建模的过程中突然发现导出的SQL建库文件无法运行,报各种错。

仔细看了一下SQL文件中的新建索引部分多了一些关键字“VISIBLE”。

查了一下,这是MySQL8.0的特性,而我的服务器是Mysql5.5很显然是无法支持的,问题是找到了,如何解决呢?

找了一圈,在配置中找到的,具体设置方式如下:

当你指定mysql版本后,导出的建库语句也是兼容指定版本的SQL。

如何使用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 status 改为 /etc/init.d/shadowsocks-go status

#停止
/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年来,作为一个技术人,云计算一定是对我影响最大的事件,阿里云作为中国云计算领域的佼佼者在我的技术生涯中是举足轻重的。

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

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