在DJ的日子

时光荏苒,转眼到DJ已快三个年头,自认为这是我收获最多的一家公司,特此记之。

工作氛围

DJ整体工作节奏还是比较轻松的,基本上不加班,小团队,组织结构简单,没有多少办公室政治。

产品定位上,由于早年定位于社交招聘导致使用DJ的大部分是学生应届生,这一定位导致DJ社招相对薄弱,最终让雇主对DJ的社招可能缺乏一些认同,再加上一些垂直招聘网站lg,boss等后起之秀,DJ的处境确实不是那么乐观。

在技术架构上,除早期遗留项目,Web主框架已经全面迁移到SpringMvc。服务层采用的是基于Dubbo的微服务架构,消息组件为RocketMq,配合Worker和定时任务进行异步任务的处理。存储这一块主要是主从Mysql集群配合Redis集群作缓存,Orm为业界流行的轻量级框架ibatis,去年已经升级为Mybatis。早年基于配置文件对项目进行管理,升级维护异常麻烦,后来由基于ZK的配置管理中心接管,持续集成为Jenkins和Maven包。这就是DJ后端的技术栈,希望能给有志于来DJ的人一些参考。

完成工作

回顾这三年,印象比较深刻的工作如下:

  • lp网验证码破解
  • 邀约服务id更换
  • 基础服务拆分
  • 延时队列
  • Maven包依赖查询工具
  • 应对XSS攻击,添加CSP头
  • 搭建现金支付、订单管理架构

剩下的大部分时间都是业务开发

心得体会

第一是要遵循一定的规则。这一条相信大家都听腻了,各种规范、最佳实践等等都是在教大家遵循一定的规则,这里我就不再赘述了。我想强调的是第二点。

第二是有时候要勇于打破规则。或许是遵循规则强调的太多了,有时候都忘了打破规则。一味地遵循规则可能会给自己或他人带来大麻烦,而打破规则往往能另辟新径。举个例子,我在基础服务拆分的时候就遇到了这个问题。我们的SOA架构基于Dubbo,一个完整的服务包括api、client和service三个包,api里主要是一些model类、枚举和服务接口,client里只有一个非常轻量的consumer配置文件,service是dubbo服务的真正的提供者,这样一个工程如果依赖服务,只需要引入api和client包即可。为了降低服务之间的耦合性,以及Maven包循环依赖的可能性,api和client里不允许引用其他服务的api和client,因为B的service里有可能依赖A的client,如果A的client里可以引入B的client,B的service就引入了自身的client,这样就会报错。一个平常非常好的规则在服务拆分的时候就造成了大麻烦,比如服务A和B分别拆出来一部分服务到C,C是一个新的服务,那么如果一个工程依赖原来的A中的服务,现在挪到C中了,那么工程就需要将C的api和client包引进来,如果拆出来服务很多,这势必会给原来服务的使用者造成很大的麻烦,因为他需要pom文件加入很多新的api和client依赖,这个时候就要变通一下,打破这种规则,这样对原来服务的使用者就完全透明了。在工程上这通常称为“白名单”。

第三是要有主人翁心态。现在经常可以在职位要求中有那么一些词:“良好的沟通技能”、“自驱动”、“责任心”等等,其实本质上是一种主人翁心态的养成,上面那些词都是这种心态的外在表现。一个简单的道理,你给别人干活不愿意干,给自己干有不愿意干的吗?给自己干你会不自驱动吗,会没有责任心吗?说了那么多,那如何养成呢?首先从个人要抛弃“我给公司打工,干好干差反正都不是我的,差不多得了”这种心态,这可不是给你灌鸡汤啊,有人可能会说凭什么呀,凭长远来看这对你自己是一种提升,比如你干一个活你自认为达到了70分,如果要达到80甚至90分,你可能就要开动脑筋费一些精力,这个过程中你可能会学到一些以前没有接触的东西,很明显你的能力提升了。但是如果你坚持上面的那种心态得过且过,虽然暂时轻松了,但错过了提升自己的机会;另一方面公司要从文化上进行引导,还要建立合理的奖惩机制,毕竟“名利”总得有一样吧,大家都是现实的人。

第四是无论自己干活还是安排别人干活一定要有明确的时间节点。这话什么意思呢?比如在生活中我们经常和朋友说这话的话:“找个时间大家聚一下啊”,这种多半聚不成,因为没有明确的时间地点。在生活中这么说还有情可原,在工作中这么说就会造成大家不知道往哪里使劲。有时候不形成书面的时间点,光是在心里那么一想有时候都大有改观。比如当初学习Coursera上的机器学习课程,也没啥计划,刚开始挺好一周学完一节,最后虎头蛇尾不了了之。上年又准备拿起来,当时正好快放假了,定的目标是放假前学完,最终只用了18天(2018.12.30-2019.1.17)。

第五是勿以“量变”而不做。有时候对于一个问题暂时没有从本质上解决它的办法,这个时候难道什么也不做了吗?不是,其实你可以做一些工作从量上对它进行改变。比如支付这一块当时技术调研,如果引入分布式事务对现有架构冲击较大,而且无论是两阶段提交还是Try-Commit-Cancel这种模式都无法100%保证事务一致性,最终做了妥协,采用消息、定时任务以及人工来保证支付数据的最终一致性。从运行到现在的结果来看,数据不一致的情况非常少,有的话大部分情况下消息和定时任务可以自动处理,只有极少数才需要人工参与。这就是一个只在“量”上解决问题的例子。

第六是当你觉得比较舒适甚至懒散的时候就该到新的环境中去了。记得以前换工作面试官经常问的一个问题是为啥要离职,当时都会说想学习一些新的东西。后来转念一想,你想学习新东西老的公司也可以啊。实际上,无论在哪里,如果你想学,新东西总会有。真正想到一个新环境中去是因为老的环境已经挺熟悉了,什么都见怪不怪,什么都习惯了,到达了一个比较舒服的状态,也就是俗话中的有点“皮”了。有人说我不会,无论在一个环境中待多久我都是一种处子的心态,好我敬你是条汉子,你牛!还有一个更重要的原因是新环境会拓宽你的视野增长你的见识。举个简单的例子,我上家公司是一个做政府项目的公司,他们的架构是公司内部打war包,分发到各地部署,你可能觉得很low,但这确实是适合他们的架构,因为政府的一些系统不允许连接外网,没法进行远程部署。假如不来DJ,我不会见识到互联网公司的一种技术架构,反过来更全面的看原来公司的架构方式。举个不恰当的例子,当你没听过原子弹的时候,你可能抱着炮弹沾沾自喜,当你听过原子弹,仅仅是知道有原子弹这回事,都足以让你做出很多改变,比如你自然而然的会想别人用原子弹我改怎么应对,我要不要造,我能不能造,如何造……等等。

最后,感谢DJ给我这样成长的机会,感谢hy、dd、wx、mg等的帮助。

原文 

https://pingao777.github.io/2019/02/13/在DJ的日子/

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 在DJ的日子

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址