手机怎么用代理ip上网

分布式与微服务架构解析

• 一、分布式
• • 1、什么是分布式架构
  • 2、为什么需要分布式架构
  • 3、分布式架构有哪些优势？
  • 4、分布式架构有什么劣势？
  • 5、分布式架构有哪些关键技术？
  • 6、基于分布式架构如何提高其高性能？
  • 7、如何基于架构提高系统的稳定性?
  • 8、分布式架构有什么难点？
• 二、微服务
• • 1、什么是微服务
  • 2、微服务架构诞生的背景
  • 3、为什么需要微服务架构
  • 4、微服务架构存在的问题
  • 5、微服务架构的优点
  • 6、常见的微服务架构
• 三、分布式架构和微服务架构的区别

一、分布式

1、什么是分布式架构

微服务架构是分布式架构，分布式架构不一定是微服务架构

2、为什么需要分布式架构

分布式架构可以更好的提高系统的容量、可靠性(避免单点故障)、性能。 同时因为模块化，系统的可重用性以及并行并发开发的效率也会提高。

3、分布式架构有哪些优势？

1. 可以实现更大数据量的存储。（抖音每天几十pb的数据）
2. 可以更好提高系统的高可用性。（业务冗余、业务拆分、限流、熔断）
3. 可以更好提高系统的可重用性。
4. 可以更好提高系统的性能。

4、分布式架构有什么劣势？

• 复杂性增加：分布式架构的设计和实现相对于单体应用来说更加复杂。开发人员需要考虑到网络通信、数据一致性、故障处理等方面的问题，这增加了系统的复杂性和开发的难度。
• 性能问题：由于分布式架构将系统拆分成多个服务，服务之间需要通过网络进行通信，这会引入一定的延迟。同时，分布式系统中的负载均衡和数据分片等机制也会对性能产生一定的影响。
• 一致性难题：在分布式系统中，由于存在多个节点，数据的一致性成为一个复杂的问题。保证数据的一致性需要引入复杂的分布式事务机制，增加了系统的开销和复杂性。
• 部署和维护成本增加：由于分布式架构涉及多个服务的部署和维护，这增加了部署和维护的成本。同时，对于分布式系统的监控和故障排查也需要更多的工作。
  系统的复杂性增加了故障排查的难度：由于分布式架构的复杂性，当系统出现故障时，排查问题变得更加困难。需要考虑多个服务之间的交互，以及网络通信等方面的问题。

5、分布式架构有哪些关键技术？

• 服务治理

• 架构管理

• DevOps（开发与运维一体化）

• 资源调度管理

• 整体架构监控

• 流量控制

6、基于分布式架构如何提高其高性能？

一般面对这样的问题，首先要从整体维度去思考，要分析问题，例如影响系统性能的因素有哪些？

1. 请求数据的传输时间
2. 请求数据的处理时间
3. 响应数据的传输时间
4. 响应数据的渲染时间
   当了解影响系统性能的因素以后，此时可以给出一些具体解决方案，例如；
5. 减少数据传输时间？（加宽带，减少数据传输量，减少传输距离）
6. 提高请求数据的处理速度？（CPU、内存、硬盘、分布式架构，缓存、算法、sql调优，索引的设计、异步）
   3.减少数据在客户端的渲染时间？（局部更新-Ajax，减少不必要的元素渲染等）
   具体从架构层面进行设计的话可以从如下几个维度进行思考：

• 应用缓存

• 负载均衡

• 异步调用

• 数据分区和数据镜像

具体从SQL调优层面如何进行优化呢？

• 获取执行慢的SQL（通过慢 SQL日志找到执行慢的SQL）
• 获取影响SQL执行比较慢的原因（通过执行计划分析SQL执行慢的原因）
• 给出具体SQL的优化方案（例如数据量太大，没设计索引或没走索引，SQL结构设计不合理）

7、如何基于架构提高系统的稳定性?

• 服务拆分：分而治之

• 服务冗余：有备无患

• 限流降级：细水长流，断尾求生

• 高可用架构：多机房部署

• 高可用运维

8、分布式架构有什么难点？

• 异构系统存在很多不标准的问题

• 系统架构中的服务依赖问题

• 故障发生的概率更大

• 多层架构的运维复杂度很大

二、微服务

1、什么是微服务

微服务架构具有以下特点：

