『分享』简单的亿级构架

[FarBox]

《简单的亿级构架》是一次去他厂做的分享的Topic，基本结构很简单，但很有效，也是FarBox目前采用的基础构架。

实际分享的1个小时里，涉及到很多其它的知识点，我们梳理了主干，就有了这篇文章。

如果你正在做全新的Startup，它或许会有参考的价值；结构非常简单，却能让你的服务变得更加稳健。

http://tech.farbox.com/post/a-simple-structure-for-billions-pv

[yushiro]

LZ文章中说的这种情况， 不能称之为“亿级”吧， 这种简单的通过DNS水平扩展WEB服务器的方式， 没有瓶颈， 真正的瓶颈在这些Web服务器的后端数据库访问请求啊。
难道有那种一次生成静态页面， 再也不变化的场景？

[FarBox]

@jerry74 后端的问题在后端考虑，后端不处理好，单机的负载能力就会弱。

也算是DNS的轮询。但几乎所有的LB系统中，都会有个调度中心，只是现在这个结构的调度中心是DNS；调度可以简单一些，也可以复杂一些。比如某台服务器CPU占比比较高，就不请求它了，这就不是以往常见的DNS轮替了。

@HowardMei Thanks，非常认同！我们开始在做这个设计前，对DNS系统的了解并不深，越到后面，越发觉得互联网的这些初期的协议，其实真的意义深远，我们只是沾光了而已。

[FarBox]

@yushiro 是的。没有严格的瓶颈，但还是有系统开销在的。这个设计跟普通的DNS轮询最大的差别是在有个动态的调度中心，可以按照自己实际的规则，判断节点上CPU负载、带宽负载、连接数等等，然后在这个规则上进行一次最优的线路选择。

真正容易出现的瓶颈确实在数据库的请求上面，这个就跟具体的项目的业务设计有直接关系了。

如果特指Web，做足缓存的颗粒度，确实可以实现一定时间内`一次生成静态页面， 再也不变化的场景`，以一种静态的方式解决，但是页面又是实时动态的。FarBox内是以浏览器语言+网站内文件的变化时间+URL作为缓存key的判断，但这比较特殊，好像没有什么可以具体分享的，并且，也就是常见的一些做法……

[ovear]

lz这套系统真的跟亿万级沾不上。。算是一个最开始的开始吧。
恕我直言，这套系统真的是槽点满满。。只能算是一个设想吧
首先，千万不要用Python做DNS查询，dns协议众多，你贴出来的可以算是最基本的一个协议吧。
如果你要实现智能dns，那么用python光是查询ip所属地点就要吃掉非常多的cpu time了，这样就转变为cpu密集型的，非常不可观。（相关协议为edns）最终出来可能只有几十到几百req，离着亿万级别还差太远太远
第二，调度系统存在问题，首先edns需要合作申请，不然你只能拿到递归dns的ip的，那么你所谓的让dns从server ip中pool一个出来给客户就会存在很大的问题。因为像4个8或者4个114这种公共dns，使用的用户可能比一个省还大，那么最终就会引发雪崩效应。现在的基本方法就是poll多个ip给客户，但是这种情况，ip是随机的，非常可能某一台服务器中的负载会远远大于其他的（实测）。
其他还有很多槽点，比如说dns服务器权责不清。dns服务器可用性问题，还有master自动推举
上面仅仅是dns方面的问题，也就是开始中的开始的问题。应用层还有很多坑的，当然还是希望lz来分享下的。

[hslx111]

堆机器来接亿级的IP，很好奇你需要堆多少机器。。。

[hepin1989]

我觉得还不如akka的cluster

[loserwn]

架构级别的东西，由于能力有限只是学习到了皮毛。特意看了一farbox本身。感觉是个很出色的产品。先站在用户的角度慢慢体会一下。目前，能力有限，只能膜拜ing。

[halfblood]

做技术还是踏实点好……搞个亿级出来，唉！

[FarBox]

@ovear `dns协议众多`是不存在的，像EDNS也只是对它的一个补充，并没有被广泛支持；如果要向Google申请，是简单的，114.114.114.114不是很清楚。如果是指dns解析包众多，这倒是。

