• 目录:

    2017 年终总结

    创建于: 2017-12-31 最近更新: 2018-01-01 分类: 杂谈 

    酝酿一下感情

    2017…刚开始的时候…

    年后上班的前几天是比较闲的，那两天完善了下春节期间写的 WeMQ 的代码…
    这个新工作的一大好处，就是啥都没有，啥都可以自己搞。WeMQ 就是今年搞事情的开始:

    1. 我想要能通过主题模式收发 mq
    2. 想要类似 qmq 的语法

    就这两个目的，在老大那肯定是说不过去的。因为没有体现出对公司的价值，只是在满足个人的快感（实际上是有价值的，只不过那个时候的自己，表达不出来）。

    2017年的开始，还带着好几件想要做的事:

    1. 打通系统间的链路, 有一个工具能通过链路id方便的查询日志，把自己从技术支持中解救出来
    2. 能看到线上运行的系统的状态, 有多少异常、响应时间怎么样、请求量有多少、缓存命中率多少、sql执行时间多少、…
    3. 希望能在业务流程的关键节点发出主题模式的 mq 消息

    1、2 两件事，伴随着 WeMQ、WeLog 的正常上线，很自然的实现了。
    3 这件事，本来已经无望。机缘巧合的因为高管的一句话，铺出了条高速公路

    还有一些…计划之外的事情…

    java 工程师之路

    工具基础

    • 为了能看懂项目里的代码，学习了 java8 的 stream、lambda
    • 知道了以前从来没听说过的 mongodb、rabbitMQ、elasticsearch、grafana
    • 知道了 zk 是什么东西
    • 因为 WeMQ, 熟悉了 java 的注解和反射的运用
    • 可重复读的字节数组流
    • 时间处理上的坑: 六个月后 不等于 三个月后的三个月后
    • Lombok

    …哇…细节简直数不清

    welog

    welog 这项目可以说是 0业务复杂度的了:

    • 通过 logback 的自定义 appender 来收集日志，
      1. 不关心日志格式
      2. 不用运维一个个日志文件的配置
      3. 不觉得对代码有侵入性，反而能帮助提升日志内容的质量
    • 通过主题模式的 mq 消息，提供可自定义日志处理插件的能力。在这个地方还可以体验一把：从“流”的角度来思考处理数据。
    • 通过 LogId 能精确匹配到日志。
    • weLogKV(weLogLongs、weLogStrings、weLogBooleans) 能提供结构化的数据。同时，按类型归类字段，在代码层面上保证了 elasticsearch 能正常索引
    • 完整的 logEvent 对象在 analyzer 处被汇总，统一推到 ELK, 在实际工作中遇到需要修改推ELK的数据格式、logstash 的 tcp 连接数异常增多运维找上门 时，发挥过令人感动的作用
    • 加上 slf4j 的 MDC 里设置 traceId，完整链路信息也能在 kibana 上查询了

    7月

    7月，我们终于动手把线上的上一届团队的核心代码，换成我们的(welog 也趁机跟着一起上线)。两个星期整出了两个大故障，但是这两个大故障之后。。。hahahahahahahahahahahahahahaha

    • 原本每个月各种姿势挂好几次的服务，连续几个月故障次数都变成了0。
    • kibana 上查询日志的功能，交给技术支持团队后，开发人员干技术支持活的时间也几乎为0。
    • 监控、统计、报警，也都有了

    计算资源使用量

    多大的用户量/数据量/调用量，需要多少的计算量。有这个经验，或者是预估资源使用量的意识后，感觉一件事完整了许多。

    • 新加了一段代码，用到了redis，得给出内存使用量的数量级、每秒的请求数。
    • welog上线了，日志收集的 appender 占用了多少带宽、多少内存、cpu。

    这些经验的获得，有时候是故意的。（也算是公司的福利之一吧）

    • welog 日志收集的 appender 一开始就故意用了 http 短连接的方式来推送日志。
    • 去掉了所有数据库查询缓存。事实证明数据库毫无压力。缓存的加入反而增加了维护的成本。

    划边界、划边界、划边界、

    以电商场景为例，总结下处理简单业务需求的套路吧。

    一句话简单概括电商的核心业务，是: “用户”看到了“可购买的资源”完成了“交易”。
    所以，最粗的边界，可以按 “用户”、“资源”、“交易” 分成 3 个。对“用户”又可以划出 “登录”、“消息通知”、“收货地址”的边界。
    边界划分的结果可能每个人给出的都不一样，可行的方案有很多，但是都应该满足 数据独立 这个检验标准（不准动我的表！！！）。

    在 数据独立 的基础上，站在边界内思考应该提供给外界什么样的接口。
    一个个独立的、设计过自己接口的模块拼接组合在一起，就能 自底向上 实现完整的业务系统。

    在单个边界内思考问题，一般就只是对单个实体的增删改查了。如果这个实体的业务场景比较复杂，画出 数据流、状态机 的图，基本上就没啥问题了。

    对待产品的思维

    原本是巨排斥写前端代码的，年末却开始学起了前端。vue + uikit 基本上是最终的选型。
    有机会深入的话，下一步应该是学习css3、熟悉js的代码规范、储备类似 clipboardjs 的优秀第三方库。
    至于一个主流的前端工程应该是什么样的: 打包、路由、模块… 放到下下步吧。
    这个转变的很大一部分原因，是一直被灌输产品的思想。多出了个想要细致的考虑每一个交互，给出最好的体验的念头。

    主动推动一件事儿

    还记得毕业后刚到业务线的那半年的自己。。。要是现在的自己来带他，估计会咬牙切齿—-这世间竟有如此差劲之人！工作能力简直为0！

    现在的自己，不受控制的，就开始把自己当成负责人，主动跟相关的人沟通，试图推进事情发展。
    虽然能力有限、没发挥什么作用，但是能不受控制的硬着头皮上啊。
    不受控制的、本能的、做着那个时候最害怕的事。。。

    科学那么美

    宅男的愿望

    日语、钢琴、游戏、动漫、轮滑、小说…基本上都没实现。哈哈哈。。。好歹护照办好了
    日语课上了33节，计划进度已经到80节了
    明天去把钢琴的一级课给过了吧
    手办的钱是时候开始存了。。。房子和两百万的小提琴呢。。。
    啥时候能继续后来的事。。。啥时候能觉得把南音、北北买了不会吃灰。。。