咱们来自字节跳动飞书商业应用研发部(Lark Business Applications)，现在咱们在北京、深圳、上海、武汉、杭州、成都、广州、三亚都设立了办公区域。咱们重视的产品范畴主要在企业经历办理软件上，包含飞书 OKR、飞书绩效、飞书招聘、飞书人事等 HCM 范畴体系，也包含飞书审批、OA、法务、财政、收购、差旅与报销等体系。欢迎各位参加咱们。
本文作者：飞书商业应用研发部 许家强
欢迎大家重视飞书技能，每周定期更新飞书技能团队技能干货内容，想看什么内容，欢迎大家谈论区留言~
背景
单体应用在向微服务化架构演进时，需要考虑怎么处理服务认证授权的问题。假如处理欠好，会引发架构的混乱，带来安全、性能、难以保护的问题。 以最典型的包含WEB页面的具有登录态办理的体系为例。在开端阶段，登录鉴权一般经过cookie+redis分布式session来完成。
在服务化过程中，单体体系会拆分为多个微服务，这时微服务间会呈现彼此调用。关于运用Dubbo、Grpc等RPC协议的体系而言，因为给web页面供给的是HTTP接口，而给微服务间调用供给的RPC接口，架构比较明晰。而关于Springcloud技能体系，微服间调用和页面都是经过HTTP RESTFUL接口，这时候要处理两个问题：
- web页面的登录校验
- 微服务之间的鉴权
处理计划
透传cookie反形式
这种计划期望坚持单体架构时的调用方法，微服务间调用接口复用了供给给WEB页面的接口。 为了处理登录鉴权问题，微服务间调用时，会将WEB页面的cookie透传至其他服务，这样鉴权逻辑能够坚持不动。 很显然，该计划尽管看上去能很好work，但它是一种反形式规划，彻底违背了微服务的初衷，微服务一定是无状况的！
内外接口别离形式
很显然，上述计划是不合理的。假如想继续坚持服务间调用运用RESTFUL域名，则能够将面向前端的接口与面向微服务的接口区别开，完成方法是为两者加上不同的URL前缀，如/inner、/outer。外部接口是给WEB页面调用的，内部接口是专门给微服务间调用的。在认证鉴权时，仅针对外部接口进行鉴权，而内部接口直接放行。 该计划的问题是，内部接口存在安全隐患，能够被外界肆意攻击。 假如要缓解该问题，可经过如下方法：
- 恳求一个额外的生产网段的域名（需做七网隔离，外网/办公网/生产网段无法相互访问），专门用于服务间调用。
- 在Nignx侧添加配置，关于原有的域名，只放行以outer前缀开端的恳求。
web和服务别离形式
上述计划的另外一个变种，仍是将对外接口和对内接口分开，可是划分的更加彻底，新增了一个专门供给面向前端供给web接口的服务，如下图所示。该计划的长处：
- 微服务不需要关怀怎么校验session，所有认证都在web服务做。这个微服务是真正无状况的。
- 微服务间的调用不做鉴权。
- 微服务是高度通用的，只需要处理范畴中心逻辑，不用关怀怎么和前端页面适配，这点关于渠道型服务尤其如此。
关于该计划中因内部接口调用产生的安全问题，可参阅上个计划，恳求一个额外的生产网段的域名。
网关鉴权
关于有中台的技能团队而言，一般都会有供给一个通用的渠道网关。咱们期望在网关处理所有登录鉴权的问题，这使得登录鉴权问题对业务服务彻底通明。而关于服务间调用的问题，可运用rpc、类rpc方法（ServiceMesh）、内部域名来完成，而这些调用方法都是零信任无鉴权的。 关于这种计划，微服务的api有很大的通用性和灵活性，接口规划不需要区别接口运用的场景，是现在业界比较推荐的做法。
总结
本文介绍了服务在从单体演进到微服务架构过程中，关于服务认证鉴权遇到的问题，并供给了开发人员可能会用到的处理计划。除计划1外（不大合理、属于野路子），其他计划在具体实践过程中都有较多的case。如今微服务架构已经成为事实上的规范，咱们期望微服务一定是无状况的，专心于处理业务流程和规矩，而鉴权认证的逻辑应交给专门的技能组件来担任，因而让网关来统一处理鉴权是一个更优雅的计划。
参加咱们
扫码发现职位 & 投递简历：
官网投递：job.toutiao.com/s/FyL7DRg