• 服务拆分：微服务架构将应用程序拆分成多个小型的服务，每个服务都专注于特定的业务功能。这种拆分使得每个服务可以独立开发、部署和扩展，从而提高了开发效率和系统的灵活性。
• 独立部署：每个微服务都可以独立部署，这意味着当一个服务需要更新或修复时，只需要重新部署该服务，而不需要重新部署整个应用程序。这种独立部署的特性可以减少对整个系统的影响，并提高了系统的可用性。
• 松耦合：微服务架构通过轻量级的通信机制（如RESTful API或消息队列）来实现服务之间的通信。这种松耦合的通信方式使得每个服务可以独立演化，而不会对其他服务产生影响。同时，松耦合还使得每个服务可以使用不同的技术栈和编程语言，以满足不同的需求。
• 可伸缩性：由于每个微服务都是独立部署的，因此可以根据需求对每个服务进行独立的扩展。这种可伸缩性使得系统可以根据负载的变化来动态调整资源的分配，从而提高系统的性能和可用性。

2、微服务架构诞生的背景

3、为什么需要微服务架构

微服务架构是从soa架构模式演变过来的，比SOA架构对服务拆分的粒度更加精细，让业务界限更加清晰

• SOA 早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间，最终 SOA 看起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。
• 此外，实施SOA时会遇到很多问题，比如通信协议（例如SOAP）的选择、第三方中间件如何选择、服务粒度如何确定等，目前也存在一些关于如何划分系统的指导性原则，但其中有很多都是错误的。SOA并没有告诉你如何将单体应用划分成微服务，所以在实施SOA时会遇到很多问题。
• 传统企业或者很多企业的软件，大多不止一套系统，都是各个独立大系统的堆砌。通常存在扩展性差、可靠性不高、维护成本大、重复轮子很多等问题。

对于上述这些问题，可以想到的解决方案有：组件化、服务化。
微服务架构将各个组件或者模块分散到各个服务中，对整个系统实现解耦。那微服务架构强调的重中之重就是业务系统需要完善的组件化和服务化。

• 组件化：将一个大系统，按照一定的业务或者技术维度关注形式，拆分成独立的组件。目的是为了分而治之，为了可重用，为了减少耦合度。比如按照技术维度：搜索组件、缓存组件；按照业务维度：用户中心、支付中心等
• 服务化：是一种以服务为中心的解决方案：服务注册、服务发布、服务调用、服务监控、服务负载均衡等。核心就是不同服务之间的通信。服务化之前：代码重复、可维护性低、DB 访问耦合等。服务化后的好处：调用简单、代码复用、业务隔离、数据库解耦等

4、微服务架构存在的问题

服务注册与发现：
微服务之间相互调用完成整体业务功能，需要考虑如何在众多微服务中找到正确的目标服务地址。 这就是所谓「服务发现」功能，常用的做法是：

• 服务提供方启动的时候把自己的地址上报给「服务注册中心」，这就是「服务注册」。
• 服务调用方「订阅」服务变更「通知」，动态的接收服务注册中心推送的服务地址列表，以后想找哪个服务直接发给他就可以。
• 分布式服务注册与发现（eureka、consul、zookeeper、Nacos）
• 分布式事务解决方案（rabbitmq、rocketmq事务消息、lnc（淘汰）、setata）最终一致性概念
• 分布式任务调度平台（XXL-Job、AlibabaCloud Scheduler、elastic-job）

运维成本：
微服务将系统分成多个独立的部分，每个部分都是可以独立部署的业务单元。这就意味着，在微服务架构下，随着服务数量的增多，每个服务都需要独立的配置、部署、监控、日志收集等，因此成本呈指数级增长。

• 这就需要我们有一套完备的服务监控体系，包括拓扑关系、监控（Metrics）、日志监控（Logging）、调用追踪（Trace）、告警通知、健康检查等，防患于未然。
• 分布式日志采集系统elk+kafka
• 分布式服务追踪与调用链系统Zipkin

部署自动化：
对于微服务架构而言，每个服务都是一个独立可部署的业务单元，每个服务的修改都需要独立部署。如何有效地构建自动化部署流水线，降低部署成本、提高部署频率，是微服务架构下需要面临的一个挑战。

• 分布式服务配置中心（springcloud config/nacos/disconfig/携程阿波罗）

服务容错：
生产环境复杂多变，服务运行过程中不可避免的发生各种故障（宕机、过载等等），需要引入「熔断、隔离、限流和降级、超时机制」等「服务容错」机制来保证服务持续可用性。
微服务是拆分成多个服务进行部署，服务间的通信都是通过网络，此时的性能会受影响。同时可靠性也会受影响。数据一致性也需要严格控制，其成本也比单块系统高。
服务治理：
由于微服务架构是把系统拆分为若干个可独立部署的服务，所以需要：

• 进行服务间的依赖测试：在服务数量较多的情况下，如何有效地保证服务之间能有效按照接口的约定正常工作，成为微服务实施过程中必须面临的巨大挑战。
• 随着微服务个数的增多，如何清晰有效地展示服务之间的依赖关系，成为了一个挑战。

