题记
本文是从PPT中整理而来,细节问题没有描述的太清楚,有问题可以直接与我联系,或者是以后会整理出相对比较完善的文档.
一.要解决的问题和方案的选择.
一般而言,我们希望达到的目标是这样的:
引用
一个高并发的系统
一个稳定的系统
一个高扩展性的架构
一个简洁的方案
一个稳定的系统
一个高扩展性的架构
一个简洁的方案
关于最后一点,从前端到后端解决并发/稳定/扩展可能有很多种方案.从机器的硬件性能到数据库的扩展设计等等都会有自己的方案,这里给出的是一个我们认为相对简洁高效的SCA方案.
二.关于Sql的使用限制
引用
绝对不允许出现跨表的查询
DB的设计更大程度上取决于缓存的设计
防止穿透缓存直接到达DB的访问
将业务逻辑放到代码中实现,不要忘了DB的主要作用毕竟是存储
DB的设计更大程度上取决于缓存的设计
防止穿透缓存直接到达DB的访问
将业务逻辑放到代码中实现,不要忘了DB的主要作用毕竟是存储
DB不是用来解决并发问题的,并发靠缓存.所以针对DB的查询都应该是精简的,尽可能的可以被缓存的数据.
怎么样能保证缓存使用的最大化呢?
1.每一个查询只缓存ID.
2.根据ID取对象单独缓存.
维护缓存中的数据也是一件比较麻烦的事情.如果维护缓存的代价太大,不如直接使用失效策略.
这也要看具体的业务场景.
三.服务
这里介绍的是使用Apache Tuscany提供的SCA的解决方案.简单的来说.我们是将一个个复杂的系统拆解成可以独立布署的服务,每一个服务提供的功能都是可以做平滑的扩展的.
有关服务的一些要点如下:
引用
没有业务逻辑的基础服务
包含业务逻辑的复杂服务
独立折分和部署
数据读写部分只交给服务处理
尽量减少服务之间的相互依赖
Controll负责服务之间的调度
包含业务逻辑的复杂服务
独立折分和部署
数据读写部分只交给服务处理
尽量减少服务之间的相互依赖
Controll负责服务之间的调度
这样从前到后分别是:WEB层,Service层,DB层.
WEB层是Controll层,负责解析用户的请求,调用不同的Service,并返回结果给用户.WEB层可以通过布署多台WEB来实现.
Service层负责处理业务逻辑和对数据操作的封装,Service是有多个的,不同的业务划分为不同的Service,同一种类型的Service依照负载情况可以布署多台.
DB层负责数据的持久化,大数据量使用分库.
四.工具
引用
尽可能多的做设计
尽可能少的写实现
尽可能多的测试
尽可能多的分析
尽可能少的写实现
尽可能多的测试
尽可能多的分析
用到的开源软件列表:
1.Mysql 数据库
2.DAL是对数据读写的封装,包括对于缓存的处理.
3.Tuscany 实现SCA的功能.
4.Scallop.对Tuscany的扩展,实现Tuscany的负载均衡.
5.Memcache 缓存.
6.Qpid JMS系统
7.DemoCode 代码生成工具