本文理论上讲应当在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项目的交付工作，参与重要方案的讨论。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ |
