架构设计内容分享(一百九十七)：分布式架构

本文链接：https://blog.csdn.net/qq_45038038/article/details/135995450

单体架构

单体架构比较初级，典型的三级架构，前端(Web/手机端)+中间业务逻辑层+数据库层。这是一种典型的Java Spring mvc或者Python Drango框架的应用。其架构图如下所示：

单体架构的应用比较容易部署、测试，在项目的初期，单体应用可以很好地运行。然而，随着需求的不断增加，越来越多的人加入开发团队，代码库也在飞速地膨胀。慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。

下面是单体架构应用的一些缺点：

「复杂性高」：以一个百万行级别的单体应用为例，整个项目包含的模块非常多、模块的边界模糊、依赖关系不清晰、代码质量参差不齐、混乱地堆砌在一起。可想而知整个项目非常复杂。每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个Bug都会带来隐含的缺陷。

「技术债务」：随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。“ 不坏不修”，这在软件开发中非常常见，在单体应用中这种思想更甚。已使用的系统设计或代码难以被修改，因为应用程序中的其他模块可能会以意料之外的方式使用它。

「部署频率低」：随着代码的增多，构建和部署的时间也会增加。而在单体应用中，每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式耗时长、影响范围大、风险高，这使得单体应用项目上线部署的频率较低。而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复，出错率比较高。

「可靠性差」：某个应用Bug，例如死循环、内存溢出等，可能会导致整个应用的崩溃。

「扩展能力受限」：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。例如，应用中有的模块是计算密集型的，它需要强劲的CPU；有的模块则是IO密集型的，需要更大的内存。由于这些模块部署在一起，不得不在硬件的选择上做出妥协。

「阻碍技术创新」：单体应用往往使用统一的技术平台或方案解决所有的问题，团队中的每个成员都必须使用相同的开发语言和框架，要想引入新框架或新技术平台会非常困难。

微服务架构

「定义」：微服务架构是一种将单一应用程序划分为一组小的、独立的服务的方法。每个服务运行在其自己的进程中，服务之间通过轻量级的方式（如HTTP REST API）进行通信。

「服务特性」：每个微服务专注于完成一个特定的业务功能，并且可以独立部署和扩展。微服务通常是长期运行的，即使在没有用户请求的时候。

「优势」：微服务提高了系统的可伸缩性和容错性，因为一个服务的故障不会影响到其他服务。此外，由于每个服务都是独立开发和维护的，所以团队可以使用最适合该服务的技术栈。

「例子」：例如，在一个电商系统中，可以有多个微服务，如用户服务（处理用户账户和认证）、商品服务（管理商品信息和库存）、订单服务（处理订单创建和支付）等。每个服务都可以有自己的数据库，并独立升级或扩展。

Serverless架构

「定义」：Serverless架构是一种云计算模型，其中云服务商负责执行用户的代码并管理基础架构。在这种模型中，开发者只需要关注业务逻辑的实现，而无需关心服务器的运维。

「服务特性」：在Serverless架构中，应用被分解为一系列的函数或者事件处理程序。这些函数只有在被调用时才会运行，并且只按实际运行时间计费。

「优势」：Serverless架构提供了高度的弹性，因为它自动管理和扩展底层资源。此外，它还消除了空闲容量的成本，因为你只为代码的实际执行时间付费。

「例子」：例如，一个图像处理服务可以采用Serverless架构。当用户上传一张图片时，这个操作会触发一个函数，该函数负责处理图片（如裁剪、压缩或添加滤镜）。处理完成后，结果图片会被存储回云存储服务。在这个过程中，没有任何长期运行的服务器，只有在处理图片时才会有计算资源被分配。

探索从单体架构到微服务，再到无服务器(Serverless)的架构之旅，我们见证了技术的不断演进和变革，以及软件架构在这其中所起到的至关重要的角色。每一种架构模式，无论是紧凑的单体，灵活的分布式，精细的微服务，还是轻盈的Serverless，都在为满足日益多变和复杂的业务需求，技术挑战以及市场竞争提供不同的策略和方案。

「单体架构」：它以其简洁高效赢得了小型项目和快速上线的场景。

「分布式应用」：在处理中大型项目和高并发场景时，显得擅长且稳健。

「微服务架构」：为大型复杂项目和快速迭代开发提供了精细化的管理和组织。

「Serverless架构」：在轻量级应用和无状态快速计算中展现出无需运维的轻盈和自由。

在这个快速发展的技术世界中，每一种架构都有其独到的优点和不可避免的挑战。理解它们的核心价值和适用场景，能使我们在面对不同的业务和技术需求时，做出富有远见和策略性的选择。而在未来，我们或许会迎来更多创新的架构模式和技术解决方案。

未来的软件架构将更加注重灵活性、可扩展性、安全性和易用性。在持续探索的道路上，让我们一起以开放的心态拥抱变化，不断学习新的知识，技能和理念，以期在未来的软件开发实践中，我们能够创造更为卓越和智能的解决方案，驾驭技术的波涛，赋能业务的创新和发展！

分布式架构

中级架构，分布式应用，中间层分布式+数据库分布式，是单体架构的并发扩展，将一个大的系统划分为多个业务模块，业务模块分别部署在不同的服务器上，各个业务模块之间通过接口进行数据交互。

数据库也大量采用分布式数据库，如redis、ES、solor等。通过LVS/Nginx代理应用，将用户请求均衡的负载到不同的服务器上。其架构图如下所示：

该架构相对于单体架构来说，这种架构提供了负载均衡的能力，大大提高了系统负载能力，解决了网站高并发的需求。

另外还有以下特点：「降低了耦合度」：把模块拆分,使用接口通信,降低模块之间的耦合度。

「责任清晰」：把项目拆分成若干个子项目,不同的团队负责不同的子项目。

「扩展方便」：增加功能时只需要再增加一个子项目,调用其他系统的接口就可以。

「部署方便」:可以灵活的进行分布式部署。

「提高代码的复用性」：比如service层,如果不采用分布式rest服务方式架构就会在手机wap商城,微信商城,pc,android，ios每个端都要写一个service层逻辑,开发量大,难以维护一起升级,这时候就可以采用分布式rest服务方式,公用一个service层。

「缺点」 : 系统之间的交互要使用远程通信,接口开发增大工作量,但是利大于弊。

微服务架构，主要是中间层分解，将系统拆分成很多小应用（微服务），微服务可以部署在不同的服务器上，也可以部署在相同的服务器不同的容器上。当应用的故障不会影响到其他应用，单应用的负载也不会影响到其他应用，其代表框架有Spring cloud、Dubbo等。

其架构图如下所示：

「易于开发和维护」：一个微服务只会关注一个特定的业务功能，所以它业务清晰、代码量较少。开发和维护单个微服务相对简单。而整个应用是由若干个微服务构建而成的，所以整个应用也会被维持在一个可控状态。

「单个微服务启动较快」：单个微服务代码量较少，所以启动会比较快。

「局部修改容易部署」：单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。

「技术栈不受限」：在微服务架构中，可以结合项目业务及团队的特点，合理地选择技术栈。例如某些服务可使用关系型数据库MySQL；某些微服务有图形计算的需求，可以使用Neo4j；甚至可根据需要，部分微服务使用Java开发，部分微服务使用Node.js开发。

微服务虽然有很多吸引人的地方，但它并不是免费的午餐，使用它是有代价的。使用微服务架构面临的挑战。

「运维要求较高」：更多的服务意味着更多的运维投入。在单体架构中，只需要保证一个应用的正常运行。而在微服务中，需要保证几十甚至几百个服务服务的正常运行与协作，这给运维带来了很大的挑战。

「分布式固有的复杂性」：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。

「接口调整成本高」：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有使用了该接口的微服务都需要做调整。

「重复劳动」：很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而导致代码重复。尽管可以使用共享库来解决这个问题（例如可以将这个功能封装成公共组件，需要该功能的微服务引用该组件），但共享库在多语言环境下就不一定行得通了。

当我们还在容器的浪潮中前行时，已经有一些革命先驱悄然布局另外一个云计算战场：Serverless架构。

