今天给大家带来的是 数人云 工程师文权在高效运维线上群的分享实录。从传统单体应用架构到微服务架构，安全问题一直是人们关注的重点，文权与大家分享了关于微服务访问安全设计方案的探索与实践。
我们首先从传统单体应用架构下的访问安全设计说起，然后分析现代微服务架构下，访问安全涉及的原则，接着讨论目前常用的几种微服务架构下的访问安全设计方案。最后，详析Spring Cloud微服务架构下如何解决访问安全的问题。
一、传统单体应用的访问安全设计
上面的示意图展示了单体应用的访问逻辑。用户通过客户端发出http或者https请求，经过负载均衡后，单体应用收到请求。接着经过auth层，进行身份验证和权限批准，这里，一般会有跟后端数据库的交互。通过后，将请求分发到对应的功能逻辑层中去。完成相关操作后，返回结果给客户端。
传统单体应用的访问安全设计——原则
从以上分析可以看到，传统单体应用的访问安全设计原则为：
第一，每次的用户请求都需要验证是否安全，这里可以分两种情况：
一种是没有session的请求，需要经过几个步骤完成session化。一般为验证当前用户的credential，获取当前用户的identity，这两步都需要访问数据库等持久化对象来完成，最后一步是为当前可用创建session，返回给客户端后，启用该session。
另一种是有session的请求，只需验证请求中当前session的有效性，即可继续请求。
第二，用户的操作请求都在后端单个进程中执行完成，完全依赖后端调用方法的可靠性。一旦出错，应用是无法再次重复请求。
传统单体应用的访问安全设计——优势和注意点
小结，传统单体应用由于设计相对简单单一，暴露给外界的入口相对较少，从而具有被攻击并造成危害性的可能小的优势。
也正是由于单体应用简单单一的特点，需要注意相关问题：
应用后端保存了所有的credential等敏感信息
一旦入侵了对这个应用的请求，就有可能拿到所有的保存在后端的信息
应用的每次操作一般都需要和数据库进行交互，造成数据库负载变高
二、微服务架构下，访问安全设计原则
先来看下这张典型的微服务设计架构图，如图所示，有以下几点特征：
每个服务只有权限去操作自己负责的那部分功能。
用户请求的身份验证和权限批准都由独立的gateway服务来保障
对外服务的LB层无法直接与提供业务服务的应用层进行访问
从上面的特征分析来看，想要给出一份访问安全设计的原则说明，就要看看微服务架构下，访问安全有哪些痛点，以下罗列了几点：
单点登录，即在微服务这种多独立服务的架构下，实现用户只需要登录一次就能访问所有相互信任的应用系统
微服务架构下的应用一般都是无状态的，导致用户的请求每次都需要鉴权，可能引发Auth服务的性能瓶颈
微服务架构下，每个组件都管理着各自的功能权限，这种细粒度的鉴权机制需要事先良好的规划
微服务架构下，需要考虑到那些非浏览器端的客户请求，是否具有良好的可操作性
根据实际情况，还有一些其他痛点，这里不再一一赘述，而这些痛点，就形成了我们在为微服务架构设计访问安全的原则。
三、微服务架构下，常用的访问安全设计方案
HTTP Basic Authentication + Independent Auth DB
HTTP Basic Authentication + Central Auth DB