首页 > 代码库 > 蚂蚁变大象:浅谈常规网站是如何从小变大的(八)(转)

蚂蚁变大象:浅谈常规网站是如何从小变大的(八)(转)

原文:http://blog.sina.com.cn/s/blog_6203dcd60100y1vi.html

         【第十一阶段 :命名位置服务】

 

         在前面我们不止一次提到了命名位置服务(Naming & Location Service)。在不同的架构或者公司里面,这个名字往往不一样,比如,在java里面叫JNDIJava Naming & Directory Interface),在有些地方可能会叫做资源位置系统(Resource Location System)。

         总之,不管叫什么名字,我们要知道的就是为什么要有这样的系统?他能做哪些事情?他有哪些实现方式?等等。

         在我们之前的章节中,我们的服务从一台单机扩展到十台左右的多机,到成百上千台机器。我们的服务从单一的一个服务扩展到成百上千的服务。这么多的机器、服务,如果不好好管理,我们就崩溃了。比如,我们的服务A要连接服务B,如果现在采用配置IP的方式,可能需要配置几十台机器的IP,如果其中某些机器出现了变更,那所有服务A连接服务BIP都要改变。如果所有的服务都是这样,这将是多么痛苦的一件事情 Orz

         如果我们只是简单的将我们的服务看成是一个个的资源(Resource),这些资源可以是数据库,可以是cache,可以是我们自己写的服务。他们都有一个共同的特点,就是在某一个IP上,打开一个PORT,遵循一定的协议,提供服务。

         我们先简单的来构建这样一个模型。我们这里先抽象一个接口,叫做Interface Resource。这个接口下面有多个实现,比如:DBResourceCacheResourceImageResource等等。具体类图如下:

 

 

         有了这样的一个层次结构以后,我们为了得到某一个实例,有多种方式,比如:

         1、直接生成的方式:

                   Resource r = new ImageResource();

         2、间接生成的方式:

                   A、比如我们在设计模式中经常使用到的工厂模式:

                   Resource r = ResourceFactory.get(“Image”);

                   BIoCInversion of Control)方式:

                   Resource r = (Resource)Container.getInstance(“ImageResource”);

 

         我们打一个不是很完全匹配的比方。我们如果直接在服务中采用IP配置的方式,就类似于直接生成实例一样,如果实例发生变化,或者要调整生成的对象,就需要修改调用者的代码。也就是说,如果其他服务的IP发生变化,我们调用者就需要修改配置,重启程序等等。而且对于如果有很多很多这样的服务,我们就崩溃了。

         那么,我们觉得更好的一种方式呢,就是,如果有一个工厂,或者一个容器,来帮我们管理这一堆的服务IP、端口、协议等等,我们要用的时候,就只需要叫一声:“给我XXX服务的实例”,那是多么美妙的事情啊!

         其实呢,我们的命名位置服务要做的就是这样的事情。他类似于一个Meta Server,记录所有服务的IPportprotocol等基础信息,以及检查这些服务的健康状态,提供给调用者最基础的信息服务。同时,再结合调用时的负载均衡策略,就可以帮我们提供很好的资源管理方式。

         这个服务,提供注册、注销、获取列表等接口。他的存在,就将直接关联的两个服务给很好的解耦了。我们看看对比:

 

 

         在没有Naming Location Service的时候,我们的服务相互直接依赖,到最后,关联关系及其复杂,可能完全没有办法维护。

         如果我们增加Naming Location Service以后,这个状态就可以得到极大的改善。

         这个时候,我们所有的服务都在NLS上注册,同时向NLS获取其他服务的信息,所有的信息都汇聚到NLS上管理。

         有了这个服务,就好类比成我们生成一个类的时候,采用间接的方式生成。

         Service s = (Service) NamingService.getService(“Image”);

 

         好,有了这样一个架构以后,我们可能会关注这个NLS如何来实现。

         实现这个服务有简单的方式,也有复杂的方式。关键是要考虑以下几个方面:

         1、如何找到这个NLSNLS是所有服务的入口,他应该是有一个不变的地址来保证我们的服务。因此,我们可以使用我们之前提到过的Virtual Server的方案,通过一个(或多个)固定的域名或者IP来绑定这个服务。

         2、可用性(Availability)和数据一致性(Consistency)。因为这个服务是一个最基础的服务,如果这个服务挂掉了,其他服务就没有办法来定位了。那么这个服务的稳定和可靠性就是及其重要的。解决方案有如下几种:

         A、单机实现服务,本地增加备份。我们用单机来实现这样一个服务,这样可以保证绝对的数据一致性。同时,每次请求数据后,每个服务本地保留一份备份数据。当这个服务挂掉了,就使用最近的一次备份。这个方案对于大多数情况是足以应付的,而且具备简单粗暴有效的特点。

         B、多机服务,数据同步。采用多机提供服务,信息更新时进行数据同步。这种方式的优点就是服务可以保证7*24小时服务,服务稳定性高。但是,问题就是维护成败会比上面一种方式高。

         3、功能。实现服务名称到IPPortProtocol等信息的一个对应。如果要设计的更通用,比如可以注册任何信息,就只需要实现Key-Value的通用数据格式。其中,Value部分需要支持更多更丰富的结构,比如ListSet等。

 

         有了这样的一个系统,我们就可以很方便的扩展我们的服务,并且能很好的规范我们服务的获取、访问接口。