上一篇文章“一分钟了解负载均衡的一切”引起了不少同学的关注,评论中大家争论的比较多的一个技术点是接入层负载均衡技术,部分同学持这样的观点: 1)nginx前端加入lvs和keepalived可以替代“DNS轮询” 2)F5能搞定接入层高可用.扩展性.负载均衡,可以替代“DNS轮询” “DNS轮询”究竟是不是过时的技术,是不是可以被其他方案替代,接入层架构技术演进,是本文将要细致讨论的内容. 一.问题域 nginx.lvs.keepalived.f5.DNS轮询,每每提到这些技术,往往讨论的是接入…
上一篇文章"一分钟了解负载均衡的一切"引起了不少同学的关注,评论中大家争论的比较多的一个技术点是接入层负载均衡技术,部分同学持这样的观点: 1)nginx前端加入lvs和keepalived可以替代"DNS轮询" 2)F5能搞定接入层高可用.扩展性.负载均衡,可以替代"DNS轮询" "DNS轮询"究竟是不是过时的技术,是不是可以被其他方案替代,接入层架构技术演进,是本文将要细致讨论的内容. 一.问题域 nginx.lvs.ke…
原文地址:http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959595&idx=1&sn=5f0633afd24c547b895f29f6538baa99&scene=1&srcid=0918W9XezgcVJt1eMtQeUE6C#wechat_redirect 016-09-18 58沈剑 架构师之路 上一篇文章“一分钟了解负载均衡的一切”引起了不少同学的关注,评论中大家争论的比较多的一个技术点是…
1)接入层架构要考虑的问题域为:高可用.扩展性.反向代理+扩展均衡 2)nginx.keepalived.lvs.f5可以很好的解决高可用.扩展性.反向代理+扩展均衡的问题 3)水平扩展scale out是解决扩展性问题的根本方案,DNS轮询是不能完全被nginx/lvs/f5所替代的…
第一章聊了[“为什么要进行服务化,服务化究竟解决什么问题”] 第二章聊了[“微服务的服务粒度选型”] 第三章聊了[“为什么说要搞定微服务架构,先搞定RPC框架?”] 上一章聊了[“微服务架构之RPC-client序列化细节”] 通过上篇文章的介绍,知道了要实施微服务,首先要搞定RPC框架,RPC框架分为客户端部分与服务端部分. RPC-client的部分又分为: (1)序列化反序列化的部分(上图中的1.4) (2)发送字节流与接收字节流的部分(上图中的2.3) 前一篇文章讨论了序列化与范序列化的…
缘起:有个朋友问我分区表在58的应用,我回答不出来,在我印象中,百度.58都没有听说有分区表相关的应用,业内进行一些技术交流的时候也更多的是自己分库分表,而不是使用分区表.于是去网上查了一下,并询问了58到家的DBA专家,将自己收到的信息沉淀下来,share给大伙. 解决什么问题? 回答:当mysql单表的数据库过大时,数据库的访问速度会下降,“数据量大”问题的常见解决方案是“水平切分”. mysql常见的水平切分方式有哪些? 回答:分库分表,分区表 什么是mysql的分库分表? 回答:把一个很…
一.缘起 mysql主从复制,读写分离是互联网用的非常多的mysql架构,主从复制最令人诟病的地方就是,在数据量较大并发量较大的场景下,主从延时会比较严重. 为什么mysql主从延时这么大? 回答:从库使用[单线程]重放relaylog. 优化思路是什么? 回答:使用单线程重放relaylog使得同步时间会比较久,导致主从延时很长,优化思路不难想到,可以[多线程并行]重放relaylog来缩短同步时间. mysql如何“多线程并行”来重放relaylog,是本文要分享的主要内容. 二.如何多线程…
第一章聊了[“为什么要进行服务化,服务化究竟解决什么问题”] 第二章聊了[“微服务的服务粒度选型”] 上一篇聊了[“为什么说要搞定微服务架构,先搞定RPC框架?”] 通过上篇文章的介绍,知道了要实施微服务,首先要搞定RPC框架,RPC框架的职责要向[调用方]和[服务提供方]屏蔽各种复杂性: (1)让调用方感觉就像调用本地函数一样 (2)让服务提供方感觉就像实现一个本地函数一样来实现服务 整个RPC框架又分为client部分与server部分: RPC-client的部分流程如上图,要进行序列化反…
第一章聊了[“为什么要进行服务化,服务化究竟解决什么问题”] 第二章聊了[“微服务的服务粒度选型”] 今天开始聊一些微服务的实践,第一块,RPC框架的原理及实践,为什么说要搞定微服务架构,先搞定RPC框架呢? 一.需求缘起 服务化的一个好处就是,不限定服务的提供方使用什么技术选型,能够实现大公司跨团队的技术解耦,如下图: 服务A是欧洲团队提供服务,欧洲团队的技术背景是Java,可以用Java实现服务: 服务B是美洲团队提供服务,可以用C++实现服务: 服务C是中国团队提供服务,可以用Go实现服务…
需求缘起 大部分互联网的业务都是“读多写少”的场景,数据库层面,读性能往往成为瓶颈.如下图:业界通常采用“一主多从,读写分离,冗余多个读库”的数据库架构来提升数据库的读性能. 这种架构的一个潜在缺点是,业务方有可能读取到并不是最新的旧数据: (1)系统先对DB-master进行了一个写操作,写主库 (2)很短的时间内并发进行了一个读操作,读从库,此时主从同步没有完成,故读取到了一个旧数据 (3)主从同步完成 有没有办法解决或者缓解这类“由于主从延时导致读取到旧数据”的问题呢,这是本文要集中讨论的…