注册 登录  
 加关注
查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

小葫芦君(汉斯的博客)

博客迁移到新博客:https://blog.ssxingshou.com

 
 
 

日志

 
 
关于我

小小葫芦商城,为您提供高品质的商品,一流的产品,一流的包装服务,一流的物流服务,放心购买

互联网应用实验与思考  

2011-11-30 09:41:13|  分类: 默认分类 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
1、路线图,从大到小,从分布式集群开始,到服务器,到应用,到开发实现,到后端优化,到前端优化。
2、每一个点需要哪些技术支持,从面到点进行突破。
      比如:要实现分布式集群,需要哪些技术支持?
      1》、首先是服务器的管理。
      目前,大型的互联网网站都由前端和后端组成,这是最大的划分,前端负责用户体验和数据的呈现问题,而后端涉及到数据的存储,数据的业务处理,以及一些计算结果的处理。这样就需要很多个服务器来进行支撑,采用分布式的服务器架构,好处很多,一个是容灾、一个是可扩展性、一个是负载均衡,但同时又要兼顾单点故障的问题产生。这样服务器集群就成了必然,那通过什么去进行解决上面所提出的问题呢?据淘宝过来的同事介绍,淘宝与阿里巴巴使用的是配置服务器ConfigServer,是自主研发的一个配置管理服务器,用来管理多个服务器集群,管理服务器与服务器之间的通信,负载均衡等等工作。其原理大概是这样的:N台服务器与ConfigServer之间保持一个实时的心跳机制,属于socket长连接,几秒钟检测一次。在N台服务器初始化时,由受管理的服务器主动把自己的服务器信息往ConfigServer发送,比如:如果是server级别的,就发送自己的IP地址、端口号以及所提供的服务的信息,如果是client级别的,就发送自己的IP地址、端口号。这样在ConfigServer就形成了一个服务器关联列表,然后在ConfigServer里面进行操作配置。
      这里举个例子:比如目前由于业务需要,后端需要提供这样的业务服务,ProductService、OrderService、UserService,这是电子商务都通用的服务,在ConfigServer里面以服务作为key,保存这样一个列表:
 服务名称 提供此服务的server IP+端口列表 需要此服务的client IP+端口列表
备注
 UserService 192.168.66.1,192.168.66.2 192.168.66.100,192.168.66.101 提供用户服务接口
其他服务类似这个列表。
      为达到容灾目的,需要对某个设备进行心跳检测,当某server挂掉时,根据心跳检测出来后,迅速在列表中删除该server信息,并通知到该service提供的服务所对应的所有的client,然后client刷新自己获取service的本地缓存配置。当某client挂了,那么ConfigServer就更新为该client提供服务的所有服务列表,并把各自服务的client列表刷新,ConfigServer提供一个web管理界面,可以实时查看管理服务的提供者server和使用者client的信息列表。假设ConfigServer挂了,服务一样存在,而且还可以配置至少3台的ConfigServer,如果这3台配置服务器集群了,又具有自动转换服务的功能,这样就可以减少单点故障发生的几率。在client端,也是需要与server建立连接的,当ConfigServer发送过来的服务提供者更新时,client得把不在列表里面的server的连接丢弃,建立新增的server的连接。这里client与server也需要建立长连接?
      为达到可扩展目的,需要在新增一个server或者新增一个client的时候,主动发信息给ConfigServer,在里面进行统筹规划,这样各自服务的提供者和使用者就可以不用重启就可以使用新增的服务和提供新增的服务了。
      为达到负载均衡的目的,可以为一个服务配置多个server进行提供,不同的client可以根据自己的规则(比如轮询、随机、按权重等),自由选择自己需要的server进行使用,减少对单点的负载。
      从上面的需求看,目前市面上有一个hadoop的子项目zookeeper,完全可以做到ConfigServer所提供的功能,因此得开发一个通用的zookeeper-client出来,给server以及client使用。里面需要实现的功能在上面都已经列出来了。
      2》、需要开发server与client之间的通信协议与数据传递的功能,也就是rpc,那这个rpc的业务场景是怎样的呢?
      目的:server与client之间数据的传递
      描述:
      1)、client发起一个服务请求,比如:UserService.getUserInfo(Long userId); 一般的处理是需要将参数进行序列化后再做socket的传输,server端通过rpc收到后,根据协议进行反序列化,然后转换成对象去调用接口,在经过业务计算后,得到一个结果集,然后再把这个结果集进行序列化,然后传输给client端接收,client再进行反序列化工作,再将结果返回到前端展现。这里的rpc,有这样一种需求,就是client发起一个请求,server端接收到请求后,立即进行反馈,同时另外一个并发线程去处理并返回结果,这样,client如何获得server并发线程返回的结果的呢?这就需要一个notify框架来支撑,也叫消息服务框架。server往client端推送。client有个类似watch功能
      2)、实现方式:
      采用netty+序列化进行实现。
      3》、消息服务框架notify框架,notify有pull跟push。
  评论这张
 
阅读(530)| 评论(2)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018