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

发表于

这里仅从一个业务开发的角度谈谈体会，格局较低，仅做个人记录
编程语言是程序员接触和使用最多的工具
后端技术基础的深度是快速学习和适应新语言的关键

  • 基于对工作中接触过的几种编程语言及其部署架构的看法继续聊。

  • 截至目前，职业生涯五分之四的时间都是在使用Java。出于个人意愿和兴趣，以及行业的发展形势，也系统的自学了Go语言，并在个人的小项目实践。在一次意外的组织变动中，我转岗到了新团队，并开始使用Go，由于之前自己的自学基础，基本是无缝切换到新语言。可能是由于团队人员大部分是从Lua或PHP开始转Go的，在那里甚至感觉自己稍稍领先。

  • Go抽象业务比Java麻烦，代码不美观，但是它原生高并发，而且微服务下很多时候就一个后端服务，业务足够小，不需要复杂的设计模式等，并不需要像以前写大型Java应用这样做非常多的抽象，还能打二进制包，甚至还能保证一个团队所有人代码都是相同风格

  • 以下讲一些个人看法，比较乱甚至不正确，仅做个人记录

    1. 小型项目省内存
    2. 写命令行程序方便简单
    3. 现在绝大部分功能都有相应的官方库和开源库
    4. 运行无需环境依赖，直接打包成二进制可执行程序（Java现在也可以了，可能大部分业务场景下体积还较大）
    5. 支持交叉编译，不要特定平台
    6. 打包体积小（根据代码实际使用情况打包-这点是我一直苦苦寻找的）
      • Go语言中有未用代码消除和可执行文件瘦身机制。只有在程序执行路径上被调用的函数才会进入最终的可执行文件，未被调用的函数会被消除
      • Go未用代码消除与可执行文件瘦身

  • 为什么现在大多数人都会认为Java启动慢占内存呢？

    • 首先不是Java自身的原因，而是跟实际使用场景有关
    • 使用Java大多数用来做业务开发，也习惯引入很多依赖库，首当其冲就是SpringBoot等框架
    • 多数都是spring相关类、proxy/cglib，以及各种bean配置
    • 而且很多类都是在启动的时候初始化的

  • 微服务下的编程语言

    • 在K8S流行之前，Java通常是使用SpringCloud
    • 其实微服务相关技术，在K8S已经实现了
    • 无论是使用Go还是Java，目前都应该向K8S靠近
    • 还有一点，K8S本身就是用Go实现的

扩展

  • 体验Graalvm+SpringBoot+Java21构建原生程序

  • 在内存利用效率上，Go语言确实比Java做得更好，在4个不同的角度来总结

    1. Java的JIT策略比Golang的AOT策略
      • Java在运行时相比Golang多占用了一些内存。原因在于：
        • Java运行态中包含了一个完整的解释器、一个JIT编译期以及一个垃圾回收器，这会显著地增加内存。
        • Golang语言直接编译到机器码，运行态只包含机器码和一个垃圾回收器。
      • 因此Golang的运行态相对消耗内存较少。
    2. 内存分配和垃圾回收器
      • Java确实在起步占用上偏多，毕竟jvm需要更多内存做jit，默认的gc算法对内存要求偏高，但这不能代表后续占用仍然线性增长。如果目标是启动成百上千个内存需求较少的进程，那Java确实不擅长。
    3. 并发
      • 协程模型比线程模型更加节省内存。
    4. 反射
      • Golang的反射更加简单，导致框架的内存消耗Golang程序比Java程序优秀。主要是因为： Java的框架实现中大量使用反射，并使用hashmap缓存信息，这2个都是极度消耗内存的行为。 Golang的框架中也使用reflect、map。但是Golang是面向interface和值类型的，这导致Golang的反射模型要比Java的反射模型简单非常多，反射过程要产生的对象数量也少非常多。

  • 为什么一些已经选择 Java 的公司，现在又开始考虑使用 Go？

    • 为什么要用Go重写Dubbo？
    • 相较于 Java，Go 在启动速度、编译速度、内存使用和高并发（如协程）方面都有明显优势。所以，那些已经采用 Java 的公司现在也在考虑引入 Go。但要注意的是，目前这样的公司仍然是少数。另外，一些公司并没有严格规定技术栈的选择，因此新成立的部门或新业务团队可以自由选择，而他们可能更倾向于选择 Go 作为开发语言。
    • 小结: 总的来说，无论是选择 Java 还是 Go，都是有其合理性的。一家公司同时选择这两种语言也同样合理。尽管这样的公司占比不大，但 Java 与 Go 之间的交流需求仍然存在。