服务安全：
有些服务的敏感数据存在安全问题，「服务安全」就是对敏感服务采用安全鉴权机制，对服务的访问需要进行相应的身份验证和授权，防止数据泄露的风险。

DevOps 与组织结构：
传统单块架构中，团队通常是按技能划分，如开发部、测试部、运维部，并通过项目的方式协作，完成系统交付。而在微服务架构的实施过程中，在组织或者团队层面，如何传递 DevOps 文化的价值，让团队理解 DevOps 文化的价值，并构建全功能团队，也是一个不小的挑战。

• 微服务不仅表现出一种架构模型，同样也表现出一种组织模型。
• 这种新型的组织模型意味着开发人员和运维的角色发生了变化，开发者将承担起服务整个生命周期的责任，包括部署和监控，而运维也越来越多地表现出一种顾问式的角色，尽早考虑服务如何部署。
• 因此，如何在微服务的实施中，按需调整组织架构，构建全功能的团队，是一个不小的挑战。

5、微服务架构的优点

• 技术异构性：
  不同服务内部的开发技术可以不一致，你可以用java来开发helloworld服务A，用golang来开发helloworld服务B。
  为不同的服务选择最适合该服务的技术，系统中不同部分也可以使用不同的存储技术，比如A服务可以选择redis存储，B服务你可以选择用MySQL存储，这都是允许的。
• 隔离性：
  一个服务不可用不会导致另一个服务也瘫痪，因为各个服务是相互独立和自治的系统。
  这在单体应用程序中是做不到的，单体应用程序中某个模块瘫痪，必将导致整个系统不可用，当然，单体程序也可以在不同机器上部署同样的程序来实现备份，不过，同样存在资源浪费问题。
• 可扩展性：
  可以只对那些影响性能的服务做扩展升级，这样对症下药的效果是很好的。
  庞大的单体服务如果出现性能瓶颈只能对软件整体进行扩展，可能真正影响性能的只是其中一个很小的模块，我们也不得不付出升级整个应用的代价，这在微服务架构中得到了改善。
• 简化部署：
  在微服务架构中，各个服务的部署是独立的，如果真出了问题也只是影响单个服务，可以快速回滚版本解决。
  如果你的服务是一个超大的单体服务，有几百万行代码，即使修改了几行代码也要重新编译整个应用，这显然是非常繁琐的，而且软件变更带来的不确定性非常高，软件部署的影响也非常大。
• 易优化：
  微服务架构中单个服务的代码量不会很大，这样当你需要重构或者优化这部分服务的时候，就会容易很多，毕竟，代码量越少意味着代码改动带来的影响越可控。

6、常见的微服务架构

Dubbo
Dubbo是阿里巴巴开源的基于 Java 的高性能 RPC（一种远程调用） 分布式服务框架（SOA），致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。
Dubbo 提供的基础能力包括： 服务发现、流式通信、负载均衡、流量治理等等。
提供的通信模型： 同步的 Request-Response （默认）、消费端异步请求、提供端异步执行、消费端请求流、提供端响应流、双向流式通信。
Dubbo 提供的是 Client-Based 的服务发现机制，使用者可以有多种方式启用服务发现：

• 使用独立的注册中心组件，如 Nacos、Zookeeper、Consul、Etcd 等。
• 将服务的组织与注册交给底层容器平台，如 Kubernetes。

部署架构： 为了在分布式环境下实现各个微服务组件间的协作， Dubbo 定义了一些中心化组件。

• 注册中心
• 配置中心
• 元数据中心
  

Tars
腾讯内部使用的微服务架构 TAF（Total Application Framework）多年的实践成果总结而成的开源项目。
仅支持 C++ 语言，目前在腾讯内部应用也非常广泛。2017 年对外开源，仅支持 C++ 语言。
gRPC
是Google开发的高性能、通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计，基于ProtoBuf(Protocol Buffers)序列化协议开发。
本身它不是分布式的，所以要实现上面的框架的功能需要进一步的开发。2015 年对外开源的跨语言 RPC 框架，支持多种语言。

thrift
最初是由 Facebook 开发的内部系统跨语言的高性能 RPC 框架，2007 年贡献给了 Apache 基金，成为 Apache 开源项目之一， 跟 gRPC 一样，Thrift 也有一套自己的接口定义语言 IDL，可以通过代码生成器，生成各种编程语言的 Client 端和 Server 端的 SDK 代码，支持多种语言。

三、分布式架构和微服务架构的区别

分布式架构和微服务架构是两种不同的架构模式，它们在设计和实现上有一些明显的区别。下面是它们之间的对比：