这也不是为了实现面向clients端的智能DNS，如果需要做，也是可以的。但是，这不会是cpu密集型的，即使没有使用缓存的前提下，超找最近距离的，用类似2D索引的实现就可以解决这个问题了呀；而IP所属地的查询一般都是在结构化的基础上2分法搜索，这个性能还是很高的……

LOL, `几十到几百req`, 不会的了，Gevent的基础上不是这样子的……

EDNS的申请，要到具体的DNS服务商处申请，这很简单的；也因为如此，所以它只是DNS的一个补充协议。一般ISP提供的本地DNS都是接近用户实际地点的。（虽然，关于面向clients端的智能DNS并不是我们的本意）没有所谓的雪崩效应，规则都是自己能控制的，`某一台服务器中的负载会远远大于其他的`出现这种情况，心跳会反应这个status，就不会再跑请求过去了。

DNS的集群跟数据库的集群不一样，并不需要一个master，如果是指SOA的设置，呃，如果认为这是一个master，就自定规则，SOA记录指向其中指定一台DNS Server就可以了。

[sivacohan]

你这个设计里面有一个重要问题你没说。就是怎么维护一致性。

从你的设计来看，你的机器是跨机房的。那机房间的同步你怎么做？

[soli]

@HowardMei 常常最有价值的不是设计上多么复杂巧妙的系统，而是经过生产环境证明切实可行的系统，这是有真金白银意义的。


===============

我也认同这个观点。

所以，我想请教 @FarBox ，这个『亿级架构』现在有哪些『生产环境』在用？这些环境目前的访问量是多少？

谢谢分享。

[est]

一亿次hello world。

[tititake]

最麻烦的session复制问题和后端数据库的架构没提啊。

[lenzhang]

原来亿级架构还可以这么理解

[openroc]

嗯，推荐看看这个，最佳实践

[两年内从零到每月十亿 PV 的发展来谈 Pinterest 的架构设计]

http://www.oschina.net/translate/scaling-pinterest-from-0-to-10s-of-billions-of-page-views

[9hills]

DNS来实现负载均衡，恕我直言，几台也就可以了。

没听说过100台机器用DNS来做负载均衡的。

[reorx]

DNS 可以用来作负载均衡，但不能是唯一的负载均衡，我见过的亿级别的网站不多，但据我了解都有 LVS + Nginx 实现四层和七层的负载均衡。lz 的“亿级架构”如果没有应用实例，怕是站不住脚的，而且标题也是有问题的，何为「简单」的亿级架构？如果是真正的亿级架构，绝不可能是「简单」二字可以形容，就内容来看，姑且可以理解为亿级架构的简单剖析，大约这才是 lz 这篇分享真正的目的。

另外使用 Python 作为代码示例，不得不说这一点是非常赞的。多数架构文章读完都是知其然不知其所以然，有易读的 Python 代码示例，对很多概念的理解上会透彻很多。倒不是说 lz 一定要用 Python 来做 DNS 解析等事情，这点还是很理解的。

对初学者而言其实是篇非常好的文章，虽然的确如楼上所说有一些不足和不够细致，但就概念的介绍而言足够了。V2EX 上的大家都有对技术有精益求精的追求，所以 lz 不必为大家的诘问介怀，对事不对人的 :)

[cevincheung]

@FarBox
表示各地运营商都是自己固定的缓存时间，不管DNS协议。硬缓存3天。

[HowardMei]

@reorx 哈哈，主要楼主标题党，惹火上身，好在也没明说亿级是指什么，有模糊空间。

用DNS做简单均衡理论上是没问题的，鉴于Farbox静态网页为主，切换速度要求不会太高，肯定用不到每层做动态均衡这么复杂，另外墙内外DNS市场生态不同也是隐含背景，大家批评质疑有利于弄清用途和局限，我个人觉得如果真是生产运行的系统，再用途有限都是有价值的。

基于DNS的Service Discovery系统比这要求还高点，墙外也有人在尝试，以后未尝不会发展成为Anycast这样的主流，生态进化之下，轻装上阵、内核良好的技术常常能大放光芒，考虑太全面是没法子创新的。

[sarices]

楼主可以说说后端数据库怎么处理？