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

点击上方蓝色字体,关注我们

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

Spring BootBoot的maven插件提供了良好的打包功能,将一个应用打包为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的原理。

上述流程图,是进行JWT认证的一个基本流程。JWT提供了大量的库供开发者使用,包括JAVA、C、C#、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#p-1.2

往期精彩回顾

基于CSE的微服务架构实践-基础架构

单体应用微服务改造实践

【性能测试】压榨一下ServiceComb

基于服务的分布式事务(下)

[学习微服务第10天] Service-Center 启动流程分析

▼更多精彩内容,请长按二维码▼

戳“阅读原文”我们一起进步

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值