专栏名称: pc859107393
高级Java开发工程师
目录
相关文章推荐
今天看啥  ›  专栏  ›  pc859107393

普通的2020年终总结

pc859107393  · 掘金  ·  · 2021-01-18 00:20
阅读 27

普通的2020年终总结

2020年终总结

行走的java全栈

2020年已经过去,在这一年内,发生了太多事情,我不平凡的27岁!首先是疫情改变了我们每个人的生活,疫情防护成了常态,剩下的就是在病毒笼罩的生活下的工作,任何工作都是在保护好自己的情况下开展的。整体来说2020是一个不错的一年。

2020年技术上面的东西,总体来说就是把以前的一些东西归总,同时又把新的东西提炼出来。这里首先要感谢我的老铁,他给了我一个机会,然后才有了我这么多自由发挥的机会,虽然说没赚到什么钱,但是年轻人最不着急的就是赚钱,我就是单纯的想利用自己的专长来变现,所以相对应我目前更加喜欢的是继续在技术上面突破自己。

首先说说2020年做了哪些事情。

2020.02.17 加入创业公司

在这前几天,前公司的同事(以下简称铁子),经过跟我的不停的磋商,我答应加入这一家创业公司。其实在这之前,我已经通过家里人联系到xx国企,年薪也是跟现在这个公司差不多,但是创业公司和国企之间的细节问题,就不讨论。

特种设备

现公司的特种设备项目,其实整体来说,我不太喜欢这个设备,给我的感觉不太好。而且来这一家公司,该公司很多程序员都是抱着看笑话的心态来的,觉得我不能处理好他们的事情,经过一番痛苦的挣扎总算修复了这个项目的第二版本。在这中途遇上了这个项目的核心员工离职,以及助手(某个大龄程序员)离职,零零碎碎的总算修复好了(感谢铁子和大金哥,他们的无私配合我们完成了这个项目的修复)。

后续紧接着为了解决这个项目的问题,同时为了提升这个项目的稳定性,衍生了第三代产品。这个产品核心架构思路转变了。首先,以前很多业务都是在后端完成的,造成的问题就是前端所有业务是串行强同步操作,造成的后果就是后端业务偏重,且业务和架构严重耦合,无法达到设备的高可用性。为了解决这个问题,提出了新的组合架构设计模式。前端业务整合,利用嵌入式服务器作为前端核心,把前端业务全部整合到嵌入式服务器中,剩下的后端就是提供事件流程模型和消息事件同步,利用mqtt物联网通信协议达到前端设备的高可用。

这个项目最终版本中,我做出的主要贡献有:后端架构设计、设备端架构(一主多插件)设计、业务迁移模式讲解等。

翻译机

其实来这个公司,公司的主要想法还是要做在线版本的高速稳定的翻译设备,老板提到的目标也很明确,赚钱+分钱,公司不要做的太大,非核心程序员可以随时开猿节流

翻译机经历的版本变化:

  • 传统request-response模型
    • 优点:开发难度小
    • 缺点:翻译功能严重不稳定,产出质量较差
  • 全量同步websocket通信
    • 优点:架构设计较为简单
    • 缺点:翻译功能稳定性较差,反应相对较慢(比前面的快60%)
  • 分片同步webSocket通信
    • 优点:数据同步快,服务稳定提升
    • 缺点:开发成本较高,架构设计复杂
  • 分片同步webSocket通信+opus音频编码拓展+聚合翻译源
    • 优点:上一版本的所有优点继承,同时提升了网络传输稳定性,支持超多语言服务
    • 缺点:架构设计更为复杂,开发成本较高,难以横向和纵向拓展
  • 分布式异步翻译服务开放平台
    • 优点:继承了上一版本所有优点,更快的翻译服务,跨云平台的拓展能力,支持多种通信协议(mqtt、grpc、websocket、http),服务内超低延迟通信
    • 缺点:目前没有成熟稳定的开源框架,所有核心产品需要我一个人维护,需要不断地演进核心框架和架构

发发牢骚

其实到最后,也就是现阶段的产品来讲,在服务可用情况下产品的核心竞争力还是很强了,已经赶上一线智能语音识别的队列水平(甚至有所超越,比腾讯和有道的快,基本和科大持平) 。但是也就是在这种情况下,我最不愿意看到的创业公司的问题出现了。当团队中的成员都在为自身利益着想的时候,团队一些东西已经变质。同时跟老板的一些矛盾,我也清晰的认识到自身在团队管理上面的不足,以及老板对我做的事情的价值评定。同样的,我的一些想法已经和当初的初心背离,我也为自身考虑的事情更多了。

这一年,我的整体状态由无偿加班变化到斤斤计较,整体来讲,大家都有责任。同样的,我这个技术总监的位置也是名不副实,这个现状很符合老板的某些想法。很多零零碎碎的事情,让我的想法越来越偏移,计较的更多。人心鬼蜮,不外如是。

