架构即代码是一种通过源代码就可以解析计算和网络架构的一种方式，然后就可以认为是任何一种软件系统。这些代码可以在源代码管理中被保存以确保可审性和再塑性，受限于测试实践和持续交付的所有准则。这是十几年前就被用在处理成长中的云计算平台的方法，也将会是日后处理计算架构的主要方式。
image
我成长于铁器时代，当任何一个新服务器应用发布，也就意味着我们会想办法让他跑在一个物理硬件上，设置那些硬件参数用来支持应用的需要，然后把应用部署到硬件上。
设置好那台硬件一般都会很费钱，也费时，一般约花费几个月。但是现在我们现在处在云时代，一个启动服务器只需要几秒，要的只是联网和信用卡。
这是一个用软件命令就可以直接开服务器（一般是虚拟机，但是可以在电脑裸机上安装），做配置的动态架构，不需用螺丝刀就可以拆卸服务器。
实践：
架构即代码是基于以下实践：
· 使用定义文件：所有配置参数都是在可执行的配置定义文件中设定的，比如外壳脚本 (Shell Script), Ansilbe Playbooks, Chef recipes 或者 Puppet manifests.在任何时间，任何人都不能登录到服务器作出即时调整。因为任何小修改都有风险把服务器变成雪花服务器，所以开发代码时候必须当做开发持久的定义代码来完成。这说明更新如果是用代码来操作会更快。幸运地是，计算机执行代码速度很快，这使他们可以快速配置上百台服务器，比人工手动键入要快很多。
· 自我记录系统和流程：从可靠度而言，比起指挥普通人去执行的文档，代码则可更精确切地贯彻执行。如果需要的话，其他的人类可读文档也可以从这串代码里生成。
· 所有事都可以做版本管理：在资源管理器中保存所有代码。这样的话，每个配置参数和每个变化都可以被记录下来用于审计，而且你可以做再塑性建设以帮助诊断问题。
· 不断测试系统和流程：测试帮助计算机在架构参数中迅速找到错误。对于任何现代软件系统，你可以为架构代码设置部署通道（Deployment pipeline），这样即使架构改变也可以实现持续交付。
· 小的改变比迭代重要：架构更新得越大，越大可能架构包含错误而且很难侦测到那个错误，特别是如果错误还会联动。小的更新使我们更容易找到错误也更容易恢复。要改变架构是，更新地约频繁，难度就越低。
· 保持服务持续可用：越来越多的系统不能承受升级或修复时的停机。像蓝绿部署（Green-Blue Deployment）和平行变化（Parallel Change）的技术就可以帮助我们在不丧失可用性的前提下做点小更新。
好处：
所有这些使我们好好地使用动态架构，可以轻松启动新的服务器或当他们被新的配置更换或负荷减少时，可以安全处置服务器。创建新的服务器像运行脚本，创造所需尽可能多的服务器实例。这是一种很好的契合Phoenix Severs（凤凰服务器）和Immutable Server（二合一服务器）的方法。
用代码设定服务器参数以为在服务器之间有一个很好的一致性。手动配置说明书可能会做出不精准的解释（更不用说错误）会配置一些微妙的不精确的参数，导致一些很难调试的棘手问题。这些难点会因为不合适的监控变得更糟，而使用代码则会使监控变得顺利。
很重要的是，使用配置代码让改变变得安全，减少应用和系统软件更新风险。一些错误可以很快发现并修复，再不行所有改变也可以回复到上次保存的配置。
使用版本控制的代码建立的架构帮你住使其变得合规和便与审计。配置里的每次改变都可以被记录，而且不容易错误地记录在案。
所有这一些的重要性都增加了，因为你需要处理更多服务器，而且当你正要把业务移到微小型服务时，发挥架构及代码的必要能力。
架构即代码技术有效地扩展到了管理服务器的大型集群，不论是在配置服务器还是制定他们如何进行交互。
原文链接：http://martinfowler.com/bliki/InfrastructureAsCode.html
网友评论