转载请注明出处：jiq•钦's
technical Blog 版权所有 author by 季义钦
一、 动机
当前我们已经全面进入到分布式应用时代，后端已经开始全面服务化，根据职责拆分为多个子系统，并且以廉价服务器集群进行支撑。
但是在这样一种架构下：
1、 减轻配置灾难：
服务、网站、FTP服务器、数据库、公共组件等资源的配置信息，以及一些全局的系统配置参数会在多个地方被配置并使用。
随着各类资源的种类和数量增多，加之引用这些资源配置信息的子系统越来越多、配置文件种类的多样化，一方面导致各类资源在多个地方被复用的时候重复配置，维护起来十分困难(配置灾难)，另一方面导致在系统升级、迁移时需要修改的配置项太多。
因此我们需要一种集中管理配置信息的方式，满足逻辑清晰、易于升级部署和维护、可靠存储、读写快速方便的要求，最大程度减轻运维压力。特别注意，我认为更重要的是在将配置集中进行管理的同时，制定出适合于每个开发团队或某些系统的配置管理规范，使得配置管理范围更加清晰，比如我们团队目前将配置项划分为：公共硬件，公共软件，服务，网站，数据库，全局参数六大类。
2、 服务访问透明：
目前大多数的做法是：仍旧在需要访问服务的地方配置服务地址信息，对于后端服务子系统通过F5负载均衡器、虚拟IP(需要一个到真实服务IP的转换手段)等方式来做到服务的负载均衡。但是随着服务数量的增多和系统访问量增加，导致：需要配置和管理的服务地址信息也越来越多，系统运维、部署、迁移困难；为现有的服务增加一个备份需要重新配置负载均衡设备；旧的异构语言的软件资产难以直接接入到系统中进行复用；F5等单点负载均衡器可能成为性能瓶颈等等问题。
所以我们需要能够做到：1) 服务提供者位置和数量的变化对所有服务消费者来说完全透明化；2) 一种异构语言的服务能够无缝接入系统提供服务；3) 一些关键性服务能够无缝地增加新的备份，以提高服务的可靠性和请求处理能力；4) 避免单点压力/故障。
因此我们需要一种能够透明地管理接入的所有服务的方式，使得服务消费者无需关注服务提供者的数量、位置、实现语言等信息，只需要提供服务名称获得服务访问代理，然后消费服务。
3、服务治理：
(1) 服务监控、预警;
(2) 哪些服务需要多少台机器支撑？什么时候该加机器？
所以理想的分布式体系架构应该是这样：
二、 总体架构
1总体架构图：
2 模块组成
分布式注册中心由注册中心和客户端库两个模块组成。
(1) 注册中心模块包含以下两个部分：
注册中心集群：以目录树的形式存储和维护服务信息、配置信息。（ZooKeeper集群实现）
Web配置界面：以JSP网站的形式存在，方便监控和管理注册中心集群中维护的服务信息和配置信息（Jquery+BootStrap+JSP+Strusts2+Spring实现）
(2) 注册中心客户端库模块需要针对每一种语言开发，如对于NET客户端就以DLL形式存在，针对Java客户端就以jar文件形式存在，其主要负责与注册中心集群通信，应用程序通过其注册和发现服务、设置和获取配置。这个模块应同注册中心模块同步实现及发布。
备注：服务治理功能还未开始开发。
三、 如何开始
1 安装Zookeeper集群
安装步骤较为简单，可参考官网。
开发，测试环境可采用单点模式，生产环境尽量采用集群模式，数量在3台最为合适，如果条件运行，最理想的是跨机房部署zookeeper节点，以做到zk集群的容灾备份，虽然我们的框架中一定程度容忍zookeeper集群不可用，但是应尽量避免。
2 发布分布式注册中心管理网站
第一步：解压安装tomcat，并将分布式注册中心war文件放到webapps目录下
第二步：修改配置文件，指定初始化配置类别
第三步：修改配置文件，指定zookeeper集群连接字符串
第四步：启动tomcat，在浏览器输入http://{IP}/zk_regcenter/login.jsp，输入admin/admin用户登录配置中心管理系统，进行配置管理和服务监控。
3 引入客户端库进行开发(C#版)
第一步：创建分布式注册中心访问实例：
方式1：自定义配置实例化
ZooKeeperFactory zooKeeperFactory = new DefaultZooKeeperFactory();
EnsembleProvider ensembleProvider = new FixedEnsembleProvider();
RetryPolicy retryPolicy = new ExponentialBackoffRetry(3);
RegisterCenterClient rgClient = new RegisterCenterClient(zooKeeperFactory, ensembleProvider, retryPolicy, 30000, 3000);
自定义zookeeper实例工厂、连接字符串读取对象、重试策略进行访问实例的初始化。
方式2：默认配置实例化
RegisterCenterClient rgClient = new RegisterCenterClient(30000, 3000);
方式3：单例模式
注册中心访问实例可以多个进程间共享，因为不涉及数据状态等存储，只有连接访问代码，类似于数据库操作实例，是可重入的，所以为了进一步提升效率和节约内存，我们可以将其维护为单例，分布式注册中心客户端库已经提供了这样的方法。
RegisterCenterClient rgClient = RgClientFactory.GetInstance();
第二步：开始访问：
(1) 服务提供者注册服务：
ServiceInfo info = new ServiceInfo() {
serviceName = "WCFCProxy",
serviceIP = "192.101.104.6",
servicePort = 1505,
language = Language.NET,
protocol = Protocol.TCP,
serviceAddr = "WCFCProxyManage"
};
rgClient.RegisterService(info);
(2) 服务消费者消费服务
string errMsg = "";
IWCFCProxy proxy = rgClient.GetProxy<IWCFCProxy>("WCFCProxy", null, out errMsg);
if (proxy != null && string.IsNullOrWhiteSpace(errMsg))
{
DataSet ds = proxy.GetAllMessageConfigByUserID(352);
}
注意上面获取服务访问代理的第二个参数，这是你要访问的服务提供者中的一个无参的接口，你可以将接口名称传递进去，分布式注册中心在每次给你返回访问代理之前会用这个接口名称去进行服务调用，测试访问代理是否可用，一旦调用成功，就会返回当前缓存中的访问代理，都则重新创建代理，并刷新缓存后返回。
所以如果你想在返回访问代理之前测试其有效性，可以将测试方法名称传递进去：
IWCFCProxy proxy = rgClient.GetProxy<IWCFCProxy>("WCFCProxy", "Ping", out errMsg);
(3) 配置消费者获取配置
ZNode node = rgClient.GetConfigItem("commSw/commImport");
备注：服务消费端和配置消费端在消费的同时已经注册了针对对应资源的监视，一旦这些服务、配置资源发生变化，消费端将能够实时感受到这些变化，具体方式就是刷新自己维护的缓存和磁盘文件，当再次消费时从缓存获取的就是最新的。当注册中心不可用时，从磁盘文件获取的也是最新的。
第三步：关闭注册中心访问实例
单例模式： RgClientFactory.Close();
非单例模式： rgClient.Close();
单例模式应该在应用程序退出时再关闭，非单例模式一定要记得每次调用完成后即要关闭。
四、 VS. TaoBao-Dubbo
1、 内外皆可复用或集成任意RPC框架
将服务提供者列表信息获取和维护模块、负载均衡模块、服务访问代理创建和维护模块分离解耦，使得内部可以加入自定义负载均衡算法，自定义RPC框架以创建服务访问代理，这样就可以服用开发团队现有的RPC框架资源。
对外仍然可以服用，可以将分布式注册中心服务访问代理获取和配置获取接口封装在现有的存在的接口中，一旦这两者失败(基本不可能)再沿用之前旧的获取方式。
2、 强大的跨语言能力
可复用现有的主流的异构平台软件资产。目前虽然只完成了C#版本的研发，但是依葫芦画瓢，其它语言平台的客户端库也很容易可以开发。
3、 服务消费者获取服务提供者信息的可靠性保障
不管是配置获取，还是服务访问代理获取。一方面提供缓存机制提升效率，另一方面提供多重保障机制，首先从缓存获取，获取失败则请求注册中心获取，同时刷新缓存和持久化存储，若还是失败则从持久化存储获取，同时刷新缓存，若还是失败则沿用以前的获取方式(通常是配置文件配置)。
提供的多重获取保障机制基本不用担心客户端会因为注册中心集群的不可用而导致无法访问服务以及使用配置。
4、 友好的配置管理和服务监控界面
5、 配置管理模块
五、版权所有
所有转载权，著作权归 jiq408694711@163.com（季义钦）个人所有。
2015 –
六、下载地址
由于仍有一些小问题还未解决，所以源码下载地址可能需要推迟才能公布。
欢迎交流！