传统的企业软件，往往部署在企业内网，以服务单个企业或集团为主，具有可以估算的系统吞吐量和访问量。基于估计的性能要求，采购相应规模的服务器，然后部署应用程序。这种背景下开发的应用软件，往往对于扩容能力要求不高，适应不了通过互联网对外服务的场景。通过互联网对外服务时，客户会越来越多，而访问量可能有明显的波动性。为了满足高峰时期的访问量而部署的计算能力，在平常时期是很大的浪费。不论是企业自己的互联网业务(B2C, B2B)，还是应用软件开发商以软件即服务(SaaS)的形式提供的企业应用，都需要反思软件是否能适应这种更加动态的场景。
云计算给这种场景提供了更好的计算平台，容器云技术更使得我们可以接近实时地获取与释放计算资源；此外，云计算平台还提供了很多的支持性服务，能极大地简化基础服务的部署与维护。那么，我们如何设计应用软件服务，以发挥云平台的这些优势呢？
国外知名的云平台服务商Heroku提供了一份开发指南 the-twelve-factor-app, 从12个方面提供了建议。本文基于我对上述开发指南的理解，整理成5条建议。
把大型应用划分为服务和程序库
把大型应用按功能分解为多个服务。对于服务共用的代码，则按功能封装为程序库。这种化整为零的策略能降低大型应用开发与支持的复杂度。按服务和程序库来建立敏捷团队，进行设计、开发与交付。
每一个服务或程序库都有自己独立的代码库，而不是把大型应用的所有代码都放在单一的代码库中。这样能更好地发挥代码库的修订历史管理能力，让不同的服务和程序库以不同的节奏进行开发和发布，而不至于在代码修订上互相干扰。
通常，服务或程序库会依赖其他的服务和程序库，应该通过依赖管理工具，详细而准确地描述依赖关系，避免依赖库的版本引起的问题。
敏捷方法能尽早交付最有价值的服务，然后持续地交付改进和新功能。这种增量的交付方法意味着时常会发布新代码。为了避免新代码中的缺陷对生产环境稳定性影响的风险，应该建立多个执行环境。比如，开发人员的开发和测试环境，集成测试环境，准生产环境（或预备生产环境）和(正式)生产环境。
不同执行环境中，服务器的IP地址、名字是不同的；数据库、消息服务器等的方法URL和账号也是不同的。这些环境上的差异，应该通过配置项体现出来，而不是使用条件语句写入到代码中。配置项可以用系统环境变量来表示，也可以用配置文件来保存。如果使用配置文件，要特别注意，服务的代码库中只能保存示例配置文件，不能保存任何具体执行环境的配置信息，以免造成信息泄露，影响系统安全。
遵循“构建、发布版本、运行”三阶段的流程，将服务发布到这些执行环境中去。“构建”是基于代码库的某一次提交来将服务的代码文件（包括依赖库）打包；“发布版本”是将代码文件包和相应执行环境的配置打包；“运行”是在某执行环境启动服务进程。不应该在运行环境中手动修改代码或配置，以免丢失。构建包和发布版本包都应该使用版本号进行标记，并使用配置管理工具自动管理。
为了避免基础软件环境，比如操作系统、开发语言版本、数据库版本等不一致造成的问题，应该尽量让开发、测试与生产等环境保持一致。由于现在大多数服务是使用Java, PHP, Python, Ruby, Nodejs等语言开发的，程序代码是通过语言虚拟机或解释器运行的，为了提高开发者工作效率，可以允许使用不同的操作系统环境。
使服务能快速启动和优雅地关闭
云平台环境中，为了响应快速波动的应用访问，我们可以通过调用云平台API，自动地管理服务执行环境的创建与销毁。
一旦执行环境准备好，服务的启动应该尽量地快。传统的以应用服务器容器为中心的架构中（比如 Java EE），需要先启动应用服务器和一些列的自带服务，再启动应用服务。整个过程太长，太慢，对于依赖较多的服务，时间是分钟级别的。在以服务为中心的架构中，理想的服务进程的启动是秒级的。
当应用的访问波峰过后，多余出来的处理能力应该优雅地关闭：不再接收新的请求，等已入列的请求完成后，停止服务进程，然后回收服务器，退还给云平台。
由于运行服务的容器（或虚拟机）数量多，且会动态地创建与释放，因此服务的运行日志不应该保存在本地磁盘，而是应该以时间序列事件流的形式发送给专门的日志处理器。运维支持人员通过日志处理平台来查看、处理、分析日志数据。
把平台支持服务看成低耦合的、可分离的资源
应用服务会依赖很多的平台服务、支持性质的服务，比如数据库、队列、缓存等。这些服务，有可能是应用开发者公司自己部署管理的，也可能是云平台提供的，还可能是第三方的服务。应用服务应该把这些支持性质的服务看成以URL访问的资源。当应用服务管理员切换资源提供者时，只需要更新配置项中URL值，应用服务代码不需要修改。这种低耦合的设计，有助于灵活选择支持服务提供者，使得应用服务商可以根据业务需要进行切换。
这要求应用服务代码使用行业标准代码库来访问这些资源，避免在代码中直接使用服务提供商的私有代码。
基于进程的服务部署
应用的服务应该以一个或多个进程的形式运行，而且任何需要保存的状态应该由后台支持服务负责，应用的服务进程对于请求者而言应该是无状态的。对服务请求者而言，不能假设下一个请求会被调度到和上一个请求同一个服务进程上进行处理。因此，会话状态不能保存到进程本地，而是应该保存到后端的数据库服务中，如 memcached, redis等。会话建立以后，服务请求者每次请求都应该带上会话ID，应用服务根据会话ID从后端支持数据库中获取会话状态。
基于进程的部署使得向外水平扩展变得很容易，只需要新增服务器、部署运行更多进程即可分担请求。对进程的管理，应该像Linux管理启动服务那样简单。
相比于传统的让服务运行于某个应用服务器容器中，网络端口由容器分配的方案，我们更倾向于以应用服务为主体来分配和使用网络端口。在应用启动时调用网络服务库，启动网络服务端口；而不是等应用服务器容器启动以后，加载应用服务模块。这种方式能从逻辑上避免共享应用服务器容器带来的冲突。如果多个服务运行于同一个应用服务器进程中，那么我们就无法以简单的进程管理方式来启动和关闭某个服务。而且，多个服务所需要加载的依赖包，在同一个进程中加载，可能存在版本冲突，使事情变得更复杂。小型化、独立化是更适应自动化服务进程管理的设计思路。
提供管理脚本执行环境
应用服务代码除了提供常规的请求处理功能以外，通常还应该提供管理脚本。这些管理员脚本一般用于执行一次性的任务，如数据库结构更新、异常数据修复，或查看服务内部状态等。
执行这些管理脚本的环境，应该与服务进程的环境相同；应该在“版本发布”后的环境中执行这些一次性任务。
