持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第22天，点击查看活动详情
微服务架构如何演变的？
传统单体架构 -> 分布式架构 -> SOA面向服务架构 -> 微服务架构
传统单体架构，也就是单点应用，早期所学习的SSM或者SSH整合项目，采用分层架构模式，数据库访问层dao、业务控制逻辑层service、控制层controller。将所有代码放到同一个项目中，部署在同一个tomcat中。
传统单体架构的优缺点：
优点：开发简单、运维简单
缺点：没有对业务逻辑实现拆分，所有代码写到同一个项目中，维护性十分差。只适合小团队或者个人开发，不适合团队模式协同开发。开发团队100人，会产生冲突问题。
如果系统中某个模块出现不可用，整个系统不可用。
应用场景：政府项目、小型管理系统、crm、oa
SOA架构模式的优缺点：
缺点：
1、采用SOAP协议实现通讯，xml传输非常重，效率低
2、服务化管理和治理设施不完善
3、依赖于中心服务发现机制
4、不适合于前后端分离架构
SOA架构与微服务架构有什么区别？
1、通讯协议
微服务架构基于SOA架构演变过来，继承SOA架构的优点，去除了SOA架构中的SOAP协议和ESB企业服务总线，改为http+Json形式传输我们的接口
ESB企业服务总线：多系统之间跨语言通讯，对数据协议实现转换，提供可靠的消息传输。
2、服务拆分的粒度
微服务，每个服务之间互不影响，独立的数据库、redis链接、MQ。实现独立部署，整个服务架构更加轻巧，轻量级。
3、迭代
微服务架构模式比SOA架构模式，更加适合互联网公司敏捷、搞笑、快速迭代版本。
微服务架构中会存在那些问题？
1、分布式事务的解决方案：rabbitmq、rocketmq事务消息、setata。最终一致性的问题
2、分布式任务调度平台：xxl-job、alibabaCloud Scheduler
3、分布式注册与发现：eureka、zookeeper、nacos
4、分布式日志采集系统：elk+kafaka
5、分布式服务追踪与调用链系统：Zipkin
6、分布式服务配置中心：阿波罗、nacos
非常重要的概念：独立部署、可配置、动态化
springcloud并不是一个rpc远程调用框架，而是一个微服务全家桶的解决方案的框架。
理念就是一条龙服务解决我们再微服务架构中遇到的问题。
公司有一定规模但不是特别有钱。（中小型的公司）
rpc远程调用的框架有哪些？
httpclient、dubbo、feign、grpc、基于netty手写rpc
springcloud第一代实际上都是用的Netflix核心组件
springcloud第二代实际上都是用的自己研发和alibaba的微服务解决框架整合
第一代：
springcloud config 分布式配置中心
euraka：服务治理
hystrix：服务保护
Ribbon：负载均衡
Feign：服务调用
Zuul：网关组件
第二代：
Nacos服务注册、配置中心
Sentinel服务保护
Seata分布式事务解决框架
OSS 阿里云存储（阿里云产品）
SchedulerX 分布式任务调度平台（建议xxl-job）
SMS 分布式短信平台
先定义接口对应规则名称，再定义用户对应规则名称
返回权限不足页面
先定义403转到/error/403接口，然后在该接口写具体返回内容。
RBAC权限模型（五张表结构）
1、权限表
id=101 接口：/addMember tag= addMember
id=102 接口： /updateMember tag= updateMember
2、角色表
test-admin
test-add
3、角色权限表
test-admin ->权限id=1，2（权限tag=addMember，updateMember ）
test-add ->权限id=1（权限tag=addMember）
4、用户表
admin用户
add用户
5、用户角色表
admin用户->test-admin
add用户->test-add