发表于

  • 由于业务需要，比如歌曲，我们需要对部分歌曲开放限免的功能，而且需要限制开放限免的场景。比如这首歌在场景A免费，在场景B收费。

  • 先说正确的做法，下发另外一个字段比如free_token，通过这个字段判断业务来源，和判断是否可以免费。free_token是随着对应的场景查询时下发的，是变化的。即同一个歌曲的free_token不是唯一的。

  • 现在有另外一种情况，想对现有的业务做限免（前端业务是不认free_token的）。这时可以把歌曲id使用free_token的值来下发，后续通过歌曲id来判断是否符合限免。

    • 这样做有个前提，就是前端业务没有使用歌曲id来做唯一性的业务（因为这是歌曲id是变化的），比如收藏。所以使用这个方案，要充分测试，而且可能还有其他不兼容的场景。

发表于

很多人普遍认为，不跟人起冲突，能得到别人满意的评价，那么就一定程度上证明他高情商以及沟通能力好。
然而，这种观点真的正确吗？在某些情况下，这样做是否必要呢？

  • 先说结论，在高人才密度的公司中，基本也应该确实是这样。因为大家能相互理解，目标是做正确的事，简明扼要节约时间提升沟通效率，尊重别人及尊重自己，对有能力的人表示钦佩并愿意向他们学习。

  • 相反在低密度人才的公司或者公司领导人不开明等情况下，情况就有所不同。举例来说，如果公司内部人际关系不够平等，或者产品地位高于技术。产品需求缺乏认真性和逻辑性，技术人员只能被动接受，甚至放任不管，那么这种沟通方式就变得有问题了。技术人员默默忍受、妥协，把自己变成产品的需求完善员，即使自己的时间被浪费也不可惜。

  • 当金钱和地位给予足够时，技术人员选择妥协也可以理解。否则，那简直就是对自己的不尊重。

发表于

在工作中，大多数情况下，大家都喜欢积极跟进事情的人。但有时候，这事情你真的要跟进吗？

  • 关于这个问题，其实并不是0或1这么简单。很多时候取决于公司的工作氛围或者分工、以及你对自己的定位等情况。

  • 在工作中，在相当长的时间里，我执行力特别强的人。我的原则是事事有结论（不给别人挖坑，不让事情烂尾）。所以我会很积极的跟进事情。

  • 但渐渐的，我开始怀疑，有些事情是你需要跟进的吗？

  • 以技术人员为例。你需要把自己当项目经理那样跟进事情吗？答案是分情况。

  • 有些情况你需要跟到底，而有些情况你只需要尽你责任即可，毕竟你有更重要的事情去做，或者说你的价值不应该在这里虚耗。

以下情况可能需要你跟进

  1. 属于你自己责任范围内的事情
  2. 这个事情是你主导发起的事情，关于你绩效等
  3. 你的公司的范围就是要你做项目经理，而且你也能接受（精神损失费不够另说）
  4. 你个人有意愿通过这种方式发展自己的综合素质或人脉等等

其他情况不需要跟进到底

  1. 已经当天反馈结果并提供解决问题的方向
  2. 需求方并未声明事情的优先级，自身也未跟进（说明不重要，不要经常给别人做无用功）
  3. 技术侧不应该每件事都跟进那么深入，尽了自己的义务即可，毕竟要合理分工
  4. 关于管理人员：不能以治标不治本的方式解决问题，技术领导应该表明立场，也是以后类似问题的处理立场，而不是一味认怂服从，累死下面的兄弟，而且没啥成长，纯粹苦力活
  5. 关于自身的话语权：作为基层员工，有些事情就是推不动，这个大家都很清楚，做到及时反馈的义务即可

