副标题[/!--empirenews.page--]
9月15日技术沙龙 | 如何将智能化和运维工作相结合，实现智能运维！
初入公司，从CRUD到运维支持
一年之前，我还是一个只会CRUD的普通程序员，常年与业务打交道，一套花式SSM框架三板斧从头玩到底。
我入职了一个初创型的互联网项目团队，在迅速融入工作环境以后，我就开始上手写起了CRUD代码。虽然不知道底层原理， 但是SSM模版代码已经烂熟于心，再加上有一些在以前工作时学习到的基础和避坑的经验，比如空值验证，防止重复提交等， 让我能够比较快地完成业务代码。
领导看到了这一点，把我安排到了运维支持部，开始让我干一些运维的活（公司在初创期用人是有这个特点）。 那个时候，开始逐个上线一个一个的服务。这是我从零开始了解公司技术现状的开端，也是一个加班到死的开端。其实加班的原因我是非常理解的，这个和公司的技术现状是离不开的，且听我慢慢道来。
艰难的系统部署：了解技术全貌
在一个晚上，领导拿了一份文档，列了一系列要上线的服务和服务要部署在的服务器，然后我们就逐渐开干了。
新服务器都是极为纯净的，连一些基础命令都没有，只好慢慢学，慢慢装。yum install xxxx，run xxx , ps aux|grep,telnet ....，一天过去了，什么jdk，tomcat，全都装好了。
（ps. 做运维这段时间最大的收获就是linux命令玩得很熟练。）
把服务部署后，启动时就遇上了难题：以前的服务是打war包放到tomcat的，但是现在的服务，需要java -jar 来启动。 尝试了可以后台启动的nohup java -jar ， 直接翻车。 无奈去询问之前的开发，人家说得用screen 命令后台启动程序。我是一个刨根问底的人，后来发现，开发在为了保持进程不退出，错误的使用了监听控制台事件的方式，导致了nohup启动异常。
那个时候，正在搞核心业务开发的人因为一直忙于开发和调试，和我们的沟通少之又少；而负责部署的我们，又不了解业务，有些问题当时的开发也懒得详细解释，于是我们只能靠猜，来部署程序。
混乱的程度可见一斑， 但这不是几个程序员所能左右的。
我在那个时候学习到的第一件事就是：在信息不足和沟通受限的时候，你要尝试学会必要的自行推理，根据已有信息的上下文来补全缺少的信息。
上线要紧，暂时就screen启动程序吧。但是程序启动以后，又遇到了更加尴尬的事情。
当时服务之间的调用方式，全部都是通过HttpClient直接调用目标服务。假如，我先启动A服务，A服务依赖B服务，B服务没启动，A服务初始化时会报错。那么，到底先启动谁后启动谁成了一个棘手的问题。
我查看了每一个服务的工程配置示例，发现每一个服务的config.properties，都有一个配置为root的选项，标识该服务的发布路径，例如，用户服务，他的config.properties 会配置 root=/userservice/ ，我就知道了，调用该服务肯定是这样的http路径：http://ip:port/userservice/xxxx。config.properties中，也会有一些带有如下特征的配置 reference_user=http://ip:port/userservice/xxxx。我很自然的明白了，这肯定是配置了该服务依赖的其他服务的调用地址。因此，我就想到，我可以根据每一个服务的配置文件理顺服务之间的调用关系。
为了确保我的猜想是正确的，我用网上的工具反编译了一个工程，发现，果然原来服务之间都是通过HttpClient调用的。
然后我就画了工程依赖图，仔细抽丝剥茧的梳理出来了程序的具体的依赖关系。最后，我终于对服务的部署顺序和方式有了思路，而有些程序员，私下已经有人开始说干不下去了要离职。
怎么部署终于明白了，可是紧接着的一个尴尬的问题就是，程序都启动了，也调通了，但是领导要求负载均衡，集群化，一个服务里直接调用另外一个服务使用了HttpClient直连的方式，怎么搞负载均衡？怎么搞？怎么集群？
当时离DeadLine不远了，上线重要，于是忍痛购买了阿里云的SLB实现每一个服务的负载均衡，当时最痛苦的事情就是要理顺这种蜘蛛网式的服务调用关系，好在我之前已经画了工程依赖图，这个也就好办了。
天天加班折腾到凌晨两点，一个半月以后，终于把全部的Service部署成功，难以想象的是，我一个完全不懂业务的人，完全根据日志信息和配置关系，搭建成功的服务，居然有80%的功能正常可用，这给了我这个苦哈哈加班的程序员不小的成就感，虽然搞不定的20%的功能后来由负责这块的开发亲自去搞了（领导出面，不能敷衍了）。虽然，后面还有一些小的插曲，虽然这个应用刚开始可能全是窟窿，但好在也终于如期上线。
这一个半月，我掌握了公司的技术架构，在一些程序员以不会为理由拒绝部署kafka,nginx,zookeeper,activemq等基础设施的时候，我出手去部署，其实我也不会，但是从学怎么用，到部署完，时间也是够的，我还学习了这些技术是干什么的，不亏。
最终，我整理了公司当时的技术全貌，一些网络转发和机房架构由于保密原因不予描述（虽然我也已经掌握了），我只单纯说一下代码层面的：
一，服务与服务之间，通过RESTful风格的HTTP调用，使用了HttpClient，需要自己维护蜘蛛网一样的服务调用关系。
二，配置文件有在本地的，有在数据库的，代码里每次获取配置每次都要load本地，select数据库。（影响性能）。
三，无用的配置文件和无用代码散落在各处，给运维造成了干扰，代码有历史遗留的味道。
四，技术栈不规范，有的人外置tomcat，有的人内置tomcat，有的人用了Netty，简直就是群魔乱舞。
五，命名不规范不统一，词不达意，公司用了elastic-job作为分布式任务调度平台，elastic-job要求每一个job启动时需要指定job-name，但是，运维经常在控制台上无法根据job-name来定位到底是哪个job，比如，工程job为payServiceAllJob,在控制台上却注册为AllJob，让人摸不着头脑。
痛点一：缺乏服务的自动发现
服务上线以后，由于本身项目就是在没有规范，没有制度的情况下放肆生长出来的，因此服务上线以后还是会疯狂的加班，来弥补一个又一个补不完的窟窿。那个时候我还没有接触业务，但是也要和开发一起加班，人工值班监控。
（编辑：核心网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
