来到XD已经一年多,见证了XD整个技术体系从小到大,业务系统从简到繁的过程。经历挺多,收获也颇丰,期间既有低谷也有高潮。先后待过两个团队,也参与了不同方面的项目研发工作。思考的挺多,想做的也挺多。

关于oss

  来到XD第一个正式团队是oss。在这里,我主导完成了XD最初的仓储、客服、电小二等诸多运营管理系统的第一版。参与oss各系统的维护,前线小二的问题反馈排查。致力于将公司内部运营业务进行线上自动化整合及线下流程优化,为公司设备仓储管理、设备城市调度及设备线下推广助力。
  另一方面,在oss整个技术团队中,一直致力于整个oss产品系的架构、基础功能优化维护。在一定程度上为适应业务需求场景进行了多次局部重构,性能优化。同时,在公司确定使用spring-cloud架构体系时,主导了oss系统的微服务改造,完成资产管理、仓储管理两个服务端工程的拆分。在消费者端进行分表分库过程中,也配合其完成了oss端牵连表结构的代码改造。
  在oss团队,我遇到了挺多困难与坎坷,有克服后迈过去的也有没有迈过的。有思考有收获,算是一个很不错的成长经历。

关于XD云

  离开oss之后来到XD云,我参与apollo设备中心的研发。对apollo整体项目架构进行了优化,完善并一定程度重构了设备上行下行消息的处理逻辑。协同完成设备相关接口从其他工程剥离解耦的工作。一同思考讨论设备多集群分离,异地多活等架构方面的设计,致力于提高整个XD云的稳定性。
  同时,在设备方面。一直参与设备网络情况排查,云端稳定性维护等工作。新近负责XD新版设备云端交互定义及开发工作,期望能够针对现有设备已经存在的问题,提出并在下一代设备中得到解决。为XD 18年量产设备的稳定性、可靠性、易用性背书。
  在这里,我感受到了浓厚的技术氛围,大家经常为解决某个问题,提出各自的想法并为之讨论。在技术深度、技术应用场景的理解上我都有了很大的提升。

关于XD架构

  在公司技术团队推广微服务及容器化的过程中,配合架构及运维同学开展了一系列架构优化工作,完成spring-cloud配置中心的搭建。
  关于配置中心,搭建其实非常简单,前期也并没有花费太多时间。之后,随着XD k8s运维体系的运行以及配置中心的逐渐应用,也发现并提炼出一些自己的个人想法。
  首先我觉得应该理清一个概念,在于我看来,配置中心首先解决的是配置的统一管理与配置中相关隐秘信息的隔离。而只是完成这一部分的功能,当前的配置中心体系已经能够解决。其次同样重要的是配置文件在配置中心的一个管理问题,要做到配置简单、管理方便、不同环境的配置清晰分割。就目前的配置文件管理来说,单单向所有开发人员以一个git仓库的形式开放公共提交,然后将针对不同环境、同环境不同集群该如何配置以文档的方式进行约束,其实教育成本挺高的,在某种程度来说是降低了开发人员接入配置中心的积极性。
  考虑一种形式,通过可视化的页面来初始化一套统一的环境,包括k8s容器群、该套环境对应各应用配置文件、需要接入该套环境的设备编号(自动下发云端集群连接地址)、云端上行下行server连接的白名单、消息队列的topic、服务注册中心等。这是一套基础配置,该套环境各应用的配置可以选择从已有的配置clone,然后针对不同环境用作什么用途(devpre)单独修改已有配置的dbcache连接信息即可。
  每套环境都是相互完全隔离的状态,里面的应用只与同环境下的其他应用关联调用。不允许出现环境间不同应用的耦合。这样可以减少在同一套k8s环境中检查不同应用间是否注册同一个注册中心、是否都是连接在用于同一用途的dbcache上的排查时间。同时,个人认为存粹的隔离好过自由的配置,快速搭建完成一整套单独的环境在轻便自由上也不会太差。
  另外,针对XD已有spring-cloud架构体系下的注册中心、配置中心以及全链路监控中心等,可以有这么一个简单的各组件入口的整合页面,提供公共的入口。这样,在开发人员进行微服务开发时,能够更清楚公司已有的微服务架构能够为他的应用带来什么,以及需要接入哪些组件来提高业务应用的稳定性。至于为什么会有这个想法,也是针对当前公司在推行微服务的过程中,各项目组基本上各自为战,独立蒙头开发,很多已经完成的中间件平台接入域名不统一、接入率不高的现状提出的。
  两种方式,一种是在一套聚合应用下可选不同环境,然后在当前环境下进入以上的架构组件;另一种方式,每个环境独立启动一个该聚合应用,每个聚合应用管理当前环境下的微服务架构组件。同时,在微服务组件聚合页面中,也可以增加对应的接入文档以及XD微服务工程生成器。达到统一XD的微服务项目结构的目的,为业务应用移交和维护提供便利。

关于技术氛围

  随着XD业务的不断成长,XD技术体系也在慢慢经历各种考验。而如何优雅清晰的划分XD架构体系,稳定提高XD业务应用可用性。有太多可以想象、借鉴的事情可以做。一种形式,在开发过程中,如果遇到某种当前体系下无法完美解决的问题,思考是否可以通过一种功能的实现或架构的优化来彻底解决。可行性、稳定性、是否很大程度提高工作效率都初步验证通过后,那么提出人可以自行立项,邮件将想法、行动广而告之,提供项目的git仓库。感兴趣的同事都可以在不影响手头工作的情况下参与其中一起讨论,解决难题,互相学习,以merge request的形式进行代码贡献。以这种形式来催化技术氛围,让当前架构存在的问题、可以如何完善优化让大家知道。增加大家工作之余的技术讨论点,集思广益、共同进步。

关于学习

  今年一直在保持不间断的学习。在java上,jvmspring-cloud上稍有收获,在gopython等其他语言的学习上也有所感悟,同时现行普遍应用的各中间件也有进一步的了解,但遗憾的是都并不深入。在尝试学习各优秀框架的过程中,发现很多设计模式和架构思路能够很好的应用于当前的工程,这些过程和感悟其实是我今年觉得最认为高兴的地方。
  在扎实自己基本功的同时,我觉得掌握理性思考,看清事物本质的能力也很重要。凡事要有自己独特的见解,不一定表达,但要做到心中有数,这对思考问题的方式是一个考验。今年希望自己在继续扎实技术基础的同时,多看看一些关于自然、数学、人文、法学及金融的经典书籍,浅尝了解。

关于期望

  希望来年多赚点钱。


本文作者Rustic_Z, 欢迎评论、交流。
转载请务必标注出处: 2017年度总结


«Previous:   JVM监控工具使用介绍

»Next:         None.