在线百万用户量下的系统架构

题记
本文是从PPT中整理而来,细节问题没有描述的太清楚,有问题可以直接与我联系,或者是以后会整理出相对比较完善的文档.


[size=large][color=olive]一.要解决的问题和方案的选择.[/color][/size]

一般而言,我们希望达到的目标是这样的:
[quote] 一个高并发的系统
一个稳定的系统
一个高扩展性的架构
一个简洁的方案[/quote]

[color=darkblue]关于最后一点,从前端到后端解决并发/稳定/扩展可能有很多种方案.从机器的硬件性能到数据库的扩展设计等等都会有自己的方案,这里给出的是一个我们认为相对简洁高效的SCA方案.[/color]


[size=large][color=olive]二.关于Sql的使用限制[/color][/size]

[quote]绝对不允许出现跨表的查询

DB的设计更大程度上取决于缓存的设计

防止穿透缓存直接到达DB的访问

将业务逻辑放到代码中实现,不要忘了DB的主要作用毕竟是存储[/quote]


DB不是用来解决并发问题的,并发靠缓存.所以针对DB的查询都应该是精简的,尽可能的可以被缓存的数据.

怎么样能保证缓存使用的最大化呢?

1.每一个查询只缓存ID.
2.根据ID取对象单独缓存.


维护缓存中的数据也是一件比较麻烦的事情.如果维护缓存的代价太大,不如直接使用失效策略.
这也要看具体的业务场景.


[size=large][color=olive]三.服务[/color][/size]

这里介绍的是使用Apache Tuscany提供的SCA的解决方案.简单的来说.我们是将一个个复杂的系统拆解成可以独立布署的服务,每一个服务提供的功能都是可以做平滑的扩展的.

有关服务的一些要点如下:

[quote]没有业务逻辑的基础服务

包含业务逻辑的复杂服务

独立折分和部署

数据读写部分只交给服务处理

尽量减少服务之间的相互依赖

Controll负责服务之间的调度[/quote]


这样从前到后分别是:WEB层,Service层,DB层.
WEB层是Controll层,负责解析用户的请求,调用不同的Service,并返回结果给用户.WEB层可以通过布署多台WEB来实现.
Service层负责处理业务逻辑和对数据操作的封装,Service是有多个的,不同的业务划分为不同的Service,同一种类型的Service依照负载情况可以布署多台.
DB层负责数据的持久化,大数据量使用分库.


[size=large][color=olive]四.工具[/color][/size]


[quote]尽可能多的做设计

尽可能少的写实现

尽可能多的测试

尽可能多的分析
[/quote]


用到的开源软件列表:
1.Mysql 数据库
2.DAL是对数据读写的封装,包括对于缓存的处理.
3.Tuscany 实现SCA的功能.
4.Scallop.对Tuscany的扩展,实现Tuscany的负载均衡.
5.Memcache 缓存.
6.Qpid JMS系统
7.DemoCode 代码生成工具