Saas 应用12个架构规范( 三 )


Saas 应用12个架构规范

文章插图
 
易处理快速启动和优雅终止可最大化健壮性
12-Factor 应用的 进程 是 易处理(disposable)的,意思是说它们可以瞬间开启或停止 。这有利于快速、弹性的伸缩应用,迅速部署变化的 代码 或 配置,稳健的部署应用 。
进程应当追求 最小启动时间  。理想状态下,进程从敲下命令到真正启动并等待请求的时间应该只需很短的时间 。更少的启动时间提供了更敏捷的 发布 以及扩展过程,此外还增加了健壮性,因为进程管理器可以在授权情形下容易的将进程搬到新的物理机器上 。
另外进程 一旦接收 终止信号(SIGTERM) 就会优雅的终止  。就网络进程而言,优雅终止是指停止监听服务的端口,即拒绝所有新的请求,并继续执行当前已接收的请求,然后退出 。此类型的进程所隐含的要求是HTTP请求大多都很短(不会超过几秒钟),而在长时间轮询中,客户端在丢失连接后应该马上尝试重连;对于 worker 进程来说,优雅终止是指将当前任务退回队列 。
 开发环境与线上环境一致尽可能的保持开发,预发布,线上环境相同
开发环境(即开发人员的本地 部署)和线上环境(外部用户访问的真实部署)之间存在着很多差异 。这些差异表现在以下三个方面:
【Saas 应用12个架构规范】时间差异: 开发人员正在编写的代码可能需要几天,几周,甚至几个月才会上线 。
人员差异: 开发人员编写代码,运维人员部署代码 。
工具差异: 开发人员或许使用 Nginx,SQLite,OS X,而线上环境使用 Apache,MySQL 以及 linux 。
12-Factor 应用想要做到 持续部署 就必须缩小本地与线上差异 。 再回头看上面所描述的三个差异:
缩小时间差异:开发人员可以几小时,甚至几分钟就部署代码 。
缩小人员差异:开发人员不只要编写代码,更应该密切参与部署过程以及代码在线上的表现 。
缩小工具差异:尽量保证开发环境以及线上环境的一致性 。
将上述总结变为一个表格如下:
Saas 应用12个架构规范

文章插图
 
12-Factor 应用的开发人员应该反对在不同环境间使用不同的后端服务 ,即使适配器已经可以几乎消除使用上的差异 。这是因为,不同的后端服务意味着会突然出现的不兼容,从而导致测试、预发布都正常的代码在线上出现问题 。这些错误会给持续部署带来阻力 。从应用程序的生命周期来看,消除这种阻力需要花费很大的代价 。
日志把日志当作事件流
日志 使得应用程序运行的动作变得透明 。在基于服务器的环境中,日志通常被写在硬盘的一个文件里,但这只是一种输出格式 。
12-factor应用本身从不考虑存储自己的输出流 。 不应该试图去写或者管理日志文件 。相反,每一个运行的进程都会直接的标准输出(stdout)事件流 。开发环境中,开发人员可以通过这些数据流,实时在终端看到应用的活动 。
在预发布或线上部署中,每个进程的输出流由运行环境截获,并将其他输出流整理在一起,然后一并发送给一个或多个最终的处理程序,用于查看或是长期存档 。这些存档路径对于应用来说不可见也不可配置,而是完全交给程序的运行环境管理 。类似 Logplex 和 Fluentd 的开源工具可以达到这个目的 。
这些事件流可以输出至文件,或者在终端实时观察 。最重要的,输出流可以发送到 Splunk 这样的日志索引及分析系统,或 Hadoop/Hive 这样的通用数据存储系统 。这些系统为查看应用的历史活动提供了强大而灵活的功能,包括:
找出过去一段时间特殊的事件 。
图形化一个大规模的趋势,比如每分钟的请求量 。
根据用户定义的条件实时触发警报,比如每分钟的报错超过某个警戒线 。
 
管理进程后台管理任务当作一次性进程运行
进程构成(process formation)是指用来处理应用的常规业务(比如处理 web 请求)的一组进程 。与此不同,开发人员经常希望执行一些管理或维护应用的一次性任务,例如:
运行数据移植(Django 中的 manage.py migrate, Rails 中的 rake db:migrate) 。
运行一个控制台(也被称为 REPL shell),来执行一些代码或是针对线上数据库做一些检查 。大多数语言都通过解释器提供了一个 REPL 工具(Python 或 perl),或是其他命令(Ruby 使用 irb, Rails 使用 rails console) 。


推荐阅读