理解问题架构给持续交付带来的难题，一种方式就是举个反例。 让我们假设有一个大的web应用程序，它有许多不同的功能。

中培伟业专家龚老师在这里做了比喻，他指出，在这个应用里有一个静态网站。整个web应用部署成一个单独的Java企业版应用程序。所以，如果只是想改正一个静态网站的拼写错误，我们就需要重新构建整个网络应用，然后重新部署。

虽然这个例子看上去很蠢，有见识的读者都不会这么干，但是我还真看到过这样的反模式。作为DevOps工程师，这可能是我们要解决的真实场景。

让我们把上面这团乱麻分解一下。在想要改正拼写错误的时候发生了什么？让我们来看一看：

1．虽然知道拼写错误是哪一个，但是我们需要修改哪一个代码库呢？因为这是一个单块系统，我们需要在代码库的版本控制系统里创建一个分支。这个新分支与生产环境的代码相符。

2．新建分支并改正拼写错误。

3．用修改后的代码构建一个新的工件。赋给它一个新版本号。

4．将这个新工件部署到生产环境。

好了，乍一看并不是太坏。但是考虑一下：

变更是在整个业务系统上做的。如果我们在部署新版本的时候出了什么错，其间的每分钟都会遭受损失。我们真的那么肯定这个变更不会影响其他部分？

事实上并不只是改正了拼写错误。我们还在生成新成品的时候改变了版本号。但是改变版本号应该是安全的，对吧？你确定吗？

这里的关键是我们已经在确认变更是否安全这件事上费了相当大的精力。系统太复杂了，即使考虑微不足道的变更所带来的影响也变得相当困难。

现实中，一个变更通常要比改正拼写错误要复杂得多。所以，我们需要为所有变更考虑部署链上包括人工校验在内的所有方面。

这样一来我们就到了一个不该去的地方。

架构经验法则有一些架构法则可以帮助我们处理上文描述的恶劣情形。

想了解更多IT资讯，请访问中培伟业官网：中培伟业