发表于

最近的工作原因，涉及到接口充权益的接口安全性问题，这里趁热再说说个人看法

  • 基于之前写的这篇使用回调机制提高接口安全性继续聊。上次扩展中提到是不是可以使用非对称加密，替换回调验证？目前我所负责的业务确实使用这种方式。

  • 业务中要对接多个渠道，渠道需要调业务的接口来加权益，为了安全性，目前的做法是由渠道自己生成RSA私钥，提供RSA公钥到业务这边。渠道使用私钥生成签名，业务这边则使用公钥解密验证，从而保证请求是合法的。

  • 其实这里还是有潜在漏洞，之前的文章也提到过，如何保证私钥不泄漏？虽然说保证私钥不泄漏是渠道自己的问题，但是多年的经验告诉我，大多数公司并没有很好的保存这些私钥的方法。按照我的猜想，这些私钥在公司内部会被经常拷贝发送，至少开发人员基本都有办法知道的。万一知道私钥的人后续离职了作恶呢？

  • 而我们经常对接一下小渠道，参差不齐。尽可能保证渠道的安全也是我们作为平台要积极考虑的问题。

  • 所以个人的看法，即使使用RSA保证签名的合法，还是要提供回调的能力，提供给渠道，通过二次校验保证知道私钥的人也无法直接从自己的私人客户端发起请求并成功加权益。毕竟回调的请求是到达渠道方的正式服务器，要在正式服务器上线恶意代码，靠谱的公司都有一定的限制和管控。

扩展

  • 接口一般都会分外网访问和内网访问，我们平常要注意避免只能内网访问的接口暴露给外网访问，因为大多数情况下，我们的内网接口会安全性低一点。

发表于

先来两段经典的话:

一
为众人抱薪者，不可使其冻毙于风雪；
为大众谋福利者，不可使其孤军奋战；
为自由开路者，不可使其困顿于荆棘。

二
愿中国青年都摆脱冷气，只是向上走。
不要听自暴自弃者的话。
能做事的做事，能发声的发声。
有一份光，发一份热。
就令萤火一般，也可以在黑暗里发一点光。
不必等候炬火。

  • 迫于由于现实的压迫，大家普遍焦虑，也会在工作中认怂，即使是不合理不正确负能量的等等；

  • 这些其实都能理解，不管是迫于生活压力，还是对方给得实在太多等原因；

  • 但有时，希望我们可以

    • 我们只是个打工的，有些东西不必过度较真
    • 虽是打工但也人格独立和自尊，不必唯唯诺诺
    • 有自己的时间分配和生活，不必紧盯信息，实在紧急对方会打电话
    • 不必焦虑，事事回复，根据自身情况，适当保持高姿态
    • 换位思考，容人之度，当然容人不是纵容
    • 工作时专注和高质量，不浪费自己时间

Reference

发表于

以下内容格局比较小，仅做个人记录

  • 从我个人接触过的ToB和ToC业务讲，有以下特点（当然肯定不是一定对的，毕竟业务形态实在太多，我没真正接触过的，就不提了）：

    • ToC的业务团队，一般只做若干个业务模块；不同的业务有不同的团队
    • ToB的业务团队，需要对接几乎所有业务，进而对外提供平台能力

  • 关于ToB业务的规范

    • ToB的业务，出于通用性，会制定各种规范由客户进行对接
    • 当然，所谓的规范，有时候是看哪方处于强势
    • 弱势方即使作为平台也要给客户做定制化
    • 比如一个简单的回调规范，客户不配合，需要平台这边按照他们的规范适配
    • 但同样支付宝和微信作为平台，难道要支付宝和微信去适配每个接入方？无非是谁更强势的问题。
    • 从这方面看，可以一定判断出这个公司目前的状况

发表于

