认证，Authentication，识别你是谁。用来识别某个用户是否是注册过的合法用户。
授权，Authorization，识别你能做什么。用来识别某个用户是否有某方面的权限。

单体架构阶段

Auth V1版本

v1版本使用了传统的Session+Cookie的形式。当用户请求登录后，服务器会校验用户名和密码，校验通过后会向Session中添加一条记录，然后将SessionId添加到Cookie里面返回给浏览器。

后续用户的访问操作会携带SessionId，Web服务器就可以根据SessionId去Session中检查，以判断用户是否登录及登录状态是否过期等。

存在的问题
Session记录只会在登录的那一台服务器上存在，而后台web服务是一个集群，前置的Nginx会将请求进行基于负载均衡策略的转发，所以可能会出现用户间歇性退出的情况。

解决方式
黏性Session架构。

Auth V1.1 ~ Sticky Session

由Nginx维护SessionId和Web服务器之间的关联，不管那一次请求，Nginx会将请求转发给对应的Web服务器进行处理，以便保证在会话期间的Session绑定。

存在的问题

稳定性：黏性会话会将用户会话绑定到某个服务器上，如果我们要对这个服务器进行一些升级或改造又或服务器延迟或宕机，那么此服务器上的一波认证用户信息就会瞬间消失，用户必须重新登录。
扩展性：黏性会话使得Web服务器和Nginx负载均衡服务器上都保存了状态，整体上属于一个有状态架构。随着流量的增长，这些状态同时给Web服务器和负载均衡器都会带来较大的压力。和无状态的应用架构比起来，这种有状态的应用架构比较难以扩展。

解决方式

会话同步复制：即各个Web服务器之间同步Session，但是会引入复杂性，整体的性能较低。
无状态会话：即Session数据不存在服务器端，而是存在浏览器端，但是存在数据泄露风险，且浏览器端对于Cookie的大小有限制（4KB）。
集中状态会话：即将Session集中存储在某个存储中，比如Memcached或Redis这种高性能缓存中。

Auth V1.5 ~ Centralized Session

Web服务器和Nginx服务器不再存储会话状态，转而交由Redis进行统一存储，从而提高了稳定性和扩展性。
对于Redis来说，也可以采用高可用集群方案，业界也有很多可扩展的实践案例。

微服务架构阶段

Auth 3.0 ~ Auth Service + Token

将登录认证抽取为一个独立的API微服务AuthService，拥有一个独立的UserDB。
这个服务统一承担登录认证、用户校验、令牌颁发等职责。
还引入了Token作为服务调用认证鉴权的主要凭证。token是一个透明令牌，也称为引用令牌，每个微服务拿到令牌，都可以去AuthService进行认证鉴权。

存在的问题

每个微服务都需要实现部分认证鉴权的逻辑，使得微服务开发方无法聚焦于业务逻辑的开发。
认证鉴权逻辑分散在每个微服务当中，一方面会带来不规范容易出错的问题，另一方面也会有潜在的安全风险（比如忘记校验令牌）

解决方式
引入网关层，进行统一的认证鉴权

Auth 3.5 ~ Token + Gateway

该架构将每个微服务都要进行的部分认证鉴权的逻辑从微服务转移到了网关中。即网关处负责拿到令牌向AuthService进行鉴权，通过后再将请求转发到后端的微服务，微服务不再包含任何认证鉴权的逻辑。
总体上，通过引入网关进行令牌的鉴权之后，大大减少了后端微服务开发方的职责，使得他们更专注于微服务的业务逻辑的开发。此外，引入网关之后，网关可以统一处理登录客户端的校验，也便于实现SSO单点登录，也为后续的微服务化和业务成长提供了基础。

存在的问题
当网站的访问流量比较大的时候，对Auth Service的压力比较大，Auth Service可能会成为性能和扩展性的瓶颈，需要严格的监控，做好HA，做好按需扩容。

解决方式
对于某些对安全不是很敏感的微服务，集中状态校验就会显得过于笨重。此时微服务可以采用基于JWT令牌的无状态的认证鉴权架构，

Auth 3.6 ~ JWT + Gateway

Auth Service颁发的令牌不再是透明令牌，而是JWT令牌。
由于JWT令牌是自包含数据和签名的，网关就不再需要到Auth Service上进行集中的校验。
这种做法简化了架构，降低了Auth Service的压力，是一种高性能的、可扩展的架构，适用于大部分对安全要求不太敏感的微服务场景。

【微服务】网站安全认证架构演进相关推荐

微服务 OLTP 分布式数据库架构演进
开源分布式数据库不用自己实现分库分表分布式数据库选型日均7亿交易量,如何设计高可用的MySQL架构? 每秒7亿次请求,阿里新一代数据库如何支撑? 云上应用系统数据存储架构演进
架构的本质是管理复杂性，微服务本身也是架构演化的结果
为应对如今无线优先和全渠道用户体验的需求和挑战,我们该如何设计灵活的面向体验的微服务架构?它有哪些模式和最佳实践?携程,Netflix和SoundCloud这些知名互联网公司是如何实践面向体验的微服务 ...
微服务——最热门的架构
微服务--最热门的架构在大型互联网应用中,如何更为合理的划分系统和团队边界.如果更加有效的组织系统开发过程.如何通过技术手段识别和消除开发过程中的浪费成为广大软件开发和技术管理人员所需要思考的命题. ...
mqtt发布json数据_微服务实战：从架构到发布（一）
引言:"微服务"是当前软件架构领域非常热门的词汇,能找到很多关于微服务的定义.准则,以及如何从微服务中获益的文章,在企业的实践中去应用"微服务"的资源却很少.本 ...
微服务实战：从架构到发布（二）
引言:上篇文章介绍了微服务和单体架构的区别.微服务的设计.消息.服务间通信.数据去中心化,本篇会继续深入微服务,介绍其它特性. 治理去中心化通常"治理"的意思是构建方案,并且迫使 ...
云原生时代微服务的高可用架构设计
简介: 在8月20日"阿里巴巴技术质量精品课"上,来自蚂蚁的经国分享了对云原生时代微服务的高可用架构设计的全面解析,为大家介绍了应用架构演进路径.云原生时代的技术福利.高可用架构的 ...
单体 soa 微服务区别_每日一读-从单体到微服务，这些年架构的演变
写在前面的话 Stay Hungry Stay Foolish!!! 每天进步一点点!!! <每日一读>是博主每日学习的一篇文章所记录的笔记,大多数是提取文章中关键内容而成:文章类型不限, ...
【2017年第3期】交通大数据：一种基于微服务的敏捷处理架构设计
杜圣东, 杨燕, 滕飞西南交通大学信息科学与技术学院,四川成都 610031 摘要:面对智慧交通广泛的大数据应用场景和技术需求,一般大数据系统难以适应多种处理情况并做出快速响应.针对这一问题,首次 ...
微服务系统之认证管理
2019独角兽企业重金招聘Python工程师标准>>> 引言: 微服务大行其道,微服务安全也是非常热门的话题.本文向大家分享微服务系统中认证管理相关技术.其中包括用户认证.网关和 A ...

【微服务】网站安全认证架构演进