互联网系统的通用架构笔记

接入层session设计原则：

1、Session—读写请求使用的上下文对象，称之会话。

业务总有状态的：用户下单购买、登录状态、好友状态、消息发送情况等；

这些有状态的信息随用户操作变化。

单机环境下：

1. 不存在session共享问题；
2. 处理简单；
3. session保存在内存；
4. 高可用不能保证（进程挂掉、宕机、session丢失不可用）。

集群设计：

--session复制：

所有接入层服务器之间同步session数据；

每台接入服务器都保存用户全量的session数据；

用户只需访问一台机器，获取速度快；

高可用保障：宕机部分机器，没影响。

问题：

--适用于接入层集群较少，不适量大量上千台接入层服务器；

--大量session复制，占用服务器和网络资源；

--存储全量用户session，内存占用量太大，甚至有可能溢出；

 

大型设计：

session绑定：

根据用户请求(UIDMacimei等唯一标示)负载均衡到特定接入层服务务器；

部分网站使用；

高可用如何保障：单点问题、复制机制（master-slave）

 

多机设计：

客户端保持 session：

--session由服务端生成，存储到客户端；

--每次请求携带客户端session；

--服务端若有更新返回给客户端存储；

C/S：

--APPS：记录到Native中；

B/S:

--Web：记录到Cookie中。

缺点：

Web Cookie记录信息大小限制（如100KB）；

每次请求都要传输session：流量、性能受影响；

用户关闭、清理掉session，用户请求不正常；

优点：

方案简单，支持服务端的无缝伸缩；

方案可用性高；

较多网站使用；

Session高可用集群：

--接入层无状态化；

--统一的高可用session分布式读写服务器集群；

--状态分离：

    接入层本身无状态；

session集群有状态：

分布式缓存（NoSQL—memcached/Redis, RDBMS—Mysql/MongoDB）

接入层安全性：

接入层是客户端和服务端的Interface；

数据安全重要性不言而喻；

保证数据安全性：连接通道加密、传输数据加密。

客户端与服务端建立安全信道—技术方案：

所有请求数据都加密，提高效率；使用对称加密算法；

对称加密密钥使用非对称加密算法经过两次协商确定；

安全信道的建立必须满足：

    任何第三方无法伪造服务器；

    在破解客户端代码的情况下，即使截获其他用户发送的加密请求也无法解密。

使用HTTPS：

    数据安全的加密；

    不推荐单向加密；使用双向加密（安全）

    客户端证书

数据加密目的：

    解决数据明文的问题；

    即使截获也无法解密；

    无法保证数据篡改；

如何保证数据正确性：

    数据签名：双方约定规则签名（md5sum、其他）

    过程：

1. 客户端按照约定签名；
2. 服务端收到数据，按照规则生成md5sum值；
3. 和数据包里md5sum值比较是否一致；
4. 一致说明没问题；不一致则说明被改

高可用接入层最佳实践：

    模块与数据分离；

    session绑定：每个session同步复制；