Brains


on summary

实习近半年了,写个总结吧

关于工作

从6月8号开始实习,到现在近半年了。回想这半年的生活过得像研一的时候,每天早晨9点起床,晚10点半回家,不过唯一值得欣慰的是每周有2天可以放松一下,而且有工资加上学校的补助,过得还是挺好的。在这里技术氛围比较浓厚,没有明显的等级观念,唯一不太好的就是大家都比较忙,很难有时间、有兴趣聊聊自己喜欢的事情,很少有机会大家一起出去聚聚,加深感情。

这半年来时间过得很快,成长的也很快,认识了很多优秀的朋友、同学,偶尔也能听到资深大牛的经验之谈,我还是很幸运的。下面总结一下自己半年的所得吧

关于职责

这半年来主要做的工作:

  • 1、docker & kubernetes的调研
  • 2、kubernetes集群 & MPI集群的运维
  • 3、公司内部一个DNN文本计算平台的前后端开发
  • 4、一个PaaS平台的后端开发

虽然很多事情都是修修补补的小事,但在这个过程中,也渐渐熟悉了软件开发的流程和运维经验,并且熟悉了内部平台的一些架构设计理念

关于运维

记得刚来的时候我做了大概2个月的运维工作,主要是关于docker & kubernetes的调研、集群搭建、稳定性测试工作,渐渐地熟悉了docker和kubernetes的使用和常见问题的处理方法。后来小组决定搭建一个高可用的kubernetes集群加进我们的平台中,在搭集群的时候遇到的坑虽然不少,学到的确实很多

  • 对kubernetes整体架构有个更清晰的认识
  • 熟悉了etcd的使用,对服务间的通信理解更上一层楼
  • 懂得了高可用的概念和解决方案

关于开发

我入职大概2个月之后才开始接触项目开发的,第一个接手的项目是一个DNN文本计算平台,通过这个平台用户可以很方便、快速的进行一次深度学习模型的训练。这个项目整体是Python开发的,感觉是因为内部人使用的,可能有些代码质量可能不太好...在这个过程中总结一下自己所得

  • 熟悉了Django开发框架
  • 熟悉了MongoDB,明白为啥这个项目选用MongoDB作为它的数据库,而不是mysql,因为这个项目需要保存很多非常复杂的配置信息,MongoDB更加适合
  • 熟悉了前端开发流程,哈哈感觉自己是个半吊子前端...学会使用ajax和jQuery
  • 理解了master -> client -> slave 三段式的架构类型

最近这段时间又处于到另一个平台的后端研发中了,这是个PaaS平台,它支撑着公司内部很多非常重要的服务。目前为这个平台所做的贡献就是一个Dashboard,它提供一个资源使用的前端页面,可以详细的查询到每个实例、服务、机器的资源使用情况,它同时也是整个平台的资源展示、监控报警、自动扩容缩容的入口。我主要做了数据采集和数据查询接口的开发,另一位同学主要负责前端展示,在另一位同事的指导下我们不断优化这个平台,目前可以做到30s内的实时查询,这个过程中也获益匪浅

  • 熟悉了Golang语言的使用
  • 熟悉了Cache的概念
  • 实际的参与到一个软件的开发和优化过程

关于上线

来这么久了,也上线了很多次了,到目前为止一共出现了2次比较严重的事故。第一个是关于DNN文本计算平台的,第二个就是Dashboard,上线失败回滚的过程还是和痛苦的,得到的经验和教训就是一定要做好备份工作。无论线下环境测得多么仔细,应用到线上的时候还是有几率出问题的。在这个过程中还学会了一套比较安全的项目部署方式,简称双Buffer,具体过程如下:

1、有两套完全一样的后端环境A和B,它们连接同一个数据库
2、上线时先把A升级了,前端切到后端A,然后测试一下是否符合预期
3、如果一切Ok的话再升级B后端,保证A和B一致性
4、如果A升级后发现问题需要回滚,那么前端直接切到B后端,这样可以大大减少上线失败的影响

还有一种上线方式是小流量上线,应用比较广泛。假如一个组件或者服务有多个实例,那么先升级一部分实例,测试升级后的这部分实例是否符合预期,如果OK的话就全部升级,如果不符合预期的话可以大大减弱上线失败的影响的

关于微服务架构

微服务应该是目前比较火的概念吧,主要思想是把程序中的一些组件、模块抽离出来做成一个服务的形式,而不是传统那样的lib库。至于微服务化的好处,我所理解的有以下几点:

减少代码冗余

举个常见的例子吧,像很多项目中都会用到与数据库打交道的DAO,每个模块间可能都会跟数据库打交道,比如查询、更新等,那么就需要把这些DAO分发给不同的模块,这样就造成代码的冗余。假说说我们的DAO规范变了,如果项目多的话修改起来还是很麻烦的。

而微服务架构的理念是可以尝试把这个DAO封装成一个服务的形式,它对外提供增删查改等接口

保证环境的一致性

在运维部署过程中,经常被运行环境搞的焦头烂额,不是少了一个环境变量就是一个库没引用。。还要就是实例升级的时候不知道每个实例代码是否一致,比如有时候在线下环境测试的好好的,到线上就出问题了。这个环境封装一般是容器做到的,在这里不得不感叹一下容器技术的出现和应用真的会大大减少运维成本

跨语言开发

这个就是个显而易见的好处啊,试想有些语言比较适合数据处理、有些语言适合通信过程处理,有些则适合并行,如果把这些功能模块做成一个服务、规范接口,这样既可以分散开发、减少代码的复杂性,又可以利用每个语言的优点

关于docker

这里还是不得不说下docker的,虽然我没有看过docker的源码,但在生成环境中运维了3个月左右时间的docker集群(kubernetes),对kubernetes集群和docker环境熟练了不少。每一次踩坑的时候,都是自己学习进步的好机会。

如果docker容器技术成熟了,或者说我们团队对docker技术非常熟悉的情况下,全面使用docker容器来进行生产环境的部署还是能带来非常大的收益的。前面也提到了docker容器技术所带来的优势,目前我开发和维护着2个项目,运维成本是非常高的,一天下来大部分时间都花在了运维上面。与人打交道、为用户解决各种疑难杂症,实际用在开发的时间还是比较少的。

如果让我说选用docker容器的理由的话,一定是可以保持环境的一致性。比如说一个项目分为好几个模块(服务),每个服务又有多个实例,每个服务间可能会共用相同的代码部分,假如说升级了其中一个服务,修改了这些共用的代码部分,其他服务也需要修改,如果改动很频繁的话,就很容易造成服务间共用的代码不一致情况,非常蛋疼的一件事。

最后

到现在为止已经整整实习半年了,有时候也会想要不要换个环境实习一下呢?多接触一些人,多接触一些项目?但想想还是放弃了这个念头,静下心来,把手中的东西做好,毕竟这边还是有很多地方值得自己学习的,想着自己要2017年年底才能毕业,还有实习近1年的时光,心都碎了。。。。想念紫色风铃声,绝不会打扰第三次了。。。

comments powered by Disqus

纸上得来终觉浅,绝知此事要躬行~