如果是为下一代大型移动应用的前端UI组件工作，那么谈论加快速度和破坏东西看上去还不错。当进入服务器领域时，就没有人希望看到破坏了。业务在飞速发展，但是如果后台基础架构包含手动部署还带有硬编码配置的应用程序的话，要想满足这些变化中的需求就会变成噩梦。本文介绍五大部署技术，使得即使是小团队也能够部署灵活的，响应式技术堆栈。
容器管理系统
Docker容器在过去两年中占领了IT世界，这是有原因的。Unix chroot命令的演化，和内核命名空间以及分层文件系统的组合，容器将应用的完整依赖集合打包在一起，这样可以将代码快速部署到任何运行着兼容内核的服务器上。和硬件虚拟化不同，容器只会造成非常小的额外消耗，启动速度几乎和进程一样快。上千个容器可以运行在一个虚拟机实例里。它们使得不可变基础架构的理念成为现实，将安装和配置状态记录成声明格式，从而可以在任何时间可靠地重做。Ubuntu 16.04 LTS Canonical引入了LXD，一种更为集成的容器管理系统，将很多Docker和硬件虚拟化的优势引入到单个平台上，增强了安全性和性能。现在可以说，容器给云上软件的部署和管理方式带来了革命性的变化。
服务发现框架
容器给用户带来了灵活性，可以几乎在任何地方运行服务，但是用户仍然需要向这些服务发送请求。这意味着系统里的某个地方需要知道实现应用程序的容器在哪里运行，以及如何将流量路由到正确的地址和端口上。在RESTful的设计里，这里的需求包括基于第7层内容来路由请求。强大的开源工具，比如NGINX和 HAProxy，让用户能够快速实现自己的方案，但是手动管理路由配置很容易出错，也会阻碍灵活性。服务发现框架，比如Consul， Apache Zookeeper和mesosphere帮助将面向服务架构的发现和路由的搭建自动化，它们为服务提供了中央化的配置存储，提供了接口来声明其生命周期事件，并且提供pub或者sub模型来将这些事件通知给其他组件。
哪种方案更适用取决于你当前的代码基和所处的开发阶段。和普通代理不同，发现层涉及更多的服务和基础架构之间的合作，因此每种方案如何支持你已经在使用的语言和工具，这是影响决策的重要因素。
容器集群
如果实现了容器化和自动服务发现之后，你就会得到集群。容器集群平台意图使构建整个系统和构建容器一样能够可靠地重复。它们填补了单个容器的运行和让很多不同容器运行起来并且一起工作之间的空白，后者包括这些容器如何在特定数量的宿主机上运行，使用特定的网络规则，自动扩展参数，访问存储等等。领先的平台包括Google的Kubernetes，Amazon Elastic Container service和Docker Compose，它们采用的是略微有所不同的方案，但是目标和理念都很类似。每种方案都有优势和劣势，但是这三种方案都是可以用于生产环境的工具，并且拥有一致的目标：自动化部署技术和整个堆栈层的配置。在其中做选择时，需要重点考虑供应商和服务代码跨平台的移植性。无论使用哪种方案，都需要研究自动化工具，比如Ansible，Chef和可敬又很顽固的GNU Make，来将所有部分组合到一起，但是在这方面的努力一定会物有所值，因为能够帮助获得可持续性和可扩展性。
即时生效的API
好了，集群已经正在运行了，并且集群有可发现的服务。因此，当http请求到达集群的/awesome或者/awesomer/端点时，请求能够分发到正确的地方，并且得到响应。那么，如果终止SSL连接，并且在应用的不同版本或者不同环境间路由呢？需要一个公开的入口点来处理这样的事情，并且可以作为所有部署在其后的不同服务的网关。可以搭建一个使用SSL的负载均衡器，但是通常负载均衡器不需要处理第7层的路由。可以在LB之后搭建一个代理来完成这部分工作，但是这时就需要考虑这个组件的配置，可扩展性和故障转移。如果能够仅仅将整个API配置为云服务，并且一个命令就可以将其部署呢？Amazon的API Gateway就是这么做的，并且非常智能。甚至可以使用Swagger这样的语言描述API，然后只需上传，它就可以工作了。Google这方面还没有提供直接的竞争产品，但是他们显然不会甘于落后，而且该领域已经有Strongloop这样的独立解决方案了。
shake-n-bake网关是否适合于你的项目？在早期阶段，应该更值得投入到速度的提升以及管理上额外消耗的减少上。但是之后，会更加依赖于在你所在的使用层级里需要实际花费多少工作。