互联网技术架构——无状态

无状态服务（Stateless Service）： 是指该服务运行的实例不会在本地存储需要持久化的数据，并且多个实例对于同一个请求响应的结果是完全一致的。
有状态服务（Stateful Service）: 是指该服务的实例可以将一部分数据随时进行备份，并且在创建一个新的有状态服务时，可以通过备份恢复这些数据，以达到数据持久化的目的。

无状态服务可以有一个或多个实例，因此支持两种服务容量调节模式；有状态服务只能有一个实例，不允许创建多个实例，因此也不支持服务容量调节模式。

尽管有很多办法可以同步和管理状态，但是最好的方法是是避免它。会话和状态破坏互联网（SaaS、电子商务等）多租户应用承诺的终极价值。在任何给定时间内，保留用户交互的数据越多，系统能服务的用户数量就越少。

在多用户领域，目标是单个系统要服务尽可能多的用户，同时仍然保持完美的用户体验。因此，我们力求解除系统对用户数量的任何限制。状态和会话耗费内存和处理能力，因此它们是以成本效益方式扩展时必须去除的部分。

有时状态对业务很重要，如果状态是必要的，我们需要以容错、高可用和成本效益的方式实施，如把状态分发到最终用户或定位在基础设施的某个特殊服务上。

---

力求无状态

尽可能选择无状态实施方案，有状态会限制可扩展性、降低可用性并增加成本。始终拒绝任何系统中对状态的需求。采用业务指标和对比（A/B）测试来确定应用中的状态是否真的会带来可预见的用户行为和业务价值。

如果只采用拆分数据库和服务器，并通过负载均衡器处理会话和状态以保持黏性。虽然可以依赖会话复制来准备好另一个系统，使我们可以在系统出故障的情况下把该服务器加入池中，但是这种方法昂贵而且需要重复内存，同时消耗系统容量。

如果确实需要状态，可以采用状态分布，即把状态移到浏览器或分布式状态服务器或缓存中。

---

在浏览器中保存会话数据

彻底避免会话数据，但需要时，在用户的浏览器中使用cookie来保存会话数据。这样做的第一个好处是系统不需要存储数据。第二个好处是来自浏览器的请求可以由池中的任何服务器处理。

但是存储会话状态的一个缺点就是，数据必须在浏览器和需要此数据的服务器之间来回传输。浏览器支持的cookie每块最多是4KB，同一域名中最多有20块cookie。但是cookie越多越大，页面加载速度越慢，因为对每个请求该数据必须来回传输。另一个缺点就是cookie会泄露用户的信息HTTPS的SSL协议要求对所有的通信加解密，可以使用两个cookie，一个是授权cookie，要求对每个使用如下JavaScript调用的HTTP页面都需要通过HTTPS来传输。这将允许大量页面（内容、CSS、脚本等）通过不安全的HTTP传输，而单一授权cookie通过HTTPS传输。

在实施时，控制cookie数据的大小至关重要。数据过多会降低页面加载以及系统Web服务器的性能。

---

用分布式缓存处理状态

当需要存储会话数据但又不能在用户的浏览器上存储时，可以使用分布式缓存在系统中存储会话数据。

首先，远离需要应用或Web服务器黏性的有状态系统。

其次，不要使用状态或会话复制服务，例如那些运行在应用服务器或第三方“集群”服务器上的服务。因为会话修改需要传播到多个节点，所以这样的系统根本无法扩展。

最后，在选择会话缓存或持久性引擎时，不要把缓存放在执行实际工作的服务器上。这有助于提高可用性，当某个服务器宕机时，至少可以保证服务器上于此关联的缓存和运行在上面的服务有一个幸存。创建缓存层（或持久层）也使我们仅根据访问缓存去扩展，而不必同时考虑应用服务和内部及远程的缓存服务。

可以选择分布式对象缓存（Memcached）或第三方数据库，作为会话信息的缓存解决方案。

---

想了解更多关于互联网技术架构：互联网技术架构专栏