工作中涉及到的应用负载的一些想法

阅读更多

一些胡乱的想法与实现

 

场景：生产者与消费者模型，前端一台ftpServer接收文件，一个文件接收完成后由一个后台进程对其进行业务处理。

 

1.       简单架构

这种设计下，不存在负载均衡，所有接收完成的文件，全部由业务处理进程加工。

业务处理进行的工作：定时任务取可处理文件，取到后进行处理，一个文件可重试N次后决定其处理结果。

 

  

  

2.       带负载架构

这种设计下，每个业务处理进程在不同的调度点，从数据库中取一定数量的文件进行处理。每个业务处理进程完成的工作都是相同的，一个结点挂了，不应响其他结点处理。

 

       

      

 

3.       按业务类别进行负载

 

随着业务需求的变化，对接收完成的文件按其类别进行不同的业务处理操作。可以考虑按业务类别进行负载。可能带来的好处，当某类业务处理操作消耗资源校多时，可考虑增加部署资源。 

  

     a.

 

 

 

 

b. 增加了中间层服务器，由其负责连接数据库，获取待处理文件资源。中间层服务器可以横向扩展进行负载，业务处理进程可从基础服务处得到中间层服务器列表，取其一可用IP进行访问。 中间层做横向扩展时，待处理文件资源需要做同步操作。

 

 

后记，随着业务处理进程的增多，随着各种服务器的增加，当设备数量增长到一定程度时。对服务器的快速管理、部署、排错等运维需求将浮出水面。感觉需要这么一套IT运维管理的机制与系统。或者是不是可以考虑类似hadoop项目这种分布式处理方案？

 

 

• 
• 大小: 12.9 KB

• 
• 大小: 45.8 KB

• 
• 大小: 46.1 KB

• 
• 大小: 55.1 KB

• 查看图片附件