SaaS应用12原则:(六)进程

301 阅读4分钟

以一个或多个无状态进程运行应用

运行环境中,应用程序通常是以一个和多个进程运行的。

最简单的场景中,代码是一个独立的脚本,运行环境是开发人员自己的笔记本电脑,进程由一条命令行(例如python my_script.py)启动。另外一个极端情况是,复杂的应用可能会使用很多进程类型 ,也就是零个或多个进程实例。

12-Factor 应用的进程必须无状态且无共享

任何需要持久化的数据都要存储在后端服务 内,比如数据库

内存区域或磁盘空间可以作为进程在做某种事务型操作时的缓存,例如下载一个很大的文件,对其操作并将结果写入数据库的过程。12-Factor 应用根本不用考虑这些缓存的内容是不是可以保留给之后的请求来使用,这是因为应用启动了多种类型的进程,将来的请求多半会由其他进程来服务。即使在只有一个进程的情形下,先前保存的数据(内存或文件系统中)也会因为重启(如代码部署、配置更改、或运行环境将进程调度至另一个物理区域执行)而丢失。

源文件打包工具(Jammit, django-compressor) 使用文件系统来缓存编译过的源文件。12-Factor 应用更倾向于在构建步骤做此动作——正如 Rails 资源管道,而不是在运行阶段。

一些互联网系统依赖于粘性 session(sticky session), 这是指将用户 session 中的数据缓存至某进程的内存中,并将同一用户的后续请求路由到同一个进程。粘性 session 是 12-Factor 极力反对的。Session 中的数据应该保存在诸如 Memcached 或 Redis 这样的带有过期时间的缓存中。

粘性 Session 缺点:

  • 不应该在进程内存中存放数据
  • 因为无法确保客户端下次请求也会被路由到该进程

总结

  • 12-Factor 应用的进程必须无状态且无共享。
  • 任何需要持久化的数据都要存储在 后端服务内,比如数据库。
  • Session 中的数据应该保存在诸如 Memcached 或 Redis 这样的带有过期时间的缓存中。
  • 运行环境中,应用程序通常是以一个和多个进程运行的。
  • 最简单的场景中,代码是一个独立的脚本,运行环境是开发人员自己的笔记本电脑,进程由一条命令行启动。

补充知识:

状态化服务

对服务器程序来说,究竟是有状态服务,还是无状态服务,其判断依旧是指两个来自相同发起者的请求在服务器端是否具备上下文关系

状态化请求: 服务器端一般都要保存请求的相关信息,每个请求可以默认地使用以前的请求信息

无状态请求: 服务器端所能够处理的过程必须全部来自于请求所携带的信息,以及其他服务器端自身所保存的、并且可以被所有请求所使用的公共信息

粘性与非粘性 Session

黏性Session: 此模式下同一会话中的请求都被派送到同一个tomcat实例上,这样我们就无须在多台服务器之间实现session共享了,这是其好处,不好的地方就是不能实现failureover了,一但用户访问的机器挂掉,那么其session就会丢失。

非黏性Session: 又名复制Session,此模式下同一会话中的请求可以被分配到不同的tomcat实例上进行处理,此时就需要在不同服务器之间同步、复制session,这样一来即使一台服务器挂掉了,请求在其它服务器上照样可以访问到session信息,其缺点在于Session复制需要系统资源和网络开销

参考: