write down,forget
标签 Tag : 架构

Chapter 1. Asterisk ,The Architecture of Open Source Applications

<Category: 读书> Comments Off on Chapter 1. Asterisk ,The Architecture of Open Source Applications

titlebar

chapter 1.Asterisk by Russell Bryant http://www.aosabook.org/en/asterisk.html

这章主要介绍了“电话交换机”asterisk的设计,虽然这个项目的历史悠久,Mark Spencer于1999,因为自己开的公司(Linux Support Services)刚好有这个需求–一个电话系统,但是有没有钱买,于是就自己弄了一个,后面发现该系统很受欢迎,他的公司便专心负责asterisk上来,并改名为Digium。

 

Asterisk的英文意思是指字符“*",Mark想通配所有的电话技术,包括模拟信号啦,数字信号啦,神马PSTN啦(public switched telephone network),voip啦,统统都可以接入到asterisk中。

 

一旦电话是通过asterisk系统进行拨打或者接听的,那么在这里就可以做很多事情了,比如电话录音,回放,10086里面烦人的语言系统,电话录音,语言邮件,语言识别,甚至实时翻译(老毛子打过来,听不懂怎么办,业务还得继续做啊)

 

系统架构比较简单清晰,有几个概念:

channel,每一个呼叫相当于是一个connection,一个连接,呼叫方是一个channel,接听方是一个channel,asterisk在中间负责调度(channel bridging)。

twoChannels

frame,通讯的数据以”帧"来传递,帧有不同的数据类型,Voice、Video、Modem、Control等等,

channel driver,很显然asterisk支持如此多的通讯协议,那就需要相对应的驱动来支持,扩展驱动只需用asterisk定义的抽象接口即可。

channelLayers

Dialplan Applications,主要是负责处理channel的,这里面就可以做很多事情,可以灵活组合多个应用来对一个channel进行处理。

后面还介绍了语音邮件是怎么收取的,网络监控,多线程处理,电话桥接等内容,

感兴趣的自己去看看吧,地址:http://www.aosabook.org/en/asterisk.html

本文来自: Chapter 1. Asterisk ,The Architecture of Open Source Applications

豆瓣技术架构的发展历程 @ QCon Beijing 2009

<Category: 云里雾里, 分布式, 架构> Comments Off on 豆瓣技术架构的发展历程 @ QCon Beijing 2009

转,学习

现场视频:InfoQ: 豆瓣网技术架构变迁

本文来自: 豆瓣技术架构的发展历程 @ QCon Beijing 2009

Force.com的多租户架构 [转]

<Category: 云里雾里, 架构> Comments Off on Force.com的多租户架构 [转]

由于Force.com所负载的应用不论是在定制方面的灵活性上,还是所承受的负载上,对基于多租户的架构而言,都是史无前例的,导致之前提到的一些模型或者改动已经无法满足要求了,所以Salesforce在Force.com引入了通过Metadata(元数据)驱动的多租户架构来动态生成快速的,可伸缩的和可定制的应用。接下来,将一步步为大家揭开Force.com多租户架构的神秘面纱,首先是它的总体架构。

阅读这篇文章的其余部分 »

本文来自: Force.com的多租户架构 [转]

Hadoop分布式文件系统:架构和设计要点

<Category: Hadoop, 云里雾里> Comments Off on Hadoop分布式文件系统:架构和设计要点

原:http://hadoop.apache.org/common/docs/current/hdfs_design.html【英文】

一、前提和设计目标
1、硬件错误是常态,而非异常情况,HDFS可能是有成百上千的server组成,任何一个组件都有可能一直失效,因此错误检测和快速、自动的恢复是HDFS的核心架构目标。
2、跑在HDFS上的应用与一般的应用不同,它们主要是以流式读为主,做批量处理;比之关注数据访问的低延迟问题,更关键的在于数据访问的高吞吐量。
3HDFS以支持大数据集合为目标,一个存储在上面的典型文件大小一般都在千兆至T字节,一个单一HDFS实例应该能支撑数以千万计的文件。
4HDFS应用对文件要求的是write-one-read-many访问模型。一个文件经过创建、写,关闭之后就不需要改变。这一假设简化了数据一致性问题,使高吞吐量的数据访问成为可能。典型的如MapReduce框架,或者一个web crawler应用都很适合这个模型。
5、移动计算的代价比之移动数据的代价低。一个应用请求的计算,离它操作的数据越近就越高效,这在数据达到海量级别的时候更是如此。将计算移动到数据附近,比之将数据移动到应用所在显然更好,HDFS提供给应用这样的接口。
6、在异构的软硬件平台间的可移植性。
阅读这篇文章的其余部分 »

本文来自: Hadoop分布式文件系统:架构和设计要点