这是一个创建于 3813 天前的主题，其中的信息可能已经有所发展或是发生改变。
《简单的亿级构架》是一次去他厂做的分享的Topic，基本结构很简单，但很有效，也是FarBox目前采用的基础构架。
实际分享的1个小时里，涉及到很多其它的知识点，我们梳理了主干，就有了这篇文章。
如果你正在做全新的Startup，它或许会有参考的价值；结构非常简单，却能让你的服务变得更加稳健。
http://tech.farbox.com/post/a-simple-structure-for-billions-pv
实际分享的1个小时里，涉及到很多其它的知识点，我们梳理了主干，就有了这篇文章。
如果你正在做全新的Startup，它或许会有参考的价值；结构非常简单，却能让你的服务变得更加稳健。
http://tech.farbox.com/post/a-simple-structure-for-billions-pv
 |
1
binux 2014-06-17 16:44:11 +08:00
负载均衡是DNS做的？不怕ISP、用户缓存？防止单点故障的方案那么多，怎么就选了个这个。。
心跳自己做？那么多开源方案工具不用？为什么？ |
 |
2
tftk 2014-06-17 17:07:45 +08:00  1
完全没看出来和'亿级'有何关系.
|
 |
3
kslr 2014-06-17 17:12:52 +08:00
标题党
|
 |
4
dongbeta 2014-06-17 17:16:27 +08:00
好吧 我是看到 “亿级” 才进来的，感觉和楼上一样
|
 |
5
missdeer 2014-06-17 17:21:06 +08:00
确实有标题党嫌疑
|
 |
6
FarBox OP @binux 这主要是水平扩展的结构，所以一个特性是具备了负载均衡的能力。另外，DNS作为基础的负载均衡，也是一个非常常见的手法。
不论ISP或者本地的DNS查询，都是遵循的DNS的基本协议，所以你可以自己控制TTL的时间，那么出现某个节点问题，可以在很短的窗口期内自动恢复。我们在文章中比较详细的解释过了。 防止单点故障的方案，很多都要考虑不同的场景，而有自己的局限性；比如考虑到节点是分布在各个机房甚至各个国家的，这就过滤掉大部分的解决方案了。 不过@binux 也可以分享一些，这样能给大家有更多参考的可能。 `心跳`的逻辑本身很简单，我们在文章中也贴了主要的代码，加上内部的一些逻辑判断，都是百行内的规模。比`心跳`更加重要的是，它是按照什么形式跳动的，比如自己web程序中一个组件能否正常运作，这种判断引入第三方的方案，实际上更加麻烦。 更加重要的是，`心跳`只是分布式构架中常见的组成部分，它是逻辑的部分，我们可能这个解释不清楚，举个例子，比如`Serf`，它肯定有心跳机制，但它不是心跳的package…… |
|
7
FarBox OP |
 |
8
qiongqi 2014-06-17 17:30:25 +08:00
亿级是啥？PV？
|
 |
9
acthtml 2014-06-17 17:33:49 +08:00
恩，不错。
|
 |
12
rrfeng 2014-06-17 17:41:54 +08:00
这也讲的太简单了。
真正的服务跑起来，一切都复杂了 |
|
15
FarBox OP @dongbeta 主要是写起来快，代码逻辑比较干净。
其实，最主要的原因还是我们对Python是最熟悉的，FarBox使用了很多第三方库，在Python的前提下，我们对里面存在的问题能直接发现并处理掉；虽然其它比如Node也能上手，但没有这方面的自信。 也题外话一个：其实Python最大的问题就是性能的问题，我们现在一些主要模板基本上都是引入了C包，而且缓存机制以及比较完善了，性能的问题就不大了。比如我们渲染一个页面现在平均能控制在10ms以下了…… |
|
16
FarBox OP |
|
17
FarBox OP @rrfeng 是的。基本逻辑是这么简单的，即使不是做后端的Dev，也能解释清楚。
不过，也有另外一方面的考虑，构架足够简单，所以可以将它分离出去而不用去考虑它的存在；复杂的就归于复杂的本身。 其实，如果开发团队的人数和实力是可控的，复杂也是可控的。也不得不承认，现实情况，项目过程中太容易腐败了，可能也是部分这个原因吧，所以我们出来自己做产品。 :) |
 |