怎么看待职场中的“业务壁垒”？

  • 在我的工作中，曾经发生过这样一件事：有一天我们在讨论，能不能实现一个业务通用组件，让各个业务接入，提升业务需求的开发效率等，这时候有一个同事就跟我说：‘那如果真的实现的话，那你这边的业务就啥都没了’，言外之意就是我这边“没事做了”。我给他的回答是：‘没关系，只要是有意义，有价值，对公司是正确的就行’

  • 那么？我真的那么爱公司吗？

    • 当然不是，我只是觉得应该做自己认为正确的事，顺便说一下漂亮话忽悠一下。

  • 在工作中，你们到遇到很多“业务壁垒”。通俗来讲，这个东西只有他会，或者短期内只有他能搞定。你甚至会觉得一股恶心，就是很乱很难受，并惊叹对方的忍耐力。

  • 然而，无数的事实证明了，这个世界不会因为没有谁就不行。

  • 而我的原则是：做正确的事，不制造业务壁垒；保持出色的整理学习能力，输出业务文档，让自己随时可替换，甚至寻找可以替换自己的人；不做狭义对自己有利的事，尽量做广义对公司有利的事。

  • 具体来说，可以这样阐述

    1. “业务壁垒”不是我认同的核心竞争力，甚至混乱的“业务壁垒”不是我能忍受的工作体验；
    2. 出色的整理学习能力，坚信长期主义，才是我认同的核心竞争力；
    3. 我在提升自己可替代性的同时，也是在提升自己的“不可替代性”；而有些地方，并不需要“不可替代性”的人；
    4. 提升自己可替代性，其实也是在保持业务的稳定；不会因个人而大受影响，甚至我因此可以放心度假，因为我会的东西，别人也可以快速学会和处理；

  • 关于“可替代性”另外补充：

    • 增加自己的安全感（休假可以找到别人）
    • 增加别人（比如上级）的安全感（万一找不到，出意外有其他人解决）
    • 个人清高，一定程度上，喜欢更高维度的不可替代性

发表于

以前刚毕业的时候，进入一个组，叫中间层，那时候还懵懵懂懂不知道想表达啥意思

  • 图来源网上，已未知出处

  • 这个组是直接给app提供接口的，主要的职能大概有以下

    • 业务适配
    • 服务聚合
    • 数据展示
    • 安全隔离

  • 聚合服务，简单的来说就是聚合底层的各个业务系统，给用户端应用提供接口

    • （直接对接用户前端的接口服务，手机app，网站，h5等用户终端）
    • BFF —— Backends for frontends（服务于前端的后端），是为了让后端API满足不同的前端使用场景，而演进出来的一种模式。
    • BFF避坑指南

  • 那么这个组有存在的必要吗？特别是现在服务内部都微服务化，很多业务服务都是直接对app提供接口的。

  • 先从表面上看看使不使用聚合层各自的特点和好处

    • 使用聚合层
      1. 前端需要对接的接口比较少，对前端来说比较友好
      2. 聚合层可以聚合底层业务的接口，相比前端直接对接，有些业务场景可以提升接口性能
      3. 能根据前端的业务场合适配和统一改动，便于快速迭代和打补丁等
      4. 可以根据前端对数据的不同使用场景，减少不必要的性能损耗
        • 如果统一接口，入参就会变得复杂，增加前端的对接成本
    • 不使用聚合层
      1. 有些业务场景，减少多一层调用，有利于提升性能
      2. 业务接口可以复用，不需要聚合层再包一层，减少开发时间
        • 前提：整个公司统一接口规范，同个接口可以复用于不同app
      3. 分散接口故障风险。一个业务故障，不会导致其他业务也故障。
        • 相对使用聚合层，聚合层的服务不可用，整个app都会受影响

  • 仔细想想，简单理解，其实使用聚合层就是水平架构，不使用就是垂直架构；根据康威定律，其实公司决定使用哪种方案，一定程度还受公司组织关系的影响。

  • 提外话：由于前后端分离的流行。聚合层服务有时候会由前端团队来维护。使用node服务用于聚合页面和后端接口，从而提升性能。相对于传统的聚合层，前端的聚合层比较轻量化，基本是无状态服务，不存储数据和加工数据，纯粹做聚合接口和页面。

扩展