说实话,有些事情,不是说我这边多心,而是有一些事情上面,明确能清晰感受到老板这边对程序员的态度。“核心员工有灵魂的程序员我们就保留,其他的,任何时候都可以不要。”那么问题来了,谁是核心呢?还是老板说了算。可怜的打工人。

整个公司研发部门人最多的也是安卓,但是他们最喜欢挂在嘴上的一句话就是“你不懂安卓”,但是我却实实在在在他们的安卓项目上面提交了不少核心代码。而老板喜欢的某些所谓的“全能人才”,至今没有能给我帮上什么忙。

开放平台的现状

我们的智能语音开放平台,目前的现状来说混合云、多接入协议、多语言、多通道、极速响应、多服务组装等等都是满足了。

  • 核心:
    • springboot(基础整合服务,方便快速开发)
    • webFlux(反应式编程,依赖springboot,异步非阻塞服务器开发必备)
    • rsocket(提供微服务间通信,支持多种请求模式,以及服务内消息推送(不需要外部组件))
    • Project Reactor(反应式编程核心)
    • 透明路由: 应用在调用服务时,不需要知道服务对应的应用信息, Broker会完成路由
    • 核心broker,提供服务注册、服务发现、调用路由、消息推送等等
    • 多协议gateway接入

其实现在这个项目核心是依赖于 阿里巴巴alibaba-rsocket-broker,当然在这个项目上面,我结合实际业务需求研发出了 服务黏性调用以及满足黏性调用的情况下的负载均衡(官方版本的服务黏性调用没有负载均衡的效果,同时他们的版本只能在服务结束后固定链路才会发生切换),因为某些考虑,这个项目我并没有同步到公司私有仓库,而是一个人一直进行维护,也是因为我见过太多的创业公司的问题才做出的这个决定。还记得当初某个大龄程序员因为跟创业公司利益分配不均的问题产生的问题,所以我也是为了给自己留一份最低保障

这个开放平台,其实一直是我的理想,当我发现了有这种智能语音识别服务的时候,我其实想法很简单,就是在物联网的情景下,我们能满足多设备、多云服务、多协议、跨云平台的智能语音识别技术,简单一点,我希望能轻松便捷的让路灯都明白我们讲话。这件事情,是我在7月份左右一直在推,但是最终开始有进度是在9月底,然后我们的云平台弄上去第一版后,把我们翻译机设备(云管家项目)以及我们的国际视频会议系统都提供了强大的语音服务接入入口,避免了我们的sass产品整合复杂,最终提供统一的pass接入服务

总结

在2020年,我经历了零零碎的事情后,我为这个公司做了这一些事情:

  • 紧急修复项目问题,保证了特种项目的按时稳定交付
  • 提供了普通微服务的springcloud脚手架
  • 统一项目管理服务
  • 统一文档管理服务
  • 统一项目追溯平台
  • 统一云服务器策略管理(服务器策略、数据库生产测试规范和管理规范、redis服务器规范)
  • 统一后端项目管理标准
  • 调整特种设备的架构设计思想,统一特种设备的交互方式(一个设备模板,独立嵌入式服务器,物联网链接,消息事件交互模型)
  • 创新了翻译设备接入交互规则,实现了websocket单路并发
  • 推进和实现了智能语音服务开放平台,为混合服务接入和混合多端接入实现了可能
  • 实现了语音数据的并发处理缓冲区,为语音识别模型提供稳定线性的音频数据输入
  • 实现了基于短语音的各种组装整合服务(长语音实施识别、对话翻译模式等)
  • 实现了稳定的后端并发处理opus库,基于opus开源代码的C++实现,提供win、macos、linux的支持

我为自己做的一些事情:

  • 研发异步反应式微服务框架
    • 异步服务器交互
    • 响应式或反应式编程
    • 远程服务调用超低延迟(网络稳定可达情况下,1毫秒响应)
    • 私有协议微服务内通信
    • 服务黏性调用,以及黏性调用时候的负载均衡
  • 总结自身所学技术
    • Java
    • springboot
    • springcloud
    • netty
    • 反应式编程
    • 一些 C++

在这一年内,我在管理上面做的事情确实不到位,这个有很多原因,也是我刻意造成的局面。也做了一件让我伤心透顶的事情,那就是和自己谈了三年的对象分手,在深圳和另一个姑娘成了对象,感情太难。明天要和老板谈一些事情,希望2021能够更好。当然在这一年内,主要核心事情是提升异步反应式微服务框架的并发性能。

最后送大家一句话:没有什么痛苦比当下的痛苦更加痛苦,但他们都会成为过去的快乐,未来就在我们的不远处。




原文地址:访问原文地址
快照地址: 访问文章快照