2014年11月14日，亚马逊AWS发布了新产品Lambda。当时Lambda被描述为：一种计算服务，根据时间运行用户的代码，无需关心底层的计算资源。从某种意义上来说，Lambda姗姗来迟，它像云计算的PaaS理念：客户只管业务，无需担心存储和计算资源。在此前不久，2014年10月22日，谷歌收购了实时后端数据库创业公司Firebase。Firebase声称开发者只需引用一个API库文件就可以使用标准REST API的各种接口对数据进行读写操作，只需编写HTML＋CSS＋JavaScrip前端代码，不需要服务器端代码（如需整合，也极其简单）。

相对于上两者，Facebook 在2014年二月收购的 Parse，则侧重于提供一个通用的后台服务。这些服务被称为Serverless或no sever。想到PaaS（平台即服务）了是吗？很像，用户不需要关心基础设施，只需要关心业务，这是迟到的PaaS，也是更实用的PaaS。这很有可能将会变革整个开发过程和传统的应用生命周期，一旦开发者们习惯了这种全自动的云上资源的创建和分配，或许就再也回不到那些需要微应用配置资源的时代里去了。

Serverless架构能够让开发者在构建应用的过程中无需关注计算资源的获取和运维，由平台来按需分配计算资源并保证应用执行的SLA（服务等级协议），按照调用次数进行计费，有效的节省应用成本。ServerLess的架构如上图所示。其优点如下所示：

「低运营成本」：在业务突发性极高的场景下，系统为了应对业务高峰，必须构建能够应对峰值需求的系统，这个系统在大部分时间是空闲的，这就导致了严重的资源浪费和成本上升。在微服务架构中，服务需要一直运行，实际上在高负载情况下每个服务都不止一个实例，这样才能完成高可用性；在Serverless架构下，服务将根据用户的调用次数进行计费，按照云计算pay-as-you-go原则，如果没有东西运行，你就不必付款，节省了使用成本。同时，用户能够通过共享网络、硬盘、CPU等计算资源，在业务高峰期通过弹性扩容方式有效的应对业务峰值，在业务波谷期将资源分享给其他用户，有效的节约了成本。

「简化设备运维」：在原有的IT体系中，开发团队即需要维护应用程序，同时还要维护硬件基础设施；Serverless架构中，开发人员面对的将是第三方开发或自定义的API 和URL，底层硬件对于开发人员透明化了，技术团队无需再关注运维工作，能够更加专注于应用系统开发。

「提升可维护性」：Serverless架构中，应用程序将调用多种第三方功能服务，组成最终的应用逻辑。目前，例如登陆鉴权服务，云数据库服务等第三方服务在安全性、可用性、性能方面都进行了大量优化，开发团队直接集成第三方的服务，能够有效的降低开发成本，同时使得应用的运维过程变得更加清晰，有效的提升了应用的可维护性。

「更快的开发速度」：这一点在现在互联网创业公司得到很好的体现，创业公司往往开始由于人员和资金等问题，不可能每个产品线都同时进行，这时候就可以考虑第三方的Baas平台，比如使用微信的用户认证、阿里云提供的RDS，极光的消息推送，第三方支付及地理位置等等，能够很快进行产品开发的速度，把工作重点放在业务实现上，把产品更快的推向市场。

但ServerLess架构也有其缺点：

「厂商平台绑定」：平台会提供Serverless架构给大玩家，比如AWS Lambda，运行它需要使用AWS指定的服务，比如API网关，DynamoDB，S3等等，一旦你在这些服务上开发一个复杂系统，你会粘牢AWS，以后只好任由他们涨价定价或者下架等操作，个性化需求很难满足，不能进行随意的迁移或者迁移的成本比较大，同时不可避免带来一些损失。Baas行业内一个比较典型的事件，2016年1月19日Facebook关闭曾经花巨额资金收购的Parse，造成用户不得不迁移在这个平台中产生一年多的数据，无疑需要花费比较大的人力和时间成本。

「成功案例比较少，没有行业标准」：目前的情况也只适合简单的应用开发，缺乏大型成功案例的推动。对于Serverless缺乏统一的认知以及相应的标准，无法适应所有的云平台。

目前微服务架构在四种架构中处于主流地位，很多应用第一、第二种架构的企业也开始慢慢转向微服务架构。到「目前为止微服务的技术相对于二三年前已经比较成熟，第四种架构将是未来发展的一种趋势。」

