孤尽T31之技术选型

技术选型

技术选型是一件很重要的事情。技术选型的原因

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

编程语言排行

今天9月份推出的jdk17版本了。

2.微服务架构产生

架构的历史包括如下几个时代

第一代单体应用

把所有的应用都打包为一个war包到tomcat下运行，这种模式叫做巨石因公

第二代SOA（Service Oriented Architecture）

面向服务架构，它是一种设计方法，服务间使用松耦合

缺点：1.ESB没有从根本上解决巨石应用的一些问题

2.SOA更多的面向企业服务，服务拆分颗粒度很大，更多的是为了复用。

第三代微服务

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

思维区别：

SOA自上而下，从运维视角出发，更多聚焦可维护性，兼顾可扩展性，从前后端分离切入。

微服务，是自下而上，从产品视角出发。

3.微服务分层架构图

微服务从整体式分5层：为前端、接入层、网关、服务、存储。

前端：是系统与人交互的层面，

接入层：负载均衡和反向代理层

网关层：对服务网关配置，对服务授权，进行治理，过滤，路由等。

服务：具体的业务服务和基础服务（比如邮件、文件、消息等）

存储层：保存业务层的数据，比如数据库，文件存储服务。

4.架构环境构建

各种工具搭建复杂，

Spring boot 工具

方便的创建可独立运行的spring应用程序
直接内嵌tomcat
简化项目的构建配置
为spring 以及第三方库提供自动配置
提供生产级特性
无需生成代码或进行xml配置

netflix 热衷开源

将自己的解决方案建立为行业标准和最佳时间
建立netflix技术品牌
雇佣、留住顶级工程师
从共享生态中获得反馈输入并受益

spring clooud家族

spring cloud config配置管理工具

spring cloud bus 事件、消息总线

spring cloud stream 中间件消息发送接收封装

spring cloud gatewary 新一代分布式网关

数据访问层技术选型

JDBC

JDBC的烦恼，

1）数据库连接如何管理？

如果不管理数据库连接引发的问题包括：连接混乱；导致连接池不够用；锁死数据库；内存溢出等。

当前大部分都是使用连接池进行管理。

2）数据库查询数据和java对象如何高效映射

spring jdbctemplate要优于其它框架（mybatis、Spring JPA、hibernate等）大概20%的性能。

Mybatis

Mybatis：我的sql我做主。

Mybatis Plus：你的sql你做主，我为你服务。

理论上上sql语句应该由专门的数据库人士处理更专业。

具体要看实际需要而定。

mybatis的层次结构

从图中可以得出：

首先由SqlSessionFactoryBuuilder来加载mybatis配置信息来创建SqlSessionFactory。

SqlSessionFactory来创建回话对象SqlSession

SqlSession创建Executor执行器来执行sql

StatementHandler来处理状态包括参数处理和返回结果集处理

typeHandler来处理jdbc返回的结果集。

数据库连接池选型
1.jdbc连接池，解决需要自己手动建立连接、关闭连接、连接复用的问题。连接池有有个标准的接口 javax.sql。DataSource，常用的连接池如下
HikariCP是Spring boot的默认连接池，号称性能最好的数据库连接池。
从性能上Druid与HikariCP相差不大，但是Druid更多的支持功能。

消息中间件选型

mq消息中间件选型

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

消息的过程如下图

消息分为P2P：点对点的模式以及订阅模式。

P2P：生产者将消息点对点的发送给指定的消费者

订阅模式：生产者将消息发布在主题上，只要订阅了该主题的消费者都能接收到。

各种mq的框架

kafka从去年20年开始新版本可以不依靠zookeeper了。

技术的选型除了框架本身的参数外还需要考虑

本身团队的能力
当前项目的实际需求
组件的稳定性

RoketMQ

从图中的可以得出：生产者在发送消息之前需要先向nameserver请求master消息服务器，然后向master发送消息

远程通信框架选型

远程通信框架（RPC）运行期状态

