当前有很多服务集群部署，但是对于我们自己开发的服务系统怎么样能够解决部署问题，对大家很麻烦和笨重.
首先，我想说对于我们国内，小公司小系统比较多。大型系统毕竟少数，向阿里云看齐的不多。其实所谓的需要集群部署，可能一般需要部署3个节点就差不多了。这么小的集群，采用企业级的大家伙是完全没有必要的。而且维护成本高，隔离不出来都很麻烦。也就是我们用了牛刀。
当然对于学习来说，了解企业级的大家伙是很有必要的，它的高大尚给我们很多空间，能够学习，能够增加饭碗的可靠。对于真实的部署却很难用到，或者说发挥其性能。说个简单例子，我们很多人都已经在使用zookeeper,但是这个真实的情况是，它是为了很大企业级的软件系统准备的，官方为了它能够支持很多很多的集群节点而不断改进，努力，但是我们普通用户哪里需要它那么强啊。虽然也在使用，但是我们就几个节点啊。它的性能根本发挥不出来。并且还得保持更新，为了那个出现的万一几率的问题。
最近空闲下来，不断给自己充电，慢慢积累了一些东西，感觉etcd是比较轻的，当然只是就眼前而言，很多组件类工具都是不断发展，最后很复杂笨重，希望它不会吧。但是etcd作为分布式K/V存储方案，具备很多基本功能，只需要自己简单组合，就能够用的很好。具体etcd是什么？有什么作用？什么原理？大家需要自己网上搜索。etcd3的监视功能，给我们的实时性带来很多优势。我感觉已经不错了。
经过上面的一段废话，让我们进入正题，很简单，看图：
我自己的服务就是服务节点1，2，3。只需要将自己的服务IP,端口注册到etcd集群中。我设计的格式是
服务系统名称/版本号/address/Leaseid作为key,值为服务的IP端口。同时每间隔一段时间（默认10s）向etcd集群刷新一次，作为心跳，告诉集群自己是活着的。太频繁我不建议，因为服务系统出现问题毕竟是少数，我们应该讲经历放在容错上。
我用java写了个例子，封装在项目etcd中的，其中的RegisterClusterServer即是服务节点注册，ClientCluster类是管理etcd集群节点的，该类会定时更新，获取etcd集群里面的所有节点地址。并且重新初始etcd集群访问客户端。ServerMonitor类则是监视新的服务节点加入和服务节点移除（异常），通过参数设置能够比较，更新文件。另外一个项目etcdmanager则是调用etcd项目，作为独立的查询系统，就是图上的独立代理。
当然另外还有一个hash一致方法的负载均衡，以供使用，项目已经上传git;这个项目只有一个类，还是来自网友的，只是测试了下，能够正常用我就没有研究了。总之，当前的一切只为小集群使用的，足够了。
好不容易休息，工作几年把自己身体整出问题了，感觉好尴尬。利用这个时间还是忍不住自己瞎捉摸了一下。希望今后有用吧，也说不定不会再弄程序了。我感觉做程序员真的累，有些时候顾不上家，而且房价一个劲涨的让人绝望。哎，发2句牢骚。希望所有程序员共勉。
HASH项目地址
https://github.com/jinyuttt/LoadBalance.git封装项目地址
https://github.com/jinyuttt/etcdregister.git