《孤尽班T31-05-技术架构选型笔记》

T31项目

文章目录

《孤尽班T31-05-技术架构选型笔记》
1. 关于技术选型
- 1.1 为什么要啊进行技术选型？
- 1.2 微服务架构的产生
- 1.3 SOA和微服务的思维区别
- 1.4 微服务分层架构图
- 1.5 Spring Cloud
2 数据访问层选型
- 2.1 JDBC
- 2.2 Mybatis 与Mybatis-plus
- 2.3 数据库连接池选型
3 消息中间件选型
- 3.1 MQ消息队列简介
- 3.2 MQ选型
4 远程通信框架选型
- 4.1 RPC框架核心技术点
- 4.2 Fegin框架调用流程分析
- 4.3 常用开源远程通信框架综合对比
5 网关层技术选型
- 5.1 API网关的由来
- 5.2 网关的分类
- 5.3 API网关部署形式：
- 5.4 业务网关技术选型
- 5.5 Spring cloud GateWay流程分析

参考学习

1. 关于技术选型

1.1 为什么要啊进行技术选型？

降低开发成本
提高研发效率

1.2 微服务架构的产生

第一代单体应用，所有的模块打包到一起部署运行
例如打包一个War包放到一个Tomcat下运行，这种架构也叫巨石应用架构，在开发小型项目上有独特的优势
易于调试、部署、运维方便

缺点：

不可靠。任何模块的一个bug,可能拖垮整个应用
单维扩展。只能通过运行更多的服务器水平扩展，而不同的应用服务对资源的需求不同
不可持续发展。引入新的框架或语言需要重构所有业务模块，往往需要在初期就选定技术栈
复制代码

SOA（Service Oriented Architecture）,面向服务架构，他是一宗会给你设计方法，设计上通常是自上而下的，服务间松散耦合。ESB集成不同协议的服务，做消息的转化、解释、路由从而联通各个服务，解决企业通信问题，服务松耦合、可扩展

缺点：

ESB的存在并没有根本解决单体巨石应用的一些问题
SOA更多的面向企业服务，服务拆分粒度很大，更多的是为了复用

微服务，是去中心化的SOA扩展，强调服务彻底的组件化，一个组件就是一个产品，服务切分粒度更小，设计上更多的自下而上的。服务间通过轻量化的协议进行通信，并根据服务本身需要独立化部署

1.3 SOA和微服务的思维区别

1.4 微服务分层架构图

优点：

业务隔离
并行开发
易于运维
单独部署

1.5 Spring Cloud

2 数据访问层选型

2.1 JDBC

数据库连接如何管理？
数据库查询数据和Java对象如何高效映射？

2.2 Mybatis 与Mybatis-plus

Mybatis 我的sql我做主
Mybatis plus 你的sql你做主，我为你服务

2.3 数据库连接池选型

**定义：**JDBC连接池，解决需要自己手动建立连接（TCP连接）、关闭连接、连接复用的问题。JDBC连接池有一个标准的接口javax.sql.DataSource，常用的JDBC连接池如下：

3 消息中间件选型

3.1 MQ消息队列简介

消息队列，在消息的传输过程中保存消息的容器，生产者和消费者不直接通讯，依靠队列保证消息的可靠性，避免了系统间的相互影响

3.2 MQ选型

功能不具备一票否决权
重性能、重扩展
技术栈、团队驾驭能力

4 远程通信框架选型

4.1 RPC框架核心技术点

4.2 Fegin框架调用流程分析

4.3 常用开源远程通信框架综合对比

5 网关层技术选型

5.1 API网关的由来

微服务提供的API的粒度通常与客户端所需的粒度不同
不同的客户端需要不同的数据
微服务实例数量及其位置（主机|端口）动态变化
服务划分会随着时间的推移而变化
服务可能会使用多种协议，有些事非web友好协议

5.2 网关的分类

流量网关与业务网关

流量网关：关注稳定安全
全局性流控
防止web攻击
屏蔽工具扫描
白黑IP名单
证书、加解密处理
业务网关：提供更好的服务
服务级别流控
服务降级与熔断
路由与负载均衡、灰度策略
服务过滤、聚合与发现
多级缓存策略
复制代码

5.3 API网关部署形式：

单节点网关与多点网关

5.4 业务网关技术选型

5.5 Spring cloud GateWay流程分析

5.6 T31项目技术栈