微服务
微服务架构风格是一种使用一套小服务来开发单个应用的方式途径,每个服务运行在自己的进程中,并使用轻量级机制通信,通常是HTTP API,这些服务基于业务能力构建,并能够通过自动化部署机制来独立部署,这些服务使用不同的编程语言实现,以及不同数据存储技术,并保持最低限度的集中式管理。
优势:
微服务每个模块就相当于一个单独的项目,代码量明显减少,遇到问题也相对来说比较好解决。
微服务每个模块都可以使用不同的存储方式(比如Redis、mysql等),数据库也是单个模块对应自己的数据库
微服务每个模块都可以使用不同的开发技术,开发模式更灵活。
本质:
微服务关键不仅仅是微服务本身,而是系统要提供一套基础的架构,这种架构使得微服务可以独立的部署、运行、升级,不仅如此,这个系统架构还让微服务与微服务之间在结构上“松耦合“,而在功能上则表现为一个统一的整体,这种所谓的”统一的整体“表现出来的是统一风格的界面、统一的权限管理、统一的安全策略、统一的上线过程、统一的日志和审计方式、统一的调度方式、统一的访问入口等。
微服务的目的是有效地拆分应用,实现敏捷开发和部署
认证过程
实现方式:
方式1:基于Session。Spring-Security会对Cookie中的SessionID进行解析,找到服务器存储的Session信息然后判断当前用户是否符合请求的要求。
方式2:基于Cookie。解析出token,然后将当前请求加入到Spring-Security管理的权限信息中去。
微服务应用通常使用基于Cookie的token方式进行认证:
权限管理数据模型
菜单表:acl_permission
| id | name |
|---|---|
| 1 | 讲师管理 |
| 2 | 课程管理 |
角色表:acl_role
| id | name |
|---|---|
| 11 | 管理员 |
| 12 | 测试人员 |
用户表:acl_user
| id | name |
|---|---|
| 100 | lucy |
| 101 | mary |
菜单角色关系表:acl_role_permission
| cid | rid |
|---|---|
| 1 | 11 |
| 2 | 11 |
| 2 | 12 |
角色用户关系表:acl_user_role
| rid | uid |
|---|---|
| 11 | 100 |
| 11 | 101 |
| 12 | 101 |
