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

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

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

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

脱离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#section-1.2

▼

往期精彩回顾

▼

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

单体应用微服务改造实践

【性能测试】压榨一下ServiceComb

基于服务的分布式事务（下）

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

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