分布式架构是指将系统的各个组件和服务分布在多台独立的计算机节点上，通过网络进行通信和协作，以实现高性能、高可用性和可伸缩性的系统架构。

分布式架构在现代计算系统中发挥着重要的作用，其主要功能和作用包括：

1.提高性能

分布式架构将系统的负载分布到多个节点上，可以实现并行处理和负载均衡。

通过并行处理，系统可以同时处理多个请求或任务，提高系统的处理能力和响应速度。

2.提高可用性

分布式架构通过将系统的服务和数据分布在多个节点上，实现了冗余备份和故障恢复机制。

即使某个节点发生故障，其他节点仍然可以继续提供服务，确保系统的可用性，通过增加节点的数量，可以进一步提高系统的可用性和容错性。

3.实现可伸缩性

分布式架构可以根据负载变化自动扩展或缩减节点的数量，实现系统的可伸缩性。

当负载增加时，可以动态添加更多节点来分担压力，当负载减少时，可以缩减节点数量以降低成本。

4.支持大规模数据处理

分布式架构可以处理大规模的数据集和复杂的计算任务，通过将数据分布在多个节点上，可以实现数据的并行处理和分布式计算。

分布式架构分类

常见的分布式架构包括微服务架构、分布式数据库系统、分布式存储系统等。

1.微服务架构

微服务架构的核心要素在于服务的发现、注册、路由、熔断、降级、分布式配置。

比如：以Spring Cloud为代表的微服务框架，都会实现以上的微服务组件。

目前国内企业使用的微服务架构：主要是：

Spring Cloud
Spring Cloud Alibaba
ServiceMesh这三套

Spring Cloud体系包含如下：

Spring Cloud Alibaba是阿里研发的一套微服务架构的落地技术方案，可以很好的兼容SpringCloud，可以简要理解为Spring Cloud的升级版。

Spring Cloud Alibaba体系包含如下图所示：

Service Mesh，是一个形象化的词语表达：Service（服务）和Mesh（网格），它描述了服务间的依赖形态，就像下面这张网一样。

2.分布式数据库

分布式数据库，从名字上可以拆解为：分布式+数据库，由多个独立实体组成，并且彼此通过网络进行互联的数据库，这就是分布式数据库。

市面上分布式数据库产品分成几大类：

1.物联网方向

时序数据库产品，满足IoT数据的收集、存储和统计，常见的有：InfluxDB、Kudu、kdb、OpenTSDB等。

2.交易关系方向

替代传统交易关系型数据库产品Oracle，DB2等满足不了海量吞吐、海量并发、海量交易、海量存储的在线交易业务场景。

例如：

蚂蚁金服Oceanbase；
腾讯TDSQL；
热璞HotDB；
中兴GoldenDB等；

3.分析关系方向

解决结构化数据存储和数据分析的业务场景，不过这块收到KV分析型产品巨大的冲击。

常见的有：

Greenplum；
Vertical；
Gbase8a等；

4.KV分析方向

Hadoop、Spark是当下的基石，国内国外较多公司都是在其基础上再做二次研发，尤其是实现兼容SQL标准语法。

5.KV文档方向

解决在线文档类型的非结构化数据存储、数据处理，都在努力兼容SQL标准语法。

常见的有：

MongoDB;
巨衫SequoiaDB等；

6.HTAP方向

随着分布式数据库的发展，我们又迎来了新的一次融合，那就是 OLTP 与 OLAP 将再一次合并为 HTAP（融合交易分析处理）数据库。

常见的分布式数据库有：

谷歌Spanner
谷歌F1；
CockroachDB；
国内TiDB；

3.分布式存储系统

常见的分布式文件系统包括：HDFS、Ceph、GlusterFS、FastDFS等。

1.HDFS

HDFS，全称Hadoop Distributed File System ，HDFS是Hadoop生态系统中的分布式文件系统，用于存储海量数据和支持大规模数据处理。

2.Ceph

Ceph是一种分布式存储系统，具有高可扩展性、高可靠性和高性能等特点。

Ceph架构，如下图所示：

3.GlusterFS

