banq
2009-12-01 09:55
1.Expect (R)evolution

2 Dependencies Matter

3 Be Authoritative

4 Never Enough Data

5 Custom Infrastructure

这5个课题我感觉没有前面提出的Partition Everything等四个架构原则具有重大意义。

这5个原则比较高,已经涉及非架构因素,包括项目管理,认为唯一不变的就是变化,这已经上升到哲学了。

xmuzyu写的四个原则容易让人明白,是一个全新异步细分思路,我以前说过,衡量你的系统是否足够细分,就看是否能够插入负载平衡,我们要怀疑代码中任何地方都可能是性能瓶颈,将来都有可能将其割裂,植入异步或负载平衡。

所以,Ebay这里谈的异步已经不是通常意义上的异步,比如我要发一个Email,那么使用异步实现,这是业务异步,而我们这里谈的是架构异步,架构异步比业务异步更广泛,它是在Base思想上的异步,是一种讲究最终一致的异步,而发Email是不讲最终一致的,什么时候发对于系统其他地方不重要,也不用Email发送完,给一个确认(如果是,就是要最终一致了)。

异步和并行编程思路是一脉相承,同一个范畴,就是和我们通常的Spring/Session Bean等同步架构思维做斗争,驱赶他们到一个小的系统,而讲究scalable的系统必定是追求BASE思想的异步架构。

这里的异步和NOSQL模式中的一致性模式是同一个意思:

1.严格一致:序列化立即拷贝更新。(quorum based 2PC )

2.自己读写一致:能够立即看到自己的修改结果,但不一定及时看到其他人修改结果。

3.Session一致性:当客户端被重定向到同一个服务器时,自己读写一致。

4.读系列一致:保证客户端发出多次请求能够看到数据的更新。

5.最终一致Eventual Consistency:需要等待一段时间才能看到以前修改结果。

[该贴被banq于2009-12-01 14:13修改过]

xmuzyu
2009-12-06 19:53
可伸缩性最佳实践

[该贴被xmuzyu于2009-12-06 19:55修改过]

r7raul
2009-12-15 15:41
在交易支付系统中有个问题,比如用户通过银行支付,钱已经付出去了,但是银行没有返回相应的成功信息,如何保证这种信息的一致性(没返回成功信息就不付款)?

sunway
2009-12-18 21:54
2009年12月06日 19:53 "xmuzyu"的内容
可伸缩性最佳实践[该贴被xmuzyu于2009-12-06 19:55修改过]

来这里的人都很牛啊,可伸缩性讲的不错

touchfu
2010-01-18 10:15
讲得非常好!个人理解这也是大部分大型应用需要去努力的方向。

随着业务的扩展,性能的需求提升,异步是必然的结果。这样系统职责分割,异步消息引入,领域模型设计都是不可或缺的。对于帐务类相关的业务,抛弃了传统的分布式事务,但可以用系统意义上的分布式事务完成(靠数据库的执行状态来推动帐务的提交还是回滚)。

yifan5
2014-09-18 15:12
挺好的文章,理念可以帮助我理解一些服务器的东西

clonalman
2014-09-19 12:41
2009-11-26 23:10 "@xmuzyu"的内容
2.1 应用水平切分

在一个大型的系统中往往会涉及到很多的错综复杂的逻辑,这个时候架构师就需要根据不同的功能对系统进行水平的分割,比如按照用户,商品,交易,搜索等功能进行水平的分割。而在具体架构和设计的过程中,我们一般通过不同的jar,b ...

功能模块的划分属于业务的垂直分割,

而业务的水平分割是依一定规则对数据进行聚合,

如楼主的例子,可根据用户注册顺序(用户ID),把用户的商品,交易,评价等相关数据聚合到一起(如放同一个库),尽量避免跨库调用的机会,这样的设计,随着用户注册数量的增加,只需要简单添加数据库即可。。

不论是业务水平分割还是垂直分割都十分考验业务建模的功力

clonalman
2014-09-19 12:56
个人体会,应用模块可以分开,是分布式的,但其存储结构不一定是分开如楼主的用户数据库,商品数据库,交易数据库等,

这也是一个有趣的问题?banq可以讨论以下吗?

猜你喜欢