环境单体应用向微服务化架构演进时,应该考虑怎样解决服务项目认

大家来源于巨量引擎飞书商用化研发部门(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. 微服务架构是高度通用，只需要解决行业关键逻辑性，无需关注怎样和前端界面兼容，这一点针对平台模式服务项目更是如此。

对该计划方案因其内部结构接口调用造成安全问题，可参照上一个计划方案，申请办理一个额外生产制造子网的网站域名。

网关ip身份验证

针对有中台技术团队来讲，一般都会有提供一个通用性的渠道网关ip。我希望在网关ip处理全部登陆身份验证问题，这也使得登陆身份验证难题对业务服务半透明的。但对于服务项目间调用的难题，可以使用rpc、类rpc方法（ServiceMesh）、内部结构网站域名来达到，但这些启用方法全是零信任无身份验证的。 对于这类计划方案，微服务架构的api有非常大的实用性和灵敏性，界面设计不用区别插口所使用的情景，是当前业内更推荐的处理方式。

汇总

文中阐述了服务项目再从单个演进到分布式架构环节中，针对资质认证身份验证遇到的困难，并且提供开发者很有可能要用到解决方案。除计划方案1外（并不大有效、归属于歪门邪道），别的计划方案在实际实践中都是有比较多的case。现如今分布式架构成为了实际上的规范，我希望微服务架构一定是无状态的，致力于解决工作流程和标准，而身份验证认证逻辑性应交到专门技术性部件全权负责，因而让网关ip来统一解决身份验证是一个更典雅的计划方案。

加入到我们

扫二维码发觉岗位 & 投简历：

官方网站递送：job.toutiao.com/s/FyL7DRg