2017年全年回顾

本文理论上讲应当在2018年Q1的时候发出来，结果出于各种原因，推迟到了现在。

个人收获

基于SpringBoot、Spring Cloud交付了多个项目，加深了对新技术的理解。
上手大数据平台，在交付项目的过程中，学习HBase、Kafka、SparkSQL的调优方法，积累了一定的运维经验。
学习架构设计的理论，在项目交付中积累经验。
学习方案分析和评估的方法，在项目中实战，进而积累经验。
通过面试官课程的学习和考试，掌握了STAR方法，作为面试官参与部门的招聘工作，在实战中积累面试工作的经验。
本年度被动转岗，进入一个全新的业务领域，在陌生的环境中，新的业务，新的角色，逐步站稳脚跟，获得周边领导和同事的认可。

全年参与的项目比较多，接触的人比较多，交流比较多，听到的新鲜事比较多，比如：

• 常年B即精神离职。
• 分工决定绩效。
• 选择大于努力。
• 人与人的差异没有那么大。
• 绩效考评的分布比例。

大事记

软件挑战大赛

从16年底一直持续至17年中，我负责的是决赛的裁判平台。
作为主要责任人，完成需求分析、架构设计、开发工作，压力比较大。后期部门接口人看我的状态不好，增加了几个同事一起投入测试和验证工作。
在研发同事的支撑下，大赛决赛当天的裁判工作顺利完成。
但是我个人的结果不太好，辛苦了半年多，结果接口人对我的表现不满意，进而影响了上半年的绩效。

就技术而言，本项目中应用了很多比较新的技术，比如：

• SpringBoot
• SpringCloud
  • feign
  • zuul
  • config
  • zipkin
  • admin
• nginx
• Docker

同样遇到了一些有趣的话题，比如：

• 使用MySQL作为数据库，遇到数据目录所在分区被写满的故障，恢复的手段。
• 使用docker封装比赛环境。
• wall clock的计时准确性问题。JVM由于存在GC，导致使用Java语言的选手，需要考虑额外的补偿。
• 参赛选手使用的部分算法。
  • 蚁群算法
  • 网络流算法
  • 模拟退火算法
  • 遗传算法

这件事情耗费了很大一块精力，中间有很多故事，本来想详细记录下来，但想想事情都过去了，就算了。

部门的新项目

从17年中持续至17年的7月底。
大赛结束之后，回归部门的新业务。
有机会尝试当时比较新颖的技术，比如SpringBoot、SpringCloud、AngularJS、Docker、nginx、angularJS等。
只可惜设计团队的胃口有点大，同时外部形势不明确，导致需求、方案不太稳定。另外涉及的技术点比较多，开发团队的积累不足，从而导致加班很多，但可惜项目的结果不太好。

SDN产品

XX产品线被解散，于是在领导的运作下，我和几个同事被提前输出到SDN产品团队，期望占据好一些的位置。这个变动并不意外，在参与原部门的新业务时，周边不时传一些小道消息，只是苦于位置太低，得到的消息都是碎片化的。
既来之，则安之。
输出到新的产品团队后，面对陌生的领导、工作方式，以及全新的业务，内心充满了忐忑。
好在几个小伙伴同心协力，一起努力，完成了换岗后的第一次大考，大家都通过了考验。

很快，我接手了性能特性DE的工作，直面老大难特性的毒打。
老大难特性基于大数据平台的如下组件实现：

• Spark
• Kafka
• HBase
• Zookeeper

关键业务流程
说起来并不复杂，简单总结如下：

• 设备端
  • 使用protobuf编码统计数据。
  • 使用统计信道上报数据。
• SDN服务端
  • 适配器在统计信道接收数据。
  • 适配器基于业务规则校验，重新编码后将数据写入Kafka。
• SDN服务端统计业务
  • 基于Spark实现的流式计算任务，提交至大数据平台运行。
  • 流式任务。
    • 从Kafka中提取数据。
    • 基于SparkSQL执行汇总统计。
    • 汇总结果写入HBase的数据表，时序表。
• 查询服务
  • 应用服务器，按照一定条件从HBase的数据表中提取原始数据。
  • 依据业务规则加工原始数据。
  • 返回处理结果，供界面呈现。

老大难特性存在的问题

• 统计数据的流式任务
  • 任务故障，导致跌零。
  • 统计数据不准确。
  • 可靠性不足，节点故障时可能导致任务整体挂掉。
• 查询服务
  • 不合理的查询方式。
  • 查询超时。
  • 多用户并发查询，体验差。
  • 数据处理策略实现不正确，比如手写的排序算法，存在很多错误。

设计类的问题

• 基于HBase表的存储
  • Key过长。
  • Key的设计，不满足查询要求。
  • 写入数据时，相关操作未做调优。
• 查询服务
  • 缺少缓存层，考虑到短时间内、相同条件的查询条件，查询结果不变，相关数据如果放在缓存内，可以有效减少对HBase表的查询操作，缩短查询路径，改善操作体验。
  • 查询操作的实现不合理，未充分利用HBase的特性以及对应业务的特点。
• 统计结果预期占用空间，不清楚。

主要的优化手段

• 业务方案的优化。
  • 裁剪掉不必要的业务。
  • 聚焦业务，调整统计图表的呈现顺序。
    • 非关键的数据图表放到次级页面。
    • 关键的数据图表的数据，预置到缓存中。
• 大数据组件的基本参数的优化方案。
  • JVM的GC算法及参数。
  • JVM的内存参数。
  • JVM的CPU、内存资源的评估方案。
• Kafka
  • topic是确定的，优化partition的数量。
  • 优化数据在partition的分布策略，改善流式任务加载数据的成本。
• SparkSQL的SQL优化方案。
• HBase的数据表占用空间的评估方案。
• 向HBase的数据表写入数据的优化方案。
• 界面查询体验的优化方案，包括：
  • 从HBase的数据表读出数据的优化方案。
  • 数据加工的优化方案。

主要的成果

• 作为大数据技术的带头人，支撑开发团队定位、修复问题。
• 作为产品的接口人，和大数据团队沟通，澄清问题，获取技术支持。
• 支持测试团队，参与疑难问题的攻关。
• 支撑一线团队，顺利通过客户侧的POC测试。
• 完善特性的性能方案评估方案。
• 作为特性的方案设计责任人
  • 看护设计方案，识别方案中存在的问题，并给出解决方案。
  • 与周边特性的设计责任人对接，及时识别方案变动点，并推动在版本中落地。
  • 支撑解决方案SE，澄清特性的各类细节问题。
• 作为产品团队的接口人，参与B项目的交付工作，参与重要方案的讨论。