服务边界不是拆得越细越好:微服务治理真正要管什么
大家好,我是Z哥。 你有没有见过这种场景? 一个后台 Job,因为运行时间长、资源消耗大,被提议单独拆一个服务。 一个商品详情页,因为要聚合商品、库存、营销、评价,也被提议单独建一个聚合服务。 App、H5、PC 三端字段不一样,于是有人说,那就每端一个 BFF。 再加上 CI 慢、部署慢、扩缩容策略不同、MQ Con
Get out of your comfort zone. To find the fun and playful.
大家好,我是Z哥。 你有没有见过这种场景? 一个后台 Job,因为运行时间长、资源消耗大,被提议单独拆一个服务。 一个商品详情页,因为要聚合商品、库存、营销、评价,也被提议单独建一个聚合服务。 App、H5、PC 三端字段不一样,于是有人说,那就每端一个 BFF。 再加上 CI 慢、部署慢、扩缩容策略不同、MQ Con
大家好,我是Z哥。 最近很多团队都在聊 AI 落地,我也分享下我实践下来的一些感受和观点,供大家参考和讨论,欢迎大家在评论区一起交流下经验和心得。 与身边的朋友交流 AI 落地话题的时候,我发现一个很常见的问题是:大家容易把 AI 落地理解成「给团队配工具」。 比如给大家开通一个 AI 编程工具,做几场分享,沉淀一些
我们总是在感叹“时间不够啊”、“来不及了”、“我太忙了”。
作为一位程序员,我们可以以代码视角来理解我们与时间的关系。
当流量瞬时激增时,API会出现大量 HttpCode 为 503 的错误。与此同时,发现另一个错误 `responses.go:69 write response failed, error: context canceled` 与该错误具有很强的相关性。
熔断是一种通用能力,可以在服务端做也可以在客户端做。我们的项目中大多数都基于 go-zero 框架实现,而使用 go-zero 框架实现的项目自带服务端熔断能力,所以本文的目的是阐述如何在客户端侧实现熔断机制。
最近在想一个问题,为什么大多数软件开发的工作都深陷在“吃力不讨好”的困境中。为什么这么说呢?因为我看到很多程序员小伙伴工作很辛苦,但是往往最终获得的结果或者说外部评价并不好。
前几周和团队里的「DDD」爱好者交流的时候,有人提到了一个概念叫「DCI」。我当时就想我只知道「DI」和「CI」,「DCI」又是什么鬼。
作为一个团队的Leader,对于团队的建设自然也离不开以上这些,但是不管你做什么其实都是围绕“人”在展开。因此我认为要做好团队建设,主要是做好以下四件事
在编码实现一个功能时,发现有一个逻辑如果按照全面去考虑的话需要改动很多地方,甚至可能要推翻当前已经写过的部分代码,但是呢现在实际场景并没那么多,当前的实现已经能满足。算了,先这样吧,后续业务怎么发展还不知道呢,到时候再说。
《数学之美》这本书买来在书架上放了很长时间了,一直没看。虽然在很多地方看到有人推荐它,但是我认为这本书毕竟还是属于工具类的,对于我之前来说用处不大,所以没有动力马上看。