分类： 架构

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

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

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

很多在一线做coding工作多年的程序员朋友好像对「架构」有着一股特殊的情感。

一方面是自己长期在一线的各种项目中coding，好像除了业务代码以外，「架构」就是体现在项目中用到的一些框架。而且每个项目里用到的框架好像还都差不多，都是spring、redis什么的。觉得做架构并不是什么难事。

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

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

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