服务边界不是拆得越细越好:微服务治理真正要管什么
大家好,我是Z哥。 你有没有见过这种场景? 一个后台 Job,因为运行时间长、资源消耗大,被提议单独拆一个服务。 一个商品详情页,因为要聚合商品、库存、营销、评价,也被提议单独建一个聚合服务。 App、H5、PC 三端字段不一样,于是有人说,那就每端一个 BFF。 再加上 CI 慢、部署慢、扩缩容策略不同、MQ Con
大家好,我是Z哥。 你有没有见过这种场景? 一个后台 Job,因为运行时间长、资源消耗大,被提议单独拆一个服务。 一个商品详情页,因为要聚合商品、库存、营销、评价,也被提议单独建一个聚合服务。 App、H5、PC 三端字段不一样,于是有人说,那就每端一个 BFF。 再加上 CI 慢、部署慢、扩缩容策略不同、MQ Con
大家好,我是Z哥。 最近很多团队都在聊 AI 落地,我也分享下我实践下来的一些感受和观点,供大家参考和讨论,欢迎大家在评论区一起交流下经验和心得。 与身边的朋友交流 AI 落地话题的时候,我发现一个很常见的问题是:大家容易把 AI 落地理解成「给团队配工具」。 比如给大家开通一个 AI 编程工具,做几场分享,沉淀一些
最近正在做新老系统切换的准备工作,对于新老系统的切换方案,正好最近有做一些了解和思考,在这里和大家分享一下,可能你以后也会用得到。
很多在一线做coding工作多年的程序员朋友好像对「架构」有着一股特殊的情感。
一方面是自己长期在一线的各种项目中coding,好像除了业务代码以外,「架构」就是体现在项目中用到的一些框架。而且每个项目里用到的框架好像还都差不多,都是spring、redis什么的。觉得做架构并不是什么难事。
我想,做「架构」是每个热爱技术的技术人在不断追求想进入的领域。但是很多人可能工作了很多年也没能真正参与到做架构这件事上。
如果我们的开发工作真的就如搭积木一般就好了,轮廓分明,个个分开,坏了哪块积木换掉哪块就好了。 但 […]
又有2周时间没冒泡了,最近实在没有大块的时间来写文章,就当找个理由。。。 也因为碎片化的时间多了,所以 […]
一、背景 大家应该在从事软件开发领域工作时间有一段时间之后,就开始有画图的意识,不管是懵懂的学别人还是想更 […]
一、架构的定义 所谓一千个架构师中有一千种“最好的架构”模式。 “架构”是我们这行业种一个很常见的词,表明其必 […]