程序员应该如何自我驱动，迅速获得成长？

已经一个月没有写增删改查了，我就有机会开始搞一些事情了。那个时候，我请我的领导去说动技术部使用Dubbo，因为它能做服务自动发现，免配置扩容服务，是一个挺流行的RPC框架。但是由于当时我们没有技术权限，这个事情是很难推动的，一切以稳定为主。

我使用过Dubbo，但是我一直不理解的是，为什么Dubbo使用了ZooKeeper就能自动扩容？就能服务自动发现？这个肯定和ZooKeeper有关系。由于我是刨根问底型的开发，因此我开始在周末时间和晚上和上下班路上自己学习ZooKeeper,什么顺序节点，永久节点，临时节点，什么树形存储，动态监听和通知。

终于，我就在没有看Dubbo源码的情况下突然恍然大悟：Dubbo的服务提供者和服务消费者都配置了服务name,如果我在ZooKeeper的一个name节点下存储服务路径集合，那么每次新增服务或者下线服务都会通知到任何监听这个name的客户端？（后来知道这叫做namespace命名服务），Dubbo肯定是使用了Zookeeper的命名服务来实现服务的动态发现的！

大部分程序员使用HttpClient都是使用的一个叫HttpHelper的工具类，我的改造就开始从HttpHelper这个工具类开始吧，让程序员传递自己的服务的ip,port,se rviceName,destinctName,zookeeperUrl，然后我在工具类里封装了获取调用路径列表，并封装了两个负载均衡算法：ip_hash,随机数。（其实我只会写这两种）。

在公司的四次迭代里，他们在一边飞速业务开发，一边逐渐把自己的HttpHelper工具类替换给我写的这个，终于可以卸下slb，实现简单的HTTP服务动态发现了。

当时的反对声音其实还是挺大的，不过运维的需求呼声更高，配置URL太麻烦了！

那个时候，公司架构重组，得领导赏识，我被重新划分到了技术部，做了基础平台研发部门的Team Leader，管理几个程序员。

痛点二：缺乏配置中心

解决了第一个痛点以后，我一边写增删改查，一边又想解决第二个痛点：配置问题。

之前每次部署程序到线上时，每次都要一个服务器一个服务器的改配置，我就想，我把我的时间浪费在这种一个服务器一个服务器改配置的事情上，真的是不甘心。

而且这么改配置，还容易出错。虽然公司没有主动要求写什么。（公司的主要眼睛还是放在了实现功能和业务上）那个时候加班没有那么狠了，程序员写完增删改查就回家了，我还在想配置中心怎么实现。那个时候微服务的概念火热，我了解到了Spring-cloud-config。知道有叫做配置中心的这种东东，对，我们也需要配置中心，把配置集中抽出来管理。由于我已经掌握了ZooKeeper，自然知道了做配置中心的思路。

半个月时间我就写完了，时间主要浪费在了写页面上。（汗，作为一个后台程序员我承认我的页面能力比较差）当然，这期间也经过了一些改版。我竟然不知道ZooKeeper有Curator这么好用的客户端，之前一直使用的原生的org.apache.zookeeper这个原生客户端操作，监听消费以后还要重新监听。

配置中心写完以后，我也在一个周末发到了群里，并推广了出去。这次，由于公司的人员团结力已经大有改观，而且我也已经是组内Team Leader，先在组内普及了。

而且我这次组外的游说和推广也没有那么困难了，最终也都一个服务一个服务的落地了配置中心，并实现了一处改动，处处生效，也实现了传说中的配置热更新。这些，并没有什么高深的技术，仅仅就是依赖了一个ZooKeeper。

弄完这些，我已经感受到了做技术的乐趣，同时，我的领导也觉得好像让我写增删改查有点浪费，要求我把我手头的任务全部分给组员，自己则是去解决别人的问题......我赢得了更多的时间去自我驱动，改善公司的基础设置。

痛点三：缺乏缓存框架

（编辑：成都站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!