Upyun运维大会之分享

上个月参加了upyun运维与架构交流大会,自己在做运维之前不曾参加过这样的会议,参加之后发现意义不仅仅在于拓展知识,更多在于扩大自己的触摸空间。

分以下几个部分来分享

自动化运维的发展

这一块的内容主要来自于upyun运维总监的分享,他的讲义中讲到了他做运维的那些年踩过的坑,以及高可用的自动化运维架构。要做到部署和监控都抓好才能有更精益的性能。

精华是这张图:

可用,用好以及好用

我们目前应用层级只能做到可用和一点点用好,应用方面可以做到定时定人,但是没把自动化的运维工具用起来。监控方面zabbix目前够用,又拍运维总监讲解的时候说到zabbix到后期机器特别多的时候对服务器的内存占用较高。所以他们选择了使用ELK套件搭建监控平台,后来我网搜了一下,评价挺好的,还能够搭建日志分析平台。接下来要好好研究一下「使用ELK套件搭建日志分析平台」

项目经典架构

接下来在听唯品会架构师赵先生讲以cloud native打造大型电商系统的议题时,讲到电商系统的架构。如下图,从架构上来看,主要有四层:LB层,APP服务层(微服务),缓存层,DB层,存在
三种典型模式:
– 主从模式
– 集群模式
– 分布式模式

Paste_Image.png

这里跟我们现在的架构也是类似的,使用了lvs分流到不同的后端服务器,使用了缓存服务和mysql。这是一个项目的经典架构也是最基础的架构,以下是一个电商系统的基础结构。

随着用户量的增长,如何能做到整个架构的稳定,赵先生这里重点讲到的就是对服务进行拆分,对DB的拆分,项目服务的拆分等等。

架构的三维图形

我们可以从X轴,Y轴,Z轴。进一步拆分。

业务的拆分

以业务为单位进行功能拆分,比如电商系统可以拆分为订单服务、用户服务、库存服务等。每个服务可以根据需要在进一步拆分为更细力度的服务。一般的大型网站可以拆分出几千个这样的服务。

DB的拆分

以mysql为例,随着访问量的上升,几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题,web程序不再仅仅专注在功能上,同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力,优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力,但是当访问量继续增大的时候,多台web机器通过文件缓存不能共享,大量的小文件缓存也带了了比较高的IO压力。在这个时候,Memcached/Redis就自然的成为一个非常时尚的技术产品。

主从读写分离

由于数据库的写入压力增加,缓存只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负,大部分网站开始使用主从复制技术来达到读写分离,以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。

分表分库

随着web2.0的继续高速发展,在Memcached的高速缓存,MySQL的主从复制,读写分离的基础之上,这时MySQL主库的写压力开始出现瓶颈,而数据量的持续猛增,由于MyISAM使用表锁,在高并发下会出现严重的锁问题,大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。同时,开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候,分表分库成了一个热门技术,是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候,MySQL推出了还不太稳定的表分区,这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群,但是由于在互联网几乎没有成功案例,性能也不能满足互联网的要求,只是在高可靠性上提供了非常大的保证。

这里又涉及到荔枝架构师讲到的,Mysql Cluster集群的CA模式:

ca模式

CAP理论

  • ⼀致性(Consistency) 所有节点都能访问同⼀份最新的数据副本
  • 可⽤性(Availability) 每个请求都能接收到⼀个响应,⽆论响应成功或失败,⽽不应该
    是⺴络超时、连接断开等⾮服务程序答复。
  • 分区容忍性(Partition tolerance) 除了整个⺴络的故障外,其他的故障(集)都不能导致整个系统
    ⽆法正确响应。

这三个要素最多只能同时实现两点,不可能三者兼顾。

易扩展高性能且灵活的数据库

NoSQL数据库种类繁多,但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系,这样就非常容易扩展。也无形之间,在架构的层面上带来了可扩展的能力。NoSQL数据库都具有非常高的读写性能,尤其在大数据量下,同样表现优秀。这得益于它的无关系性,数据库的结构简单。一般MySQL使用Query Cache,每次表的更新Cache就失效,是一种大粒度的Cache,总体来说性能要高。

NoSQL无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式。而在关系数据库里,增删字段是一件非常麻烦的事情。如果是非常大数据量的表,增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。NoSQL在不太影响性能的情况,就可以方便的实现高可用的架构。

MySQL和NoSQL都有各自的特点和使用的应用场景,两者的紧密结合将会给web2.0的数据库发展带来新的思路。让关系数据库关注在关系上,NoSQL关注在存储上。

分享大会中所有讲义的pdf
「云运维的启示与架构设计」
「酷狗大数据平台架构重构」
「以 Cloud Native 打造大型电商系统」
「腾讯分布式NoSQL集群运营实践」
「异地多活IDC机房架构」
「高速发展下的电商运维环境建设之路」

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,456评论 5 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,370评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,337评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,583评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,596评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,572评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,936评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,595评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,850评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,601评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,685评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,371评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,951评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,934评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,167评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,636评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,411评论 2 342

推荐阅读更多精彩内容