• 目录:

    2017 年终总结


    酝酿一下感情

    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节了
    明天去把钢琴的一级课给过了吧
    手办的钱是时候开始存了。。。房子和两百万的小提琴呢。。。
    啥时候能继续后来的事。。。啥时候能觉得把南音、北北买了不会吃灰。。。