18
jerry74 2014-06-17 18:08:08 +08:00
动态内容的都不用考虑后端?
一个dns轮替就叫亿级构架? |
 |
19
flykite 2014-06-17 18:22:01 +08:00
呃，这个应该是系列教程，万里长征的第一步才对。期待后面有更多佳作。
|
 |
20
HowardMei 2014-06-17 18:34:58 +08:00 1
很好的分享，常常最有价值的不是设计上多么复杂巧妙的系统，而是经过生产环境证明切实可行的系统，这是有真金白银意义的。
|
 |
21
yushiro 2014-06-17 18:43:22 +08:00
LZ文章中说的这种情况， 不能称之为“亿级”吧， 这种简单的通过DNS水平扩展WEB服务器的方式， 没有瓶颈， 真正的瓶颈在这些Web服务器的后端数据库访问请求啊。
难道有那种一次生成静态页面， 再也不变化的场景？ |
|
22
FarBox OP |
|
23
FarBox OP @yushiro 是的。没有严格的瓶颈，但还是有系统开销在的。这个设计跟普通的DNS轮询最大的差别是在有个动态的调度中心，可以按照自己实际的规则，判断节点上CPU负载、带宽负载、连接数等等，然后在这个规则上进行一次最优的线路选择。
真正容易出现的瓶颈确实在数据库的请求上面，这个就跟具体的项目的业务设计有直接关系了。 如果特指Web，做足缓存的颗粒度，确实可以实现一定时间内`一次生成静态页面， 再也不变化的场景`，以一种静态的方式解决，但是页面又是实时动态的。FarBox内是以浏览器语言+网站内文件的变化时间+URL作为缓存key的判断，但这比较特殊，好像没有什么可以具体分享的，并且，也就是常见的一些做法…… |
 |
24
ovear 2014-06-17 19:28:58 +08:00
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来分享下的。 |
 |
25
hslx111 2014-06-17 19:29:05 +08:00
堆机器来接亿级的IP，很好奇你需要堆多少机器。。。
|
 |
26
hepin1989 2014-06-17 19:36:35 +08:00
我觉得还不如akka的cluster
|
 |
27
loserwn 2014-06-17 19:41:13 +08:00
架构级别的东西，由于能力有限只是学习到了皮毛。特意看了一farbox本身。感觉是个很出色的产品。先站在用户的角度慢慢体会一下。目前，能力有限，只能膜拜ing。
|
 |
28
halfblood 2014-06-17 19:50:51 +08:00
做技术还是踏实点好……搞个亿级出来，唉！
|
|
29
FarBox OP @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就可以了。 |
 |
30
sivacohan 2014-06-17 20:28:45 +08:00 via Android
你这个设计里面有一个重要问题你没说。就是怎么维护一致性。
从你的设计来看，你的机器是跨机房的。那机房间的同步你怎么做？ |
 |
31
soli 2014-06-17 20:40:07 +08:00
|
 |
32
est 2014-06-17 20:43:03 +08:00
一亿次hello world。
|
 |
33
tititake 2014-06-17 21:10:09 +08:00
最麻烦的session复制问题和后端数据库的架构没提啊。
|
 |
34
lenzhang 2014-06-17 21:50:34 +08:00
原来亿级架构还可以这么理解
|
 |
35
openroc 2014-06-17 23:00:49 +08:00
嗯，推荐看看这个，最佳实践
[两年内从零到每月十亿 PV 的发展来谈 Pinterest 的架构设计] http://www.oschina.net/translate/scaling-pinterest-from-0-to-10s-of-billions-of-page-views |
 |
