架构

大家好，我是Z哥。 你有没有见过这种场景？ 一个后台 Job，因为运行时间长、资源消耗大，被提议单独拆一个服务。 一个商品详情页，因为要聚合商品、库存、营销、评价，也被提议单独建一个聚合服务。 App、H5、PC 三端字段不一样，于是有人说，那就每端一个 BFF。 再加上 CI 慢、部署慢、扩缩容策略不同、MQ Con

大家好，我是Z哥。 最近很多团队都在聊 AI 落地，我也分享下我实践下来的一些感受和观点，供大家参考和讨论，欢迎大家在评论区一起交流下经验和心得。 与身边的朋友交流 AI 落地话题的时候，我发现一个很常见的问题是：大家容易把 AI 落地理解成「给团队配工具」。 比如给大家开通一个 AI 编程工具，做几场分享，沉淀一些

最近正在做新老系统切换的准备工作，对于新老系统的切换方案，正好最近有做一些了解和思考，在这里和大家分享一下，可能你以后也会用得到。

不管是十几年前 SOA 的流行，还是 7、8 年前微服务的大行其道，还是如今云原生的展露锋芒，背后都离不开一件事，程序拆分或者说服务拆分。否则，一个单体应用，以上的这些技术潮流好像都与它没什么关系，只是一个看客。

很多在一线做coding工作多年的程序员朋友好像对「架构」有着一股特殊的情感。 一方面是自己长期在一线的各种项目中coding，好像除了业务代码以外，「架构」就是体现在项目中用到的一些框架。而且每个项目里用到的框架好像还都差不多，都是spring、redis什么的。觉得做架构并不是什么难事。

我想，做「架构」是每个热爱技术的技术人在不断追求想进入的领域。但是很多人可能工作了很多年也没能真正参与到做架构这件事上。

近期这类信息被报道的频繁度进一步增加。这不，最近陆续又有一些国外公司宣布退出微服务架构的迭代路线，逐渐将一些小粒度的服务进行合并成一个更大粒度的服务，甚至还发明了一个新的名词——「宏服务（macroservices）」。其中不乏像Uber这样的体量的大公司。

我们中国有句古话，分久必合，合久必分。 很多事物的发展都逃不开这个规律。如今，这件事也正在分布式、微服务概念大行其道的软件开发领域里发生。

如果我们的开发工作真的就如搭积木一般就好了，轮廓分明，个个分开，坏了哪块积木换掉哪块就好了。 但 […]

又有2周时间没冒泡了，最近实在没有大块的时间来写文章，就当找个理由。。。 也因为碎片化的时间多了，所以 […]

一、架构的定义 所谓一千个架构师中有一千种“最好的架构”模式。 “架构”是我们这行业种一个很常见的词，表明其必 […]