分布式与微服务架构解析
一、分布式
1、什么是分布式架构
微服务架构是分布式架构，分布式架构不一定是微服务架构
当系统的并发处理能力、存储能力不足时，我们可能会创建多个web服务(多个tomcat服务器)，多个数据库服务(主从架构等)，这些服务器通过网络进行连接，然后协同处理客户端的并发请求，这样的系统我们称之为分布式系统。
2、为什么需要分布式架构
分布式架构可以更好的提高系统的容量、可靠性(避免单点故障)、性能。 同时因为模块化，系统的可重用性以及并行并发开发的效率也会提高。
当一个系统的业务量越来越大时，我们需要垂直或是水平拆分业务系统，同时为了避免所有业务都部署在一台机器上时，一旦机器出现故障从而导致整体不可用，就需要将这些业务部署在多台计算机上，来构建一个分布式架构。
3、分布式架构有哪些优势？
- 可以实现更大数据量的存储。（抖音每天几十pb的数据）
- 可以更好提高系统的高可用性。（业务冗余、业务拆分、限流、熔断）
- 可以更好提高系统的可重用性。
- 可以更好提高系统的性能。
4、分布式架构有什么劣势？
- 复杂性增加：分布式架构的设计和实现相对于单体应用来说更加复杂。开发人员需要考虑到网络通信、数据一致性、故障处理等方面的问题，这增加了系统的复杂性和开发的难度。
- 性能问题：由于分布式架构将系统拆分成多个服务，服务之间需要通过网络进行通信，这会引入一定的延迟。同时，分布式系统中的负载均衡和数据分片等机制也会对性能产生一定的影响。
- 一致性难题：在分布式系统中，由于存在多个节点，数据的一致性成为一个复杂的问题。保证数据的一致性需要引入复杂的分布式事务机制，增加了系统的开销和复杂性。
- 部署和维护成本增加：由于分布式架构涉及多个服务的部署和维护，这增加了部署和维护的成本。同时，对于分布式系统的监控和故障排查也需要更多的工作。 系统的复杂性增加了故障排查的难度：由于分布式架构的复杂性，当系统出现故障时，排查问题变得更加困难。需要考虑多个服务之间的交互，以及网络通信等方面的问题。
5、分布式架构有哪些关键技术？
- 服务治理
服务治理最大的意义是需要把服务间的依赖关系、服务调用链，以及关键的服务给梳理出来，并对这些服务进行性能和可用性方面的管理。一般我们所讨论的服务拆分、服务注册、服务发现、服务限流、服务熔断、降级、服务的链路跟踪，监控等都属于服务治理的范畴。
- 架构管理
基于服务所形成的架构需要用架构管理、整体架构的生命周期管理，以及对服务的编排、聚合事务处理等服务调度的功能。
- DevOps（开发与运维一体化）
分布式系统可以更为快速的更新服务，但是对于服务的测试和部署都会是挑战。所以，还需要DevOps的全流程，其中包括环境构建、持续集成、持续部署等、自动化运维。有了DevOps后，我们就可以对服务进行自动伸缩、故障迁移、配置管理、状态管理等一系列的自动化运维技术了。（AIOps）
- 资源调度管理
应用层的自动化运维需要基础层的调度支持，也就是云计算IaaS层的计算、存储、网络等资源调度、隔离和管理。
- 整体架构监控
如果没有一个好的监控系统，那么自动化运维和资源调度管理只可能成为一个泡影，因为监控系统是你的眼睛。没有眼睛、没有数据，就无法进行高效的运维。所以说，监控是非常重要的部分。这里的监控需要对三层系统（应用层、中间件、基础层）进行监控。
- 流量控制
6、基于分布式架构如何提高其高性能？
一般面对这样的问题，首先要从整体维度去思考，要分析问题，例如影响系统性能的因素有哪些？
- 请求数据的传输时间
- 请求数据的处理时间
- 响应数据的传输时间
- 响应数据的渲染时间当了解影响系统性能的因素以后，此时可以给出一些具体解决方案，例如；
- 减少数据传输时间？（加宽带，减少数据传输量，减少传输距离）
- 提高请求数据的处理速度？（CPU、内存、硬盘、分布式架构，缓存、算法、sql调优，索引的设计、异步） 3.减少数据在客户端的渲染时间？（局部更新-Ajax，减少不必要的元素渲染等）具体从架构层面进行设计的话可以从如下几个维度进行思考：
- 应用缓存
为系统添加缓存，可以有效地提高系统的访问能力。从前端的浏览器，到网络，再到后端的服务，底层的数据库、文件系统、硬盘和CPU，全都有缓存，这是提高快速访问能力最有效的手段。
- 负载均衡
负载均衡是做水平扩展的关键技术，使用多台机器来共同分担一部分流量请求。
- 异步调用
异步系统主要通过消息队列来对请求做排队处理，这样可以把前端的请求的峰值给“削平”了，而后端通过自己能够处理的速度来处理请求。
- 数据分区和数据镜像
数据区分是把数据按一定的方式分成多个区（比如通过地理位置），不同的数据区分来分担不同区的流量。
具体从SQL调优层面如何进行优化呢？
- 获取执行慢的SQL（通过慢 SQL日志找到执行慢的SQL）
- 获取影响SQL执行比较慢的原因（通过执行计划分析SQL执行慢的原因）
- 给出具体SQL的优化方案（例如数据量太大，没设计索引或没走索引，SQL结构设计不合理）
7、如何基于架构提高系统的稳定性?
- 服务拆分：分而治之
服务拆分可以更好的实现故障隔离，同时也可以重用服务模块。
- 服务冗余：有备无患
服务冗余是为了去除单点故障，支持服务的弹性伸缩，以及故障迁移。
- 限流降级：细水长流，断尾求生
当系统扛不住压力时，只能通过限流或者功能降级的方式来停掉一部分任务，或是拒绝一部分用户，以确保整个架构不会挂掉。
- 高可用架构：多机房部署
高可用就是从冗余架构的角度来保障可用性。比如多租户隔离，灾备多活等，总之是wield不出单点故障。
- 高可用运维
指的是DevOps中的CI（持续集成）、CD（持续部署）。一个良好的运维应做了足够的自动化测试，做相应的灰度发布，以及对线上系统的自动化控制。这样就可以做到“计划内”或是“非计划内”的宕机事件的时长最短。
8、分布式架构有什么难点？
- 异构系统存在很多不标准的问题
构建软件时使用的编程语言、通讯协议、数据格式、运维标准可能不同，进而导致架构设计的复杂度越来越高。
- 系统架构中的服务依赖问题
传统的单体应用，一台机器挂了，整个软件就垮掉了，分布式架构下也可能出现这样的问题，因为一个服务可能会依赖另一个服务，某个服务挂掉了，会导致调用链上的服务都出现故障。
- 故障发生的概率更大
分布式架构中，服务和机器都会比较多，故障发生的频率会更大，只是影响面没有单体应用的影响面大，分布式系统中故障可以被隔离。还有就是分布式架构管理相对于单体架构也更加复杂，没有优秀的架构管理人员，故障的频率还是会非常高。
- 多层架构的运维复杂度很大
分布式架构中，我们可以将系统分为四层(基础层、平台层、应用层、接入层)
- 基础层：包括机器、网络和存储设备
- 平台层：就是中间件层包括tomcat、MySQL、Redis、RocketMQ类似的软件。
- 应用层：就是我们的业务软件，包括各种业务服务。
- 接入层：就是接入用户请求的网关、负载均衡、CDN、DNS等。
二、微服务
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 代码，支持多种语言。
微服务框架与RPC
- 什么是RPC？ RPC (Remote Procedure Call）远程过程调用是一个计算机通信协议。我们一般的程序调用是本地程序内部的调用，RPC允许你像调用本地函数一样去调用另一个程序的函数，这中间会涉及网络通信和进程间通信，但你无需知道实现细节，RPC框架为你屏蔽了底层实现。
- RPC是一种服务器-客户端（Client/Server）模式，经典实现是一个通过发送请求-接受回应进行信息交互的系统。
- 两者关系： 微服务框架一般都包含了RPC的实现和一系列「服务治理」能力，是一套软件开发框架。我们可以基于这个框架之上实现自己的微服务，方便的利用微服务框架提供的「服务治理」能力和RPC能力，所以微服务框架也被有些人称作RPC框架。
三、分布式架构和微服务架构的区别
分布式架构和微服务架构是两种不同的架构模式，它们在设计和实现上有一些明显的区别。下面是它们之间的对比：
分布式架构微服务架构定义分布式架构是将一个大型系统划分为多个独立的模块，这些模块可以在不同的服务器上运行，通过网络进行通信。微服务架构是一种将应用程序划分为一组小型、独立的服务的架构，每个服务都可以独立部署、扩展和维护。系统复杂性分布式架构通常需要更多的协调和管理，因为不同的模块需要通过网络进行通信和协调。微服务架构通过将系统拆分为小型服务，降低了系统的复杂性，每个服务可以独立开发和部署。扩展性分布式架构通常需要在整个系统上进行扩展，当系统的负载增加时，需要增加整个系统的资源。微服务架构允许对系统的不同服务进行独立的扩展，当某个服务的负载增加时，只需增加该服务的资源。可维护性分布式架构的模块间的依赖关系较强，当一个模块发生变化时，可能会影响到其他模块，导致维护困难。微服务架构的每个服务都是独立的，当一个服务发生变化时，只需关注该服务的维护，不会影响其他服务。部署分布式架构需要将整个系统一起部署，当一个模块发生变化时，需要重新部署整个系统。微服务架构允许每个服务独立部署，当某个服务发生变化时，只需重新部署该服务。
版权归原作者 Aimee.洁 所有， 如有侵权，请联系我们删除。