基于CSE的微服务架构实践-轻量级架构技术选型

举报
liubao68 发表于 2019/02/23 10:45:40 2019/02/23
【摘要】 本文在前一篇“基于CSE的微服务架构实践-基础架构”基础上,介绍了使用CSE进行轻量级架构的技术选型参考。文末提供了基于JWT的微服务认证鉴权方案。

轻量级架构模式下,可以选择CSE作为RPC开发框架的基础,并选择其他开源技术实现微服务业务功能。

 

Spring BootBootmaven插件提供了良好的打包功能,将一个应用打包为jar包,可以方便的分发应用程序,同时使用ServiceStage可以轻松的部署jar包,实现容器运行。

 

轻量级架构下,技术选型会倾向于选择轻量级组件,而不选择封装好的框架,以实现对于应用程序最灵活的控制,比如不选择任何spring-boot-start封装的组件,也不选择必须构建于J2EE(或者JavaEE)协议之上的组件。这种架构通常适合于技术开发能力比较强的团队,对于技术原理有比较深入的了解,然后期望更加高效灵活的实现业务诉求。

业务场景

技术选型

选型考虑

网关

CSE Edge Service

非常高效的异步通信支持的网关实现,同时最大限度开放了底层vert.x   API,转发逻辑可以由业务灵活定制。

实例隔离、重试、隔离仓等

CSE RPC内置功能

Hystrix在早期应用广泛,但是由于其性能问题、错误定位以及在业务场景上适应性问题,不建议用户采用,最新版本目前已经停止维护。

数据库访问

dbcp + mybatis

不依赖于J2EE的实现,能够非常灵活的在不同运行环境使用。

Redis访问

jedis


消息中间件

kafka,activemq

消息中间件类型很多,都提供了自己的客户端类,不依赖于spring

分布式事务

ServiceComb pack (TCC)


认证鉴权

Role Based + JWT

或者Role   Based + Session或者JWT +   Session的组合实现

不采用任何框架,自行实现鉴权服务,更加灵活的管理业务认证需求。

 

脱离Spring Boot体系和J2EE(JavaEE)技术体系构建微服务,具备很大的灵活性,能够掌握系统的细节。但是对技术人员要求相对高一些。好在很多开发场景,比如数据库、消息中间件、认证鉴权等都有大量非常成熟、稳定并使用广泛的库可以选择,因此这个难度并不是很大。

 

作为一个案例,我们使用JWT库,提供一个可参考的鉴权实现方案。在开始之前,建议开发者查询JWT的资料,了解JWT的原理。

 image.png


上述流程图,是进行JWT认证的一个基本流程。JWT提供了大量的库供开发者使用,包括JAVACC#javascript等等。要进行JWT认证,需要在各个节点部署共享秘钥或者采用非对称秘钥完成认证。在上面的例子中,认证管理服务部署了公私钥对,其他服务部署了公钥。

 

采用JWT认证的流程如下:

1.       用户调用认证管理服务的login接口获取Token。通常用户需要提供用户名密码等信息。返回的Token是按照JWT标准进行编码的BASE64格式,包含了有效期、唯一标识等规定的字段,还包含少量的角色信息,比如roles=USER,ADMIN等。这些信息采用了认证管理服务的私钥进行加密,只有采用它分发的公钥才能够解密。请求完成后,用户将Token设置到浏览器Cookie里面或者LocalStorage里面。

2.       用户调用产品管理接口。需要将Token信息从浏览器读取出来,通过Authorization头或者其他的HTTP头将信息传递下来。其他服务可以采用公钥对Token进行解密,确认用户身份,以及获取角色信息。对于身份认证的部分,可以在网关统一进行,也可以直接由业务执行。网关进行的好处是可以防止疏漏,但是会存在重复检查的成本。业务可以从Token里面解析出来角色信息,以判断访问者是否具备相关操作,比如listProduct或者deleteProduct的权限。

 

JWT的好处是非常适合微服务架构,认证过程完全是无状态的,可以由使用者在本地完成认证,非常高效。同时非常适合需要进行大量第三方认证的场景(比如OAuth),在获取第三方授权的Token后,就直接可以在业务中进行认证,不需要对第三方认证提供额外的会话管理机制。

 

JWT机制作为业务系统的认证机制也存在一些问题。比如Token大小的问题。如果业务系统比较复杂,权限认证需要大量的信息才能够确定,那么Token信息可能随着权限规则的增加而增加,由于HTTP消息头过大,可能导致拒绝服务,还会影响整个系统的网络传输效率,造成大量浪费。因此在设计Token的的时候,一定需要对影响Token大小的因素做好评估,控制Token的大小。针对特殊场景,需要采用额外的认证机制弥补这个缺陷。比如认证管理服务提供接口/queryAllowedOperations,允许用户通过Token ID查询授权的操作列表,同时结合缓存等方案,减少对于认证管理服务的访问。JWT还有增加重放攻击的可能性,这个可以结合有效时间,在认证服务里面提供Token续期接口等方式,弥补可能存在的风险。

 

总之,JWT给微服务进行会话管理提供了良好的解决方案,依赖于灵活的认证鉴权系统设计,可以适配各种复杂的业务场景。通过JWT库完成相关的认证逻辑开发,而不依赖于一些会话管理框架,给业务提供了极大的灵活性和选择空间。

 

作为一个专门的的第三方认证服务,可以参考OAuth 2 它使用JWT作为认证的技术基础:

https://tools.ietf.org/html/rfc6749#section-1.2


【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。