我们来自字节跳动飞书商业应用研发部(Lark Business Applications)，目前我们在北京、深圳、上海、武汉、杭州、成都、广州、三亚都设立了办公区域。我们关注的产品领域主要在企业经验管理软件上，包括飞书 OKR、飞书绩效、飞书招聘、飞书人事等 HCM 领域系统，也包括飞书审批、OA、法务、财务、采购、差旅与报销等系统。欢迎各位加入我们。

本文作者：飞书商业应用研发部 许家强

欢迎大家关注飞书技术，每周定期更新飞书技术团队技术干货内容，想看什么内容，欢迎大家评论区留言~

单体应用在向微服务化架构演进时，需要考虑如何解决服务认证授权的问题。如果处理不好，会引发架构的混乱，带来安全、性能、难以维护的问题。 以最典型的包含WEB页面的具备登录态管理的系统为例。在最初阶段，登录鉴权一般通过cookie+redis分布式session来实现。

在服务化过程中，单体系统会拆分为多个微服务，这时微服务间会出现相互调用。对于使用Dubbo、Grpc等RPC协议的系统而言，由于给web页面提供的是HTTP接口，而给微服务间调用提供的RPC接口，架构比较清晰。而对于Springcloud技术体系，微服间调用和页面都是通过HTTP RESTFUL接口，这时候要解决两个问题：

1. web页面的登录校验
2. 微服务之间的鉴权

透传cookie反模式

这种方案希望保持单体架构时的调用方式，微服务间调用接口复用了提供给WEB页面的接口。 为了解决登录鉴权问题，微服务间调用时，会将WEB页面的cookie透传至其他服务，这样鉴权逻辑可以保持不动。 很显然，该方案虽然看上去能很好work，但它是一种反模式设计，完全违背了微服务的初衷，微服务一定是无状态的！

内外接口分离模式

很显然，上述方案是不合理的。如果想继续保持服务间调用使用RESTFUL域名，则可以将面向前端的接口与面向微服务的接口区分开，实现方式是为两者加上不同的URL前缀，如/inner、/outer。外部接口是给WEB页面调用的，内部接口是专门给微服务间调用的。在认证鉴权时，仅针对外部接口进行鉴权，而内部接口直接放行。 该方案的问题是，内部接口存在安全隐患，可以被外界肆意攻击。 如果要缓解该问题，可通过如下方式：

1. 申请一个额外的生产网段的域名（需做七网隔离，外网/办公网/生产网段无法互相访问），专门用于服务间调用。
2. 在Nignx侧增加配置，对于原有的域名，只放行以outer前缀开始的请求。

web和服务分离模式

上述方案的另外一个变种，仍是将对外接口和对内接口分开，但是划分的更加彻底，新增了一个专门提供面向前端提供web接口的服务，如下图所示。该方案的优点：

1. 微服务不需要关心如何校验session，所有认证都在web服务做。这个微服务是真正无状态的。
2. 微服务间的调用不做鉴权。
3. 微服务是高度通用的，只需要处理领域核心逻辑，不用关心如何和前端页面适配，这点对于平台型服务尤其如此。

对于该方案中因内部接口调用产生的安全问题，可参考上个方案，申请一个额外的生产网段的域名。

对于有中台的技术团队而言，一般都会有提供一个通用的平台网关。我们希望在网关解决所有登录鉴权的问题，这使得登录鉴权问题对业务服务完全透明。而对于服务间调用的问题，可使用rpc、类rpc方式（ServiceMesh）、内部域名来实现，而这些调用方式都是零信任无鉴权的。 对于这种方案，微服务的api有很大的通用性和灵活性，接口设计不需要区分接口使用的场景，是目前业界比较推荐的做法。

本文介绍了服务在从单体演进到微服务架构过程中，对于服务认证鉴权遇到的问题，并提供了开发人员可能会用到的解决方案。除方案1外（不大合理、属于野路子），其他方案在具体实践过程中都有较多的case。如今微服务架构已经成为事实上的标准，我们希望微服务一定是无状态的，专注于处理业务流程和规则，而鉴权认证的逻辑应交给专门的技术组件来负责，因此让网关来统一处理鉴权是一个更优雅的方案。

扫码发现职位 & 投递简历：

官网投递：job.toutiao.com/s/FyL7DRg