36
9hills 2014-06-17 23:15:29 +08:00
DNS来实现负载均衡，恕我直言，几台也就可以了。
没听说过100台机器用DNS来做负载均衡的。 |
 |
37
reorx 2014-06-18 01:53:03 +08:00 1
DNS 可以用来作负载均衡，但不能是唯一的负载均衡，我见过的亿级别的网站不多，但据我了解都有 LVS + Nginx 实现四层和七层的负载均衡。lz 的“亿级架构”如果没有应用实例，怕是站不住脚的，而且标题也是有问题的，何为「简单」的亿级架构？如果是真正的亿级架构，绝不可能是「简单」二字可以形容，就内容来看，姑且可以理解为亿级架构的简单剖析，大约这才是 lz 这篇分享真正的目的。
另外使用 Python 作为代码示例，不得不说这一点是非常赞的。多数架构文章读完都是知其然不知其所以然，有易读的 Python 代码示例，对很多概念的理解上会透彻很多。倒不是说 lz 一定要用 Python 来做 DNS 解析等事情，这点还是很理解的。 对初学者而言其实是篇非常好的文章，虽然的确如楼上所说有一些不足和不够细致，但就概念的介绍而言足够了。V2EX 上的大家都有对技术有精益求精的追求，所以 lz 不必为大家的诘问介怀，对事不对人的 :) |
 |
38
cevincheung 2014-06-18 08:46:24 +08:00
@FarBox
表示各地运营商都是自己固定的缓存时间，不管DNS协议。硬缓存3天。 |
|
39
HowardMei 2014-06-18 09:35:35 +08:00 via iPad
@reorx 哈哈，主要楼主标题党，惹火上身，好在也没明说亿级是指什么，有模糊空间。
用DNS做简单均衡理论上是没问题的，鉴于Farbox静态网页为主，切换速度要求不会太高，肯定用不到每层做动态均衡这么复杂，另外墙内外DNS市场生态不同也是隐含背景，大家批评质疑有利于弄清用途和局限，我个人觉得如果真是生产运行的系统，再用途有限都是有价值的。 基于DNS的Service Discovery系统比这要求还高点，墙外也有人在尝试，以后未尝不会发展成为Anycast这样的主流，生态进化之下，轻装上阵、内核良好的技术常常能大放光芒，考虑太全面是没法子创新的。 |
 |
40
sarices 2014-06-18 09:52:50 +08:00
楼主可以说说后端数据库怎么处理？
|
|
41
rrfeng 2014-06-18 10:22:51 +08:00
我觉得这整楼里也没几个人真正摸过『亿级』的架构……
私以为 lz 的示例只能当作教科书式的启发。或许 lz 本来就是这么个意思，然后被大家误解了。 或者 lz 真用这些代码实现了一个『亿级』的东西呢 |
 |
42
usoluyun 2014-06-18 11:07:43 +08:00
恕我直言，负载均衡和dns轮训本身是两回事。你用dns轮训代替负载均衡，就需要额外的工作量用在心跳程序开发部署维护，mongodb维护，dns服务器要有额外的逻辑去自动剔除不工作的服务器，以及把回复工作的服务器加回来等等工作。只看表面很简单，这些额外的工作量和维护量还不如用haproxy或者lvs做负载均衡来的直接。
|
 |
43
chagel 2014-06-18 12:52:27 +08:00
AWS ELB + Auto Scaling
|
 |
44
RangerWolf 2014-06-18 13:42:26 +08:00
自己连W级别都没摸过~ 悲剧。。。
|
 |
45
ototsuyume 2014-06-18 14:21:08 +08:00
纯标题党，pv达到亿级的网站系统难点是如何保证后端业务逻辑的正确性和可用性，特别是涉及到并发事务的业务
|
Select Language