如何删除多个wordpress,东莞网站优化流程,查流量网站,html网站开发教程文章目录 一#xff0c;微服务二#xff0c;集群、分布式三#xff0c;远程调用四#xff0c;负载均衡五#xff0c;服务注册、服务发现、注册中心六#xff0c;配置中心七#xff0c;服务熔断、服务降级1#xff0c;服务熔断2#xff0c;服务降级3#xff0c;区别 八… 文章目录 一微服务二集群、分布式三远程调用四负载均衡五服务注册、服务发现、注册中心六配置中心七服务熔断、服务降级1服务熔断2服务降级3区别 八API 网关 这一节内容比较干全部是概念性的内容不需要实操。 一微服务
对于谷粒商城的架构无论是从理论上还是从实际开发角度可以把所有功能在一个服务里实现互联网早期很多项目都是这样落地的。
我们常常把这种架构称之为“大单体”。
当功能越来越多、系统越来越庞大、用户越来越多、研发团队越来越大“大单体架构”会暴露有很多问题比如性能问题、开发效率问题。
出现了这些问题之后很自然的想到把大单体服务拆分为多个小的服务微服务就在这个背景下诞生了。
微服务就像是把一个单独的应用程序开发为一套小服务比方说每个小服务运行在自己的进程中并使用轻量级机制通信通常是 HTTP API。这些服务围绕业务能力来构建并通过完全自动化部署机制来独立部署。
这些服务使用不同的编程语言书写以及不同数据存储技术并保持最低限度的集中式管理。
简而言之拒绝大型单体应用基于业务边界进行服务微化拆分各个服务独立部署运行。
拆分在计算机世界是一个非常重要的思想和手段当我们开发过程中遇到难题时拆分通常是非常有效的解决方案。比如大单体拆分为微服务、分库分表、冷热分类、读写分离、主从分离、主备分离都是常见的架构技巧也是遇到问题后的解决手段。
当然微服务架构也会带来很多挑战典型的问题是像下图一样众多的微服务再加上彼此之间相互调用成为一团乱码如何管理和治理就是我们必须面对的挑战这套课程的第二阶段就是解决这个问题的。 二集群、分布式
这里有点咬文嚼字了解即可。
集群是个名词分布式可以理解为副词起修饰作用。
比如我们通常说MySQL集群不会说MySQL分布式会说Redis集群不会说Redis分布式。
集群是个物理形态分布式是个工作方式。
只要是一堆机器就可以叫集群机器之间有无协作无关紧要。
分布式描述了这样一种工作方式一个工作被拆分为多个任务分发到多个集群上执行。
所以分布式系统的不同服务之间是有协作关系的。
分布式系统必然是集群式部署但是集群上运行的软件不一定能称之为分布式系统。
比如用户在商城系统下单涉及订单系统、库存系统、商品系统、结算系统需要这些系统协作才能完成这个功能商城系统就是一个分布式系统。
MySQL集群虽然是部署在多台集群上但彼此并不需要协作所以不能称之为分布式系统。
三远程调用
在分布式系统中各个服务可能处于不同主机但是服务之间不可避免的需要互相调用这种调用称为远程调用。
SpringCloud 中使用 HTTPJSON 的方式完成远程调用。 四负载均衡
分布式系统中A 服务需要调用B服务B服务是集群部署在多台机器中都存在从需求实现的角度A 调用任意一个即可。 这种情况下可能出现的一种情况是A发出的请求始终固定打到其中一台机器上(比如图中的B1导致这台服务器压力非常大而另外两台服务器又很空闲。
最好是让A的请求均匀的分发到B服务的三台服务器上避免某台服务器很忙其他服务器很闲的情况这种效果通过负载均衡来实现。
常见的负载均衡算法
①轮询。为第一个请求选择健康池中的第一个后端服务器然后按顺序往后依次选择直到最后一个然后循环。②最小连接。优先选择连接数最少也就是压力最小的后端服务器在会话较长的情况下可以考虑采取这种方式。③散列。根据请求源的 IP 的散列hash来选择要转发的服务器。这种方式可以一定程度上保证特定用户能连接到相同的服务器。如果你的应用需要处理状态而要求用户能连接到和之前相同的服务器可以考虑采取这种方式。④随机。将请求随机转发到一台服务器上在大样本下不同服务器接收到的请求数大致均衡。
五服务注册、服务发现、注册中心
A 服务调用 B 服务时A 服务需要知道 B 服务所在服务器的IP。
我们当然可以考虑把B服务的IP写死在A服务的配置文件中但是一旦B服务的IP发生变化就要修改A服务的配置文件低效且不安全。
更大的问题在于如果服务非常多比方说A服务除了调用B服务之外还可能调用其他的几十个服务如果全部都在A服务中写死IP其运维难度之大、出错概率之高是不能被容忍的。
我们还必须意识到在现在K8S容器部署已经成为微服务部署的标准方案服务的IP是动态分配的不可预知且经常变化。
这就要求必须以一种更科学灵活的方式来保存每个服务的IP。
这就是注册中心的作用。 所有的服务在部署完成后将服务名和IP注册到注册中心。
调用方根据要调用的服务的名称从注册中心获取IP然后向这个IP发送请求。
注册中心还能动态感知服务是否可用将不可用的服务剔除避免出现无效的调用。
六配置中心 每一个服务最终都有大量的配置并且每个服务都可能部署在多台机器上。
变更配置是经常性的在微服务架构下有大量的服务器如果每次变更都要去服务器上修改是不可行的不仅工作量大效率低风险也很大。
配置中心就可以完美解决这个问题配置中心用来集中管理微服务的配置信息。每个服务启动后自动从配置中心获取自己的配置。
七服务熔断、服务降级
在微服务架构中微服务之间通过网络进行通信存在相互依赖当其中一个服务不可用时有可能会造成雪崩效应。 如图所示假设库存服务不可用
①商品服务调用库存服务时库存服务没有响应商品服务就会一直等待②越来越多的请求到达商品服务都等在商品服务导致商品服务的资源被消耗殆尽最终商品服务不可用③商品服务不可用后订单服务请求商品服务没有响应一直等待④越来越多的请求到达订单服务进入等待状态导致订单服务的资源被耗尽不能接收新的订单请求订单服务也变成不可用的服务了
最终导致整个系统所有的服务都不可用了这就是雪崩。
要防止这样的情况必须要有容错机制来保护服务。
1服务熔断
服务熔断是指调用方发现服务不可用后不再发出请求。
通常的策略是设置请求超时时间当被调用的服务经常失败到达某个阈值可以开启断路保护机制后来的请求不再去调用这个服务。
2服务降级
服务降级是指被调用方感知到系统资源紧张无法处理更多的请求时不再对请求做常规的处理而是基于降级规则直接做出简单的响应避免本机资源消耗和调用方的阻塞。
3区别
服务熔断是调用方的手段服务降级是被调用方的策略。
八API 网关
在微服务架构中API Gateway 作为整体架构的重要组件它抽象了微服务中都需要的公共功能同时提供了客户端负载均衡服务自动熔断灰度发布统一认证限流流控日志统计等丰富的功能帮助我们解决很多 API 管理难题。