GlusterFS是一种基于用户空间的分布式文件系统，可以将多个服务器或节点组成一个文件系统。

4.分布式计算

分布式计算是指，利用多个计算机或处理器共同处理一个计算任务。

将任务分解为多个子任务，由不同的计算机或处理器分别处理这些子任务，最后将处理结果进行合并，从而完成整个计算任务的过程。

有很多分布式计算产品可供选择，以下是一些常见的分布式计算产品：

1.Apache Hadoop

一个开源的分布式计算平台，用于处理大规模的数据集，它采用分布式文件系统和MapReduce计算模型，适用于大数据处理和分析。

2.Apache Spark

Spark是一个开源的快速通用的分布式计算引擎，支持高级数据分析和机器学习，它采用内存计算和弹性分布式数据集，适用于实时数据处理和复杂的计算任务。

3.TensorFlow

一个开源的机器学习框架，支持分布式计算和GPU加速，适用于深度学习和其他复杂的数学计算任务。

4.Apache Flink

一个开源的流处理和批处理框架，支持分布式计算和低延迟数据流处理，适用于实时数据处理和批处理任务。

5.Apache Storm

一个开源的分布式实时计算系统，适用于实时数据处理和流数据分析。

6.Amazon EC2

亚马逊云计算服务中的一种，提供弹性计算、存储和网络服务，支持多种计算实例类型，包括分布式计算实例，适用于大规模计算和分析任务。

5.分布式通信

分布式通信是指分布式系统中各个节点之间进行数据交换和协作的过程。

比如：典型的RPC框架就是典型的分布式通信。

RPC框架比较出名的有google的gRPC，facebook的thrift，也及阿里的Dubbo。

Dubbo主要包含如下几个核心组件：

Thriftt是一个RPC框架(RPC是远程过程调用)，与Dubbo类似，最初由Facebook开发，后面进入Apache开源项目。

Thrift架构，如下图所示：

gRPC由Google开发的高性能RPC框架，使用Protocol Buffers进行序列化，支持多种编程语言。

6.负载均衡

负载均衡是一种在计算机网络和系统架构中使用的技术，用于均衡分发工作负载到多个资源，比如：服务器、计算节点或存储设备上，以提高系统的性能、可伸缩性。

如下图所示：

负载均衡主要分为：二层、三层、四层、以及七层负载均衡。

1.二层负载均衡（mac）

根据OSI模型分的二层负载，一般是用虚拟mac地址方式，外部对虚拟MAC地址请求，负载均衡接收后分配后端实际的MAC地址响应）。

2.三层负载均衡（ip）

一般采用虚拟IP地址方式，外部对虚拟的ip地址请求，负载均衡接收后分配后端实际的IP地址响应。

3.四层负载均衡（tcp）

四层的负载均衡就是基于IP 端口的负载均衡，在三次负载均衡的基础上，用ip port接收请求，再转发到对应的机器。

实现四层负载均衡的软件有：

F5：硬件负载均衡器，功能很好，但是成本很高。
lvs：重量级的四层负载软件
nginx：轻量级的四层负载软件，带缓存功能，正则表达式较灵活
haproxy：模拟四层转发，较灵活

4.七层负载均衡（http）

七层的负载均衡，就是基于虚拟的URL或主机IP的负载均衡，根据虚拟的url或IP，主机名接收请求，再转向相应的处理服务器。

实现七层负载均衡的软件有：

haproxy：天生负载均衡技能，全面支持七层代理，会话保持，标记，路径转移；
nginx：只在http协议和mail协议上功能比较好，性能与haproxy差不多；
apache：功能较差
Mysql proxy：功能尚可。

总的来说，一般是lvs做4层负载；nginx做7层负载。

7.分布式安全

分布式架构需要考虑数据和通信的安全性，安全机制包括身份认证、访问控制、数据加密、安全传输协议等，以保护数据的机密性、完整性和可用性。

8.分布式事务

分布式事务是指涉及多个计算机，或进程的一系列操作，这些操作需要保证在所有节点上的一致性和原子性。

如下图所示：

上图一次大的事务操作，由不同的小事务操作组成，这些小事务的操作分布在不同的服务器上，这些操作要么全部成功，要么全部失败。