网站找人做的他能登管理员吗禁止显示网站目录

当前位置： 首页 > news >正文

网站找人做的他能登管理员吗,禁止显示网站目录,温州专业手机网站制作多少钱,毕业生登记表自我鉴定模板目录 一、概念 1、单体架构 2、微服务 3、springcloud 二、微服务的拆分 1、微服务的拆分原则 1.1 什么时候拆 1.2 怎么拆 2、服务调用 2.1 resttemplate 2.2 远程调用 一、概念 1、单体架构 单体架构#xff08;monolithic structure#xff09;#xff1a;顾名…  目录 一、概念 1、单体架构 2、微服务 3、springcloud 二、微服务的拆分 1、微服务的拆分原则 1.1 什么时候拆 1.2 怎么拆 2、服务调用 2.1 resttemplate 2.2 远程调用 一、概念 1、单体架构 单体架构monolithic structure顾名思义整个项目中所有功能模块都在一个工程中开发项目部署时需要对所有模块一起编译、打包项目的架构设计、开发模式都非常简单。 当项目规模较小时这种模式上手快部署、运维也都很方便因此早期很多小型项目都采用这种模式。 但随着项目的业务规模越来越大团队开发人员也不断增加单体架构就呈现出越来越多的问题 团队协作成本高试想一下你们团队数十个人同时协作开发同一个项目由于所有模块都在一个项目中不同模块的代码之间物理边界越来越模糊。最终要把功能合并到一个分支你绝对会陷入到解决冲突的泥潭之中。 系统发布效率低任何模块变更都需要发布整个系统而系统发布过程中需要多个模块之间制约较多需要对比各种文件任何一处出现问题都会导致发布失败往往一次发布需要数十分钟甚至数小时。 系统可用性差单体架构各个功能模块是作为一个服务部署相互之间会互相影响一些热点功能会耗尽系统资源导致其它服务低可用。
2、微服务 微服务Microservices是一种软件架构风格它将一个大型应用程序拆分为一组小型、独立的服务每个服务运行在自己的进程中并通过轻量级的通信机制如HTTP/REST或消息队列进行通信。每个服务通常专注于完成一个特定的业务功能并且可以独立部署、扩展和维护。 微服务架构首先是服务化就是将单体架构中的功能模块从单体应用中拆分出来独立部署为多个服务。同时要满足下面的一些特点 单一职责一个微服务负责一部分业务功能并且其核心数据不依赖于其它模块。 团队自治每个微服务都有自己独立的开发、测试、发布、运维人员团队人员规模不超过10人2张披萨能喂饱 服务自治每个微服务都独立打包部署访问自己独立的数据库。并且要做好服务隔离避免对其它服务产生影响
在微服务中可以将不同的模块交给不同的团队开发并且独立部署 那么单体架构存在的问题有没有解决呢 团队协作成本高 由于服务拆分每个服务代码量大大减少参与开发的后台人员在1~3名协作成本大大降低 系统发布效率低 每个服务都是独立部署当有某个服务有代码变更时只需要打包部署该服务即可 系统可用性差 每个服务独立部署并且做好服务隔离使用自己的服务器资源不会影响到其它服务。 综上所述微服务架构解决了单体架构存在的问题特别适合大型互联网项目的开发因此被各大互联网公司普遍采用。大家以前可能听说过分布式架构分布式就是服务拆分的过程其实微服务架构正式分布式架构的一种最佳实践的方案。 当然微服务架构虽然能解决单体架构的各种问题但在拆分的过程中还会面临很多其它问题。比如 如果出现跨服务的业务该如何处理 页面请求到底该访问哪个服务 如何实现各个服务之间的服务隔离
3、springcloud Spring Cloud 是一个基于 Spring Boot 的微服务框架它提供了一系列工具和库帮助开发者快速构建和部署微服务架构的应用程序。Spring Cloud 提供了许多常见的微服务模式和组件如服务发现、配置管理、负载均衡、断路器、API 网关等。 微服务拆分以后碰到的各种问题都有对应的解决方案和微服务组件而SpringCloud框架可以说是目前Java领域最全面的微服务组件的集合了。 而且SpringCloud依托于SpringBoot的自动装配能力大大降低了其项目搭建、组件使用的成本。对于没有自研微服务组件能力的中小型企业使用SpringCloud全家桶来实现微服务开发可以说是最合适的选择了 目前SpringCloud最新版本为2022.0.x版本对应的SpringBoot版本为3.x版本但它们全部依赖于JDK17目前在企业中使用相对较少。 SpringCloud版本SpringBoot版本2022.0.x aka Kilburn3.0.x2021.0.x aka Jubilee2.6.x, 2.7.x (Starting with 2021.0.3)2020.0.x aka Ilford2.4.x, 2.5.x (Starting with 2020.0.3)Hoxton2.2.x, 2.3.x (Starting with SR5)Greenwich2.1.xFinchley2.0.xEdgware1.5.xDalston1.5.x 二、微服务的拆分 1、微服务的拆分原则 服务拆分一定要考虑几个问题 什么时候拆 如何拆
1.1 什么时候拆 一般情况下对于一个初创的项目首先要做的是验证项目的可行性。因此这一阶段的首要任务是敏捷开发快速产出生产可用的产品投入市场做验证。为了达成这一目的该阶段项目架构往往会比较简单很多情况下会直接采用单体架构这样开发成本比较低可以快速产出结果一旦发现项目不符合市场损失较小。 如果这一阶段采用复杂的微服务架构投入大量的人力和时间成本用于架构设计最终发现产品不符合市场需求等于全部做了无用功。 所以对于大多数小型项目来说一般是先采用单体架构随着用户规模扩大、业务复杂后再逐渐拆分为微服务架构。这样初期成本会比较低可以快速试错。但是这么做的问题就在于后期做服务拆分时可能会遇到很多代码耦合带来的问题拆分比较困难前易后难。 而对于一些大型项目在立项之初目的就很明确为了长远考虑在架构设计时就直接选择微服务架构。虽然前期投入较多但后期就少了拆分服务的烦恼前难后易。 1.2 怎么拆 之前我们说过微服务拆分时粒度要小这其实是拆分的目标。具体可以从两个角度来分析 高内聚每个微服务的职责要尽量单一包含的业务相互关联度高、完整度高。 低耦合每个微服务的功能要相对独立尽量减少对其它微服务的依赖或者依赖接口的稳定性要强。 高内聚首先是单一职责但不能说一个微服务就一个接口而是要保证微服务内部业务的完整性为前提。目标是当我们要修改某个业务时最好就只修改当前微服务这样变更的成本更低。 一旦微服务做到了高内聚那么服务之间的耦合度自然就降低了。 当然微服务之间不可避免的会有或多或少的业务交互比如下单时需要查询商品数据。这个时候我们不能在订单服务直接查询商品数据库否则就导致了数据耦合。而应该由商品服务对应暴露接口并且一定要保证微服务对外接口的稳定性即尽量保证接口外观不变。虽然出现了服务间调用但此时无论你如何在商品服务做内部修改都不会影响到订单微服务服务间的耦合度就降低了。 明确了拆分目标接下来就是拆分方式了。我们在做服务拆分时一般有两种方式 纵向拆分 横向拆分 所谓纵向拆分就是按照项目的功能模块来拆分。例如商城项目中就有用户管理功能、订单管理功能、购物车功能、商品管理功能、支付功能等。那么按照功能模块将他们拆分为一个个服务就属于纵向拆分。这种拆分模式可以尽可能提高服务的内聚性。 而横向拆分是看各个功能模块之间有没有公共的业务部分如果有将其抽取出来作为通用服务。例如用户登录是需要发送消息通知记录风控数据下单时也要发送短信记录风控数据。因此消息发送、风控数据记录就是通用的业务功能因此可以将他们分别抽取为公共服务消息中心服务、风控管理服务。这样可以提高业务的复用性避免重复开发。同时通用业务一般接口稳定性较强也不会使服务之间过分耦合。 然而当我们拆分完成到不同的模块之后我们又会遇到一个新的问题那就是当拆分为不同的微服务之后我们如何跨服务调用其他服务的接口 2、服务调用 当我们将前端的nginx启动之后你就会惊讶的发现为什么获取不了后端的数据了明明拆分之前还好好的这是因为将单体项目拆分成了不同的服务了然而不同的服务之间是不能直接调用其它服务的三层架构中的功能的。如果想要调用该如何实现呢首先要明白服务之间调用也是要用HTTP请求或者REST那么我们如何发送HTTP请求到其他服务呢 2.1 resttemplate Spring给我们提供了一个RestTemplate的API可以方便的实现Http请求的发送。其中提供了大量的方法方便我们发送Http请求例如 可以看到常见的Get、Post、Put、Delete请求都支持如果请求参数比较复杂还可以使用exchange方法来构造请求。 在使用之前需要先将resttemplate注入到ioc容器中做如下配置 package com.hmall.cart.config; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.web.client.RestTemplate; Configuration public class RemoteCallConfig {Beanpublic RestTemplate restTemplate() {return new RestTemplate();} } 2.2 远程调用 示例如下 可以看到利用RestTemplate发送http请求与前端ajax发送请求非常相似都包含四部分信息 请求方式 请求路径 请求参数 返回值类型
Java发送http请求可以使用Spring提供的RestTemplate使用的基本步骤如下 注册RestTemplate到Spring容器 调用RestTemplate的API发送请求常见方法有 getForObject发送Get请求并返回指定类型对象 PostForObject发送Post请求并返回指定类型对象 put发送PUT请求 delete发送Delete请求 exchange发送任意类型请求返回ResponseEntity 使用过之后我们会发现这种方法跨服务调用有很多的劣势比如我们直接将url写死了就不能灵活的调用其他的功能了、再者就是这种方法比较繁琐需要很多的参数。在下面我们会借助nacos服务注册中心实现服务之间的调用这样实现会比较方便而且不会出现上述问题。