我是科蜜,20年的…

5:30左右突然惊醒,拿起手机一看有同学给我发微信说科比挂了。我大大的问号,赶快看了一下朋友圈和网易新闻,已经有人发出了国外网站正式的报道。。。心里顿时五味陈杂,一时不知道如何是好。一个陪伴了自己整个少年时代的偶像说没就没了,还是以这种意外的方式,相信好胜心那么强的他也是非常不甘心的。也许有人会说,人家这么一个超级巨星,你们这些粉丝矫情啥,人家都不认识你。确实,我的存在对他来说是无所谓的,但是他对我的意义却是不一般,我也相信他对于无数他的粉丝都有不一样的意义。

我的2019

和去年一样,本文来自自己给部门的公开信。内容经过脱敏。


2020年已经过去了快一个月。回顾2019年,真的感谢大家,总体来看,部门的全年产出是符合预期的,也获得了其他需求部门的高度好评。不仅仅支撑了微鲤看看、广告平台、用户增长等业务相关系统的快速迭代,也不断地在探索运维基础设施、前端基础设施、大数据平台、推荐系统、公共组件、技术中间件并取得了一些令人印象深刻的成果。

要求了大家做全年的总结和新的一年的规划,我自己也从工作、学习和生活三个方面来总结一下我自己的2019年。

《管理的常识》学习笔记

今年随着公司人员规模的不断扩大,自己越发意识到了管理的重要性。尤其对于技术管理者来说,程序员的思维和管理者的思维有很多地方是截然不同的,如果不做好认知的改变和思维的转变,很容易用惯性思维来做事,那么一个非常优秀的研发工程师很可能会成为一个非常不合格的管理者。所以,自己一直在寻找管理的书籍、课程来学习。其中,《管理的常识》这本书是极客邦TGO寄来的礼物,仔细阅读了一下,还是有不少启发的。

中台简谈

面对新事物,先接纳,再判断。不要轻易就否定,即使经过自己的思考后确实没啥价值,这期间的思考过程也是一种知识梳理和思维锻炼。

2019年技术圈最火的一个词非“中台”莫属了。联想到公司已经在持续做的平台化,其实会让人感到混乱。平台和中台有啥区别?有了中台,那么前台和后台又指的什么?本文是自己在调研中台概念中沉淀出来的一些思考。

数据传输之RESTful

REST,全称表现层状态转移(Representational State Transfer), 指的是资源在网络中以某种表现形式进行状态转移,是一种架构风格。其描述的是在网络中Client和Server的一种交互形式。简单来说就是用HTTP URL来定位资源,用HTTP的各种method来描述操作。其关键的三个概念如下:

  • Resource: 资源,主要指的是数据。
  • Representational:数据的表现形式,如JSON、XML、HTML等。
  • State Transfer:状态变化, 通过HTTP method来描述。

REST经常被用来规范API的设计以及数据传输的格式,可以统一给各种客户端提供接口,包括Web、iOS、Android和其他的服务。REST不需要显式的前端页面,只需要按照格式返回数据即可。符合REST风格的API称为RESTful API,符合RESTFul规范的架构称为RESTful架构。如下图所示:

如何培养解决问题的意识

解决问题其实并不是最终的目的,需要加一个修饰词成为有效地解决问题,这才是最终的目的。那么如何有效地解决问题呢?这是有一些方法论做指导的。要培养解决问题的能力,需要首先掌握这些方法论。解决问题分为三步走:识别问题、分析问题、解决问题。

使用Spring Boot快速开发

Java开发中常用的Spring现在变得越来越复杂,越来越不好上手。这一点Spring Source自己也注意到了,因此推出了Spring Boot,旨在简化使用Spring的门槛,大大降低Spring的配置工作,并且能够很容易地将应用打包为可独立运行的程序(即不依赖于第三方容器,可以独立以jar或者war包的形式运行)。其带来的开发效率的提升使得Spring Boot被看做至少近5年来Spring乃至整个Java社区最有影响力的项目之一,也被人看作是Java EE开发的颠覆者。另一方面来说,Spring Boot也顺应了现在微服务(MicroServices)的理念,可以用来构建基于Spring框架的可独立部署应用程序。

Java开发框架之日志

日志在应用开发中是一个非常关键的部分。有经验的工程师能够凭借以往的经验判断出哪里该打印日志、该以何种级别打印日志。这样就能够在线上发生问题的时候快速定位并解决问题,极大的减少应用的运维成本。

微服务杂谈

这几年在Java工程师招聘时,会看到很多人的简历都写着使用了Spring Cloud做微服务实现,使用Docker做自动化部署,并且也会把这些做为自己的亮点。而比较有趣的这其中以小公司出来的人为绝大多数,大的公司出来的人简历上倒是很少提这些东西。

对于我自己来说,从15年就开始关注这一块,看过马丁.福勒最开始的关于微服务的论文、也看过不少对微服务的论证的英文文章和书,也研究过Spring Cloud、Sofa等开源实现以及Service mesh。考虑到我们公司研发团队人力不足、基础设施不完善,当初是没有推行微服务的。但随着看到上述的那种简历越来越多,有时候我也会疑问:难道真的不用微服务就落后了吗?公司的同事如果不掌握这些就真的没有竞争力了吗。而随着最近公司业务的逐步提升,研发人员越来越多,借着在梳理公司的微服务落地计划时,也梳理了一下微服务的相关知识点,也是本文的主要内容。

开篇之前先声明我对微服务的几点态度:

  1. 架构模式有很多,微服务不是唯一的选择也不是什么银弹。国内绝大多数中小公司引入微服务都是在盲目追新,也能看出做此种技术选型的工程师基础架构素质的不足。
  2. “你必须长的足够高才能使用微服务”。微服务基础设施,尤其是容器技术、自动化部署、自动化测试这些不完备,微服务形同虚设,不会带来什么质的提升。
  3. 微服务架构的关键不在于具体的实现,而在于如何合理地划分服务边界以及组织架构是否相匹配。不考虑研发团队的规模和组成就盲目上微服务是不良的技术选型。
  4. Spring Boot是Spring全家桶的上层封装,并不是什么崭新的技术,也不是什么值得觉得成为自己杀手锏的技术。
  5. Spring Cloud中Spring Cloud Netflix的组件是经过生产环境验证的,其他的则建议慎重选择。