发表于

表结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
CREATE TABLE `user_balance` (
`user_id` varchar(128) NOT NULL DEFAULT '' COMMENT '用户ID',
`coin` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT '余额',
`create_time` datetime DEFAULT NULL COMMENT '创建时间',
`update_time` datetime DEFAULT NULL COMMENT '更新时间',
PRIMARY KEY (`user_id`),
KEY `idx_updatetime` (`update_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='账户余额表';


CREATE TABLE `user_balance_log` (
`log_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '流水id',
`order_id` varchar(128) NOT NULL DEFAULT '' COMMENT '业务订单ID',
`user_id` varchar(128) NOT NULL DEFAULT '' COMMENT '用户ID',
`type` tinyint(4) NOT NULL DEFAULT '0' COMMENT '1：加，2：减',
`coin` bigint(20) NOT NULL DEFAULT '0' COMMENT '变更金额',
`coin_after` bigint(20) NOT NULL DEFAULT '0' COMMENT '变更后的金额',
`create_time` datetime DEFAULT NULL COMMENT '创建时间',
PRIMARY KEY (`log_id`),
KEY `idx_createtime` (`create_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='账户余额表流水表';

INSERT INTO `user_balance`(`user_id`, `coin`, `create_time`, `update_time`) VALUES ('kxw', 20000000, '2024-10-23 00:00:00', '2024-10-23 00:00:00');

UPDATE `user_balance` SET `coin`= `coin` - 1000 WHERE `user_id` = 'kxw' AND `coin` >= 1000;

操作用户余额时注意

  1. 可重复读（记录扣费后余额快照）(select coin 后记录到user_balance_log表的coin_after)
  2. 乐观锁（扣费冲突）（set coin - 1000 where coin >= 1000）
  3. 业务幂等（不同业务使用相应的订单表）
  4. 事务（用户余额表user_balance、日志流水表user_balance_log、业务订单表绑定）
  5. canal 监听 binlog 识别业务异常 (对比 binlog监听的user_balance表coin变化量 和 user_balance_log的 coin记录总量 是否一致)

流水表只需要记录coin_after

事务过程

事务1 事务2
BEGIN;
BEGIN;
SELECT * FROM user_balance WHERE user_id = ‘kxw’; (coin=20000000)
UPDATE user_balance SET coin= coin - 1000 WHERE user_id = ‘kxw’ AND coin >= 1000;
SELECT * FROM user_balance WHERE user_id = ‘kxw’; (coin=20000000)
UPDATE user_balance SET coin= coin - 1000 WHERE user_id = ‘kxw’ AND coin >= 1000;
SELECT * FROM user_balance WHERE user_id = ‘kxw’; (coin=19999000)
COMMIT;
SELECT * FROM user_balance WHERE user_id = ‘kxw’; (coin=19998000)
COMMIT;
  • 流水表只需要记录coin_after（变更后的余额）即可，因为变更前的余额，可能因为并发导致不准确，除非开启事务后，使用select for update来查询，而不是用普通的快照读

发表于

  • 经历了一次大家普遍觉得“没考好”的高考后，我补录进入了广州一家末流的一本学校。出身于广东四五线城市的普通家庭，在高考前我并没有认真研究自己想要选择的专业。经过简单的网上搜索就业率后，我选择了网络工程这个专业。当时我并不认为这个专业与编程有什么关联，甚至可以说我对编程一无所知。

  • 进入大学后，习惯于自学的我感到如同置身地狱（初中和高中时期我都是习惯自己看书、解题，几乎很少主动向老师请教）。现在回想起来，这种极端的习惯可能是我未能进一步提升，或走了一些弯路的原因。之所以称之为“地狱难度”，是因为我真的一无所知，只知道努力却无法抓住重点。在大学里，没有明确的方向，学习的内容繁多而杂乱。

  • 另一方面，我也得为自己辩解一下。中国的大学（我没有见识过其他国家的情况）计算机专业的教育在一定程度上与社会脱节。缺乏引路人或足够的主动性和渴望，很难在未来的就业中具备足够的竞争力。当然，那时的网络没有现在这么发达，优质的教程较为匮乏。因此，我始终相信年轻人会越来越聪明，只要愿意学习，网络上有很多免费的优质资源，能够帮助我们少走很多弯路。毕竟，站在巨人的肩膀上学习，可以大大提高效率，节约时间。

毕业进入第一家公司 V

时长：两年
社会经验尚浅，没有好好体会和感受就离开了。
个人成长：业务和技术启蒙，基本开发技术和业务流程的熟悉与掌握，大公司职场的适应。

  • 我首先要感谢三个人：飞哥、龙哥和强哥。

  • 飞哥是我关系最好的同事，我们在工作中配合默契，工作之外也相处得非常融洽。他曾告诉我：“我不是来工作的，我是来交朋友的。”随着年龄的增长，我越来越认同，对于绝大多数人来说，人脉确实非常重要。

  • 龙哥回想起来应该是我当时工作中的业务小组长。由于刚参加工作，我对这个角色并没有太多概念，我们平常就像普通同事那样相处。龙哥像大哥一样指导我解决工作中的问题，也会和我讨论业务和技术，推荐阅读技术书籍，鼓励我相信自己的学习能力，多读英文书，获取一手资料。工作之外，我们也常常开玩笑，偶尔一起出去吃下午茶。

  • 强哥是我遇到的技术能力最强的同事，思维敏捷、动手能力出众。我现在的许多工作习惯都是向他学习的。强哥当时负责组内的基础建设，算是技术含量最高的小组。我后来主动去学习，并自然地加入了这个小组。虽然强哥有时显得严肃，但可能是对某些事情无法忍受。聪明的人有时会觉得与不太聪明的人共事很困难，因此难免会有些暴躁，现在我偶尔也能体会到这种感觉。与强哥的故事并未结束，后来我还跟着他一起创业了一段时间。

  • 在这里，我交到了最多的朋友，大家都非常友好。

第二家公司 U

时长：一年三个月
技术基础较好的公司，但气氛却比较压抑，难以适应。
个人成长：学习能力和方法，技术基础原理的积累。

  • 在这里，我遇到了两个不错的同事，阿舜和阿君。总体来说，我与某些同事相处得较好，但总感觉有些同事特别冷漠，虽然不是故意的，似乎普遍存在社交恐惧，平常默默去食堂吃饭也不打招呼。可能是性格、职业属性、职场压力和公司文化等多方面原因，我个人的感受比较压抑。

  • 作为国内前几的大公司，里面确实汇聚了很多人才和技术沉淀，光是在内网的论坛上就能学到不少知识。

  • 此外，我在这家公司体验到了大公司内部创业的团队模式，以及组织架构调整和人员变动的经历。

第三家公司 D

时长：三个月
一家创业公司，最累但也是最开心的时光，同事相处融洽。
个人成长：技术管理者全局思考能力的培养，技术规划等经验。

  • 加入这家公司是前一家公司的强哥邀请的，他是团队的创始人之一，后来他也辞去了前公司的职务，全职加入。

  • 团队规模较小，大约十三人，其中开发人员七个，没有专门的测试人员。虽然我只在这里待了三个月就宣布解散，但还是体验到了创业公司的开放与忙碌，当然也有混乱和无奈等。团队的技术人员经验虽然较浅，但各有优点和潜力。其中阿韬是我邀请到下家公司一起共事的。

第四家公司 K

时长：六年
收入最多，但在大公司光环下却是一个相对奇葩的小作坊。在这里，我的个人能力得到了充分发挥。
个人成长：各方面能力的积累与提升，职场经验和事务处理的积累。

  • 不确定是什么原因，前期技术和业务能力的积累、个人职业能力的成熟、对职场规则的理解，还是这里人才密度不足的影响。在这里，我的职业发展如鱼得水。在六年中经历了多次组织调整和三四次换领导，我也开始带领小规模的技术团队。在这段时间，我得到了同事们不同程度的认可，六年来每年的绩效都是优秀或以上。

  • 我认为有几个因素促成了这一点：遇到优秀的领导、扎实的个人技术能力、良好的透明沟通等。最核心的窍门在于，在正确的职场价值观前提下，常常换位思考，这样基本能做出合理的选择。当然，有时在某些原则下可能会产生冲突和不愉快，或许有更好的处理方式，但我个人尚未掌握，某些方面也不想耗费额外时间，显得比较直接。另外，我的行事风格也在增加自己的“可替代性”。

  • 在这里，我结识了许多关系良好的同事，毕竟待了很多年。其中，特别提到阿拳、阿杰和阿韬。

  • 阿拳是我偶然发现的校友，比我小一届。有些人天然有种默契，眼神一对，自然而然就成了好朋友。他是一个喜欢技术挑战，渴望提升自己能力的人，但似乎在职场上的投入和专注不足，始终未能如愿。经历了换团队后，他也没有改观，最终离开了，加入了其他公司。现在看到他职业发展越来越好，生活也越来越丰富，我意识到，合适的环境和机遇对我们来说确实很重要。

  • 阿杰是我刚加入公司时的同事，后来换团队后的领导。他与之前的领导不同，比较平易近人，尽量将公司的各种政策和职场潜规则向我们说明白。尽管身处职场，他总能从一个打工人的角度保持良心。大多数情况下，我们的相处就像朋友一样。

  • 阿韬是前公司 D 的同事，他给我留下的印象最深刻的就是人际关系很好，从未见他与任何人发生冲突，平常开朗，喜欢群体活动。加入公司后，除了工作，我们私下相处的时间也最多，成为了我最好的朋友。在公司，他的评价一直很好，大家有心事都会找他倾诉，我常戏称他为“中央空调”。在这里，虽然技术能力是基础，但大多数情况下，沟通能力更为重要。

发表于

接口调用存在于内部服务之间，也存在于客户端和服务端之间
既然涉及接口调用，必然就涉及到数据的序列化

RPC

  • 什么是 RPC？
    • RPC是”远程过程调用”(Remote Procedure Call)的缩写。这是一种计算机通信协议,允许程序调用另一个地址空间(通常是在其它计算机上)的子程序或过程,而程序员就像调用本地程序一样,无需额外地为这个交互作用编程。
  • 其实 RPC 不仅可以存在于内部服务之间，前端和服务端之间的交互也可以用 RPC

序列化

  • 一般情况下，我们习惯于使用 idl 文件定义数据格式（比如 thrift 或 Protocol Buffer），然后使用 RPC（比如 gPRC 等）用于服务之间的调用；而使用 JSON 和 HTTP 作为前端和服务端的交互方式
  • 这里提一点，回看 RPC 的定义，即使使用 JSON 作为序列化协议，也可以使用 RPC 作为接口调用，具体要看 RPC 框架的实现。

使用 RPC 和 IDL文件 的好处

  • 本文只关注序列化方面相关的好处
  • 举个例子，接口调用简单使用 HTTP + JSON；如果后续加字段，而调用方使用不规范，复用接口调用的返回对象用于业务的其他逻辑，而字段名刚好相同，则会冲突从而可能导致逻辑异常，这种低级错误无论是客户端还是服务端都经常发生
  • 理论上每个接口都应该有单独的接口响应类，这样才不会在后续加字段时产生语义冲突,虽然写起来麻烦，但这是最规范最严谨的做法，所以自动化代码工具很重要
  • 其中一种解决方式：使用 IDL 文件定义数据格式，并且通过 RPC 框架限制调用的返回对象不被随意设置，从而解决这种低级又容易忽视的错误
  • 对 RPC 框架的要求：
    1. 限制返回对象不被修改
    2. 排查工具完善，支持将数据转成可阅读格式（比如使用Protobuf二进制传输，将很难排查）
    3. 适配多种语言的客户端 sdk（包括客户端）

发表于

生命是以时间为单位的，浪费别人的时间等于谋财害命；浪费自己的时间，等于慢性自杀。 - 鲁迅

  • 平常在工作中，有些同事在没有提前发会议主题和相关资料前，突然就拉一群人一起开会，方便了自己，却浪费了别人的时间。
  • 比如一些不专业的产品为了节省自己的时间，也不做充分的会前准备，拉一堆开发给自己做需求完善员，对别人的时间极其不尊重。

高效会议

  1. 能线下小部分人沟通清楚的，不必拉齐人一起开会
  2. 会前发相关资料，让潜在参与者提前了解
  3. 看完资料，可以发相关疑问，有些内容可以提前单独沟通
  4. 真正开会前发会议主题和目标
  5. 会有要有会议纪要，结论，执行人等

Reference

最近和几个大佬朋友聊天，大家不约而同的在吐槽公司开会效率低下的问题。



一提到开会，想必大家都会浮现各种场景，甚至有人可能要开始骂娘了吧？不断延长的会议时间，沉默的参会成员，语无伦次的会议组织者，不断跑偏的主题，一不小心一天就全在开会了。



what? 不仅一天全开会了，还没有任何有用的结论？



作为一个开会无数的互联网老鸟，针对高效开会，我有以下六点建议：



1.能不开会就不要开会



很多会其实根本没有开的必要，不少人平时不沟通，沟通全靠会议！



一旦开会出现几个人相互扯皮，你一句我一句的情况，基本可以断定这几个人平时就不怎么沟通，或者沟通有问题。



更为可怕的是，有些管理者，不开会就不知道自己要做什么！曾经我招过一个产品leader，热衷于组织各种会议，基本可以在会议室呆着不用出来的那种，但关键事情的推进都没落地。



具体注意点如下：

会议组织者还没完全想清楚之前，坚决不要开会

能定点沟通清楚的问题，坚决不要开会

能召集3，4个人花5分钟说清楚的事情，坚决不要开会



2.开小会，越小越好



会议人数尽量控制在7个人以内，人越多会议效率越低。有时候喊很多人开会，无非是出于显示你的权威或者逃避责任，潜台词是：反正大家都参加会议了，出了问题一起扛。



不知道大家注意过一个现象没有，不少微信群人少的时候，大家都很活跃，如果进来一些不说话的「潜水者」，大家也就慢慢都不说话了。



开会也是一个道理！如果有不太相关的人进来，他肯定会不怎么参与讨论，而其他人的思维活跃度都会受影响。



那么有人会问：如果会议就是需要很多人参与怎么办？可以将一个大的会议拆解成几个议题，分议题开小会。然后再把小会的决策者喊一起开会。



乔布斯就特别重视控制会议人数，在「疯狂的简洁」一书中记载了乔布斯一个小故事：「在一次和广告公司的例行会议上，乔布斯突然发现了一位名叫Lorrie的陌生的参会者，乔布斯指着Lorrie问到：“请问您是哪位？”，Lorrie解释自己需要听这个会议，但最后乔布斯还是礼貌的请Lorrie小姐离开了：“我不觉得你有必要参加这个会议，Lorrie小姐，谢谢。”」



我猜，Lorrie小姐估计也是暗爽的吧，毕竟她估计也是莫名其妙被拉到这个会议。



3.开会前做好充分准备



会议组织者需要把会议主题、会议背景、提前同步给所有参会人员，甚至需要提前进行答疑及相关沟通工作。



比如产品的技术评审会，不少产品经理可能没有提前发出原型做沟通。结果在会议上大家需要先理解原型，而不是上来直奔主题。



充分的准备工作，会让会议更加高效，大家坐下来开会的时候已经清楚所有信息，开门见山展开思辨，而不是一屋子人毫无准备甚至满头雾水。



4.能站着开，就别坐着开



比尔盖茨说过一句话，“当你能站着开会，就不要坐下来”。



会议室的椅子也不能用太舒服的那种，为什么？当人们坐在一个舒适且舒服的椅子上，大脑更多的时候是在放空状态，注意力无法被集中。



坐在那里舒舒服服的探讨，效率远低于站着快速解决。当站着开会，不再有人坐在办公椅上犯困想打瞌睡，不再有人玩手机看电脑。时间大大的减少，不再沉默寡言，而是速战速决。



每日的项目进度之类，特别适合10-20分钟的站会形式。站着开会，大家都不想浪费时间，自然就更能保证高节奏，高效率。



5.盯紧走神的人



开会的过程中，一般会不断有人走神。这点很考验会议组织者，如果发现有人走神，需要盯着他，看他眼睛。如果还不行，就需要提醒下拉回他的注意力。



开会应该是个激烈思辨的过程，走神是要被杜绝的。如果团队中发现开会经常走神的人，那要小心了。他要么是对业务不太了解，说不上话，要么是心灰意冷已经不想说话。「要引起重视了」



6.会后，有结论、有责任



开会过程要对关键结论做会议纪要，在会议结束后，尽早发出会议记录。会议记录可能会有遗漏和错误的地方，尽早将会议记录发给所有相关人，可以让其它参会者检查，提出问题或作出补充。



会议结束后，将任务指派给每一位责任人。这也往往是会议组织者的工作，不仅仅做出决定，更要负责落实决定的执行。如果这一步做不到位，那基本可以说这个会白开了。



最后总结几句：



开会是个大学问，千万不要小看提升的那点效率。10个人开会，浪费2小时，就相当于浪费了一个人一天的生命和一个人的工资。



工作的目标是为了创造价值，而不是摧毁价值。低效会议无疑是摧毁价值的重要帮凶！！！



浪费时间等于谋财害命，高效开会是每个会议组织者必须学会的技能。

发表于

  • 前段时间在看Rust，所有权部分涉及到很多规则，让我重新反思了传统文科和理科的区别

  • 学习一门编程语言，大家普遍会认为这是一门理科

  • 但像Rust语言的所有权规则，让我想到了英语中的各种时态规则

  • 大家基本会认为英语是文科

  • 但我其实认为Rust中的规则和英语中的规则，其实没啥区别，都是逻辑规则，比较烧脑。

  • 所以无论是学习文科还是学习理科，有些地方，都是需要良好的逻辑能力。

  • 逻辑能力好的人，基本学习文科理科都不会有太大差异。都是聪明的人。

  • 当然中理科中偏理的部分，文科中偏文的部分，这些可能有差异则另说。

发表于

  • 由于业务进程不是Java编写的，无法使用Saturn提供的Java定时任务，只能使用Shell定时任务

  • 这里选择用UDS实现Shell进程和服务进程之间的通信，实现和使用Java定时任务一样的效果

  • 在上次的实现中，只考虑了如何触发定时任务执行，并没有考虑如何停止

实现对执行中的任务进行停止

  • 通过测试可以知道，当在saturn控制台点击终止任务时，会对shell进程发出terminated信号

  • 如何不是通过saturn控制台触发，直接终端执行shell命令时，操作Crtl+C时，会对Shell进程发出interrupt信号

  • 基于上述研究，提供以下方式停止业务服务的运行中的定时任务

    1. 通过saturn控制台点击终止任务，发terminated信号
    2. 通过操作Crtl+C，发interrupt信号
    3. 通过执行shell命令，指定任务名称和-stop选项，直接发出终止任务请求

  • 具体实现参考：saturncli

扩展

  • 经过测试，saturn的调度不会因为设置的频率太快导致并发运行，只会执行完一个任务再执行下一个

发表于

几年前也做过feed流相关的服务，虽然网上相关的文章很多，这里也做个人的简要记录和总结
方案并非原创，当时是参考其他业务团队的设计

  • 需求背景：做一个用户动态模块，可以发动态，可以关注别人动态，有推荐列表，有消息提醒（其实就是微博的基本功能）

实现逻辑流程

  • 整个feed流设计都是强依赖Redis来实现的，以下列出key设计和对应的功能模块

    • 粉丝的feed流 - 【feed_list_$userId】
      • member-$id_$userId_$type （score-addtime）
    • 粉丝的feed流为空标志 - 【【feed_list_empty_$userId】】- 防止每次请求都穿透到DB
    • 用户的活跃粉丝列表 - 【active_fans_list_$userId】
    • 用户的活跃属性 - 【active_user_status_${userId}】
    • 动态详情 - 【cache.user.dynamic_${dynamicId}】 - MGet获取

  • 数据库分表设计

    • 用户动态表 - 按用户id分库
    • 评论表 - 按动态id分库（根据业务，一般都是单个动态的所有评论）
    • 点赞表 - 按用户id分库（根据业务，一般都是动态列表中展示当前用户的点赞状态）

  • feed流使用sortset，score是addtime

  • 推模式，通过维护用户的活跃粉丝列表（有数量限制），推到粉丝的feed流

  • 拉模式，通过请求第一页或其他接口进行预加载，查询粉丝的关注人和对应动态（有数量限制），构建粉丝自己feed流

01.feed流 构建 整体流程

  • 用户发动态、删动态、关注和取关事件，都会对feed流有相应操作
  • 通过发布事件的设计进行业务逻辑解耦

用户发动态（推模式）

  1. 用户发布动态（写入DB）
  2. 查询用户的活跃粉丝列表（Redis）
  3. 写入粉丝的Feed流（Redis）
  4. 写入消息表

粉丝拉关注列表（拉模式）（请求第一页或其他接口，预加载）

  1. 获取feed流（Redis）
  2. 获取关注用户列表（RPC）（限制2000个粉丝）
  3. 获取关注人的动态数据（DB）（限制没人100条动态）
  4. 写入个人的Feed流（Redis）
  5. 成为活跃用户（Redis）

02.动态消息交互

  • 消息表 和 消息读取时间表（用于控制用户红点提示和读取消息列表的范围）
  • 消息表保存7天定时清除

03.feed流预加载策略（pull模式）

  • 。。。。
  • 将用户加入为活跃粉丝

04.动态新增、删除（push模式），活跃粉丝处理

  • 用户的活跃粉丝列表逻辑
    1. 拉取过feed流或发布过动态等操作的用户，都会设置成有活跃粉丝属性的用户
    2. RPC获取用户的粉丝列表，过滤掉非活跃用户，保存到用户的活跃粉丝列表
    3. 关注和取关事件，也更新活跃粉丝列表

05.关注、取关 事件 对feed流的处理

06.获取feed流

  • 有了前面的推拉模式，用户直接从redis获取feed流即可

07.动态类型版本设计

  • 随着动态类型的新增，客户端旧版本不支持新类型动态，需要过滤；

  • 目前feed流是存在redis的，直接过滤可能会导致旧版本数据为空，可以通过多版本动态来区分

  • 实现描述

    1. 用户获取feed流，根据客户端的版本号等信息，判断出客户端支持的feed版本，并构建对应的feed流
    2. 用户发布动态，构建用户存在的活跃动态版本的feed流（为了用户的新旧版本都兼容）

扩展

  • 很久之前做的一次实验
    • 取消了微信黑名单，没看到之前的人的朋友圈。说明微信朋友圈也是feed持久化的方式实现
    • 微博也是这样，之前关注过，取关后再恢复，内容也能恢复，说明feed表只是逻辑删（应该是存数据库表了）
  • 微博feed实现（猜测）
    1. 为每个用户保存他所有关注的用户的feed表数据
    2. 假如取关，则重写关注能恢复数据（逻辑删除）
    3. 但如果之前没关注的用户，则他之前的动态不会出现在feed表中

发表于

第一次接触配置中心，是快十年前了，那时的配置中心还没像现在那么多成熟的开源项目，很多公司都需要结合自身业务自研。

使用配置中心的好处

  1. 快速发布变更配置，实时生效
  2. 对于不复杂的系统或业务配置，可以避免写繁琐的后台，但又具备快速变更的功能
  3. 读取配置性能高，一般配置后，都是以内存变量的方式常驻在服务中，可以说读取配置几乎零成本

配置中心的核心-推送原理

这里主要讲一下个人实际接触的三种原理，其实从宏观本质上看，三种方案原理是一致的

  1. 第一家公司的配置中心自研方案，借助ZooKeeper的临时节点变更事件，从而实现实时推送

  1. 第二家公司的服务治理中心的实现方案，使用Netty使服务中心和各服务之间建立TCP长链接，从而实现配置推送

  2. 第三家公司使用Apollo开源项目作为配置中心，原理是使用HTTP的Long polling方案

  • 从原理的本质上看，三者都是通过保持TCP连接不断开，从而复用这个通道进行数据推送
  • 除了推送的实现很重要之外，后台管理系统的设计和客户端的SDK也很重要。因为光能实时推送是不够的，要让接入配置中心方便，以及能方便管理和发布配置也是很关键的。在这一点上，Apollo这个开源项目是很不错的。

发表于

从事IT行业若干年，有时回首，不禁感叹，很多技术方案和日常生活息息相关，可以相互借鉴。

以下只是草稿，以后有缘再整理

以下每项并不是独立，而是相互重叠的

  • 从日常的工作中总结常用的套路，勤记录，提升后续的效率
  • 多开发一些能提高效率的小工具，逐步优化，并可以给其他同事使用
  • 抽时间回顾和总结
  • 对用户的业务数据感兴趣，并思考哪些技术优化值得做

技术追求

  • 提升自身和团队的水平、服务架构合理性和性能的考虑、提高开发效率和体验

定时任务使用UDS作为触发运行的通知方式

  • 基于架构的完全性考虑：不暴露非本机触发的机会
  • 基于架构的合理性考虑：复用已有服务的逻辑和资源，无需新开进程
  • 具体实现看：谈谈定时任务的原理和应用 - 使用域信号通知通知服务

代码质量

使用代码扫描工具

  • 比如Java的Sonar、Golang的golint等

单元测试

  • 及时发现新代码逻辑问题，以及发现避免误改动等
  • 提交代码检查并及时阻断

代码Review

  • 上面的事项自动化，比如和gitlab pipeline结合，在开发阶段就及时修正；
  • 后续代码review可以避免审核低级问题，提高效率

开发效率

脚本工具

  • 开发快速生成curl脚本的工具，便于快速定位问题，以及反馈时提供复现实例；

代码复用

通用组件抽象

  • apollo灰度工具
  • bi数据上报组件
  • 消息通知组件

业务组件抽象

  • 目前都流行微服务，但有很多上游的逻辑是可以复用的，可以抽象出来，通过代码库的方式复用

服务稳定

灰度工具

  • 为保证改动一旦出问题，降低影响，开发基于配置中心的灰度工具，可以根据业务属性进行灰度

性能优化

  • 使用wrk、pprof等工具分析优化

文档化

常规事情文档化

复杂事情文档化

发表于
  • BI的数据统计跑数结果一般是T+1生成的
  1. 实时性要求不高的功能，用于推荐等其他业务功能，可用于统计和监控等
  2. 对实时性要求高的功能，做后置的监控，及早发现逻辑错误