1）调用方首先向注册中心请求，得到有哪些服务可用，根据得到的服务选择一个调用

2）调用通过远程调用调用服务提供方，主要包括

调用发起->寻址路由->协议适配/序列化-网络传输

远程通信框架的技术点

发布和引用方式：http

通信协议：是7层，还是4层，在不同的层次的协议是不一样的。

Feign框架的调用流程分析

常用的远程通信框架

网关层的技术选型

网关的由来

微服务体用的api的颗粒度通常与客户所需的颗粒度不同
不同的客户端需要不同的数据
微服务实例数量及其位置（主机+端口）动态变化
服务划分会随着时间的推移而变化，网关可以屏蔽和处理这些变化，不需要在应用系统来处理这些变化。
服务可能会使用多种协议，有些是非web有好协议

网关的分类

按照职责划分：通常分为流量网关和业务网关。

流量网关：关注稳定和安全功能包括

全局性流控

防止web攻击

按照API网关部署形式划分为单节点网关和多节点网关。

主要的开源网关有

Nginx+Lu主要是流控网关。

网关的定义以及功能

API网关的技术选型

从使用成熟度，

Spring Cloud 自身的gateway原理解析

gateway的流程

孤尽T31之技术选型相关推荐

T31项目架构选型方案
服务选型曾经的技术选型 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GjyeLuSg-1636378253985)(C:\Users\Zyf\Desktop\T31 ...
孤尽T31项目第6天-Java项目工程结构规约
文章目录前言一.应用分层 1. 分层的目的 2. MVC框架模式 3. 推荐的分层结构 4. 分层的异常处理 5. 分层数据模型二.Maven管理 1. Maven的作用 2. 构建 3. Ma ...
孤尽T31项目Day26
孤尽T31项目Day26 系统健壮性设计 1 代码评审什么样的是烂代码(人的视角) 维护者脏话的频率高维护者脏话的类型丰富存在打架斗殴的可能性面向离职编程什么是烂代码(代码视角) 不遵守代码 ...
前端技术选型的遗憾和经验教训
我是Max,Spectrum的技术联合创始人.Spectrum 是一个面向大型在线社区的开源聊天应用程序,最近被GitHub收购.我们是一个三人团队,主要拥有前端和设计背景,我们在这个项目上工作了近两 ...
宅家学习，如何进行Kubernetes Ingress控制器的技术选型？
导语:在Kubernetes的实践.部署中,为了解决 Pod 迁移.Node Pod 端口.域名动态分配等问题,需要开发人员选择合适的 Ingress 解决方案.面对市场上众多Ingress产品,开发 ...
小米资深工程师瞿晋萍（男）：米聊服务器的技术选型和架构设计
小米资深工程师瞿晋萍:米聊服务器的技术选型和架构设计 - 资讯频道 - CSDN.NET 小米资深工程师瞿晋萍:米聊服务器的技术选型和架构设计 2012-07-07 11:04 | 238次阅读 | ...
银行背景下分库分表技术选型
业务持续增长带来的单表数据量过大,必然影响到数据库的读写性能,那到底要不要分库分表呢? 阿里巴巴P3C规范给出一个推荐: [推荐]单表行数超过500万行或者单表容量超过2GB,才推荐进行分库分表. 说 ...
从数仓到数据中台，谈技术选型最优解
本文根据颜博老师在[Deeplus直播第218期]线上分享演讲内容整理而成. 颜博马蜂窝数仓研发总监现任马蜂窝数据仓库团队负责人,曾供职于京东.IBM.亚信等公司. 数据行业老兵一名,历经传统数据 ...
麦司机博客项目技术选型-Java后端
麦司机博客项目博客主页:maisiji.cn/ github地址:github.com/fendoudebb/- Java后端技术选型介绍 SpringBoot: 后端框架项目主页: spring ...

孤尽T31之技术选型

孤尽T31之技术选型相关推荐

最新文章

热门文章