系统架构系列,四种常见系统架构介绍

系统架构系列,四种常见系统架构介绍

软件架构是软件的基本结构。

适当的架构是软件成功的最重要因素之一。大型软件公司通常有专门的架构师职位（架构师），只有高级程序员才能填补。

如果软件开发者不了解软件架构的演进，就会限制技术的选择和开发者的生存和提升空间。在这里我列出了四种主要的软件架构及其优缺点，希望能帮助软件开发者扩展知识。

一、单体架构

单体架构比较初级，典型的三层架构，前端（Web/移动端）+中间业务逻辑层+数据库层。这是一个典型的 Java Spring mvc 或 Python Drango 框架应用程序。架构图如下：

单体架构的应用相对容易部署和测试。在项目的早期，单体应用程序可以很好地运行。然而，随着需求的不断增加，越来越多的人加入了开发团队云计算分布式系统，代码库也在膨胀。慢慢的，单体应用越来越臃肿，可维护性和灵活性逐渐下降，维护成本越来越高。以下是单体架构应用程序的一些缺点：

高复杂度：以一个百万行的单体应用为例，整个项目包含大量模块，模块边界模糊，依赖关系不清晰，代码质量参差不齐，杂乱无章。可以想象，整个项目非常复杂。每次修改代码，哪怕是添加一个简单的功能，或者修复一个bug，都会带来隐含的缺陷。

技术债务：随着时间的推移，需求会发生变化，人员也会发生变化，应用程序的技术债务会不断增加和积累。 “不要破坏，不要修复”在软件开发中很常见，在单体应用程序中更是如此。使用的系统设计或代码很难修改，因为应用程序中的其他模块可能会以意想不到的方式使用它。

低部署频率：随着代码的增长，构建和部署时间也会增加。在单体应用程序中，每个功能更改或错误修复都会导致需要重新部署整个应用程序。全量部署方式耗时长、影响范围大、风险大，使得单个应用项目上线部署频率低。部署频率低也导致两个版本之间有大量的功能变更和bug修复，错误率比较高。

可靠性差：应用程序中的一个bug，如死循环、内存溢出等，可能会导致整个应用程序崩溃。

有限的可扩展性：单个应用程序只能作为一个整体进行扩展，不能根据业务模块的需要进行扩展。例如，应用程序中的某些模块是计算密集型的，需要强大的 CPU；有些模块是 IO 密集型的，需要更大的内存。由于这些模块是一起部署的，因此必须在硬件选择上做出妥协。

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

二、分布式应用程序

中间架构，分布式应用，中间层分布式+数据库分布式，是单一架构的并发扩展，将一个大的系统分为多个业务模块，业务模块部署在不同的服务器上，并且各个业务模块通过接口交换数据。数据库也使用了大量的分布式数据库，如redis、ES、solo等。通过 LVS/Nginx 代理应用，将用户请求的负载均衡到不同的服务器上。其架构图如下：

与单一架构相比，该架构提供了负载均衡的能力，大大提高了系统的负载能力，满足网站的高并发需求。此外，还有以下特点：

降低耦合度：拆分模块，使用接口通信，降低模块之间的耦合度。

职责明确：将项目划分为多个子项目，不同的团队负责不同的子项目。

易于扩展：添加功能时，只需添加另一个子项目，调用其他系统的接口即可。

易于部署：可以灵活地进行分布式部署。

提高代码的复用性：比如在服务层，如果不采用分布式REST服务架构，手机wap商城、微信商城、pc、android的每一端都会写一个服务，和ios层逻辑系统架构系列,四种常见系统架构介绍，开发量大，很难一起维护和升级。这时候可以使用分布式的rest服务方式来共享一个服务层。

缺点：系统间交互需要使用远程通信，接口开发增加工作量，但利大于弊。

三、微服务架构

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

易于开发和维护：微服务只会专注于特定的业务功能，因此业务清晰，代码量少。开发和维护单个微服务相对简单。整个应用由多个微服务构建而成，因此整个应用也会保持在可控状态。

单个微服务启动速度更快：单个微服务代码少，启动速度会更快。

部分修改易于部署：只要修改了单个应用程序系统架构系列，就必须重新部署整个应用程序。微服务解决了这个问题。一般来说，修改一个微服务，只需要重新部署该服务即可。

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

微服务尽管有很多吸引力，但并不是免费的午餐，使用它们是有代价的。使用微服务架构的挑战。

运维要求更高：服务越多，运维投入越大。在单体架构中，只需启动并运行一个应用程序。在微服务中，需要保证几十个甚至上百个服务的正常运行和协作系统架构系列，给运维带来了很大的挑战。

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

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

重复工作：许多服务可能使用相同的功能，但此功能尚未分解为微服务。这时候每个服务都可能开发这个功能，导致代码重复。虽然可以使用共享库来解决这个问题（例如，可以将功能封装到一个公共组件中，供需要该功能的微服务引用），但共享库不一定能在多语言环境中工作。

四、无服务器架构

当我们还在容器的浪潮中，一些革命先驱者悄悄地部署了另一个云计算战场：无服务器架构。

2014 年 11 月 14 日，亚马逊 AWS 发布了新产品 Lambda。在当时，Lambda被描述为：一个按时间运行用户代码的计算服务，无需关心底层计算资源。从某种意义上说，Lambda 早就该了。就像云计算的PaaS概念：客户只关心自己的业务，不关心存储和计算资源。不久前，2014 年 10 月 22 日，谷歌收购了实时后端数据库初创公司 Firebase。 Firebase声称开发者只需要参考一个API库文件就可以使用标准REST API的各种接口来读写数据，并且只需要编写HTML+CSS+JavaScript前端代码，无需服务端代码（如果集成是必需的，也非常简单）。

与上述两者相比，Facebook 于 2014 年 2 月收购的 Parse 专注于提供通用的后台服务。这些服务称为无服务器或无服务器。考虑 PaaS（平台即服务）？就像，用户不需要关心基础设施，他们只需要关心业务。这是一个后期的PaaS，也是比较实用的PaaS。这很可能会改变整个开发过程和传统的应用程序生命周期。一旦开发者习惯了云上资源的自动创建和分配，他们可能永远无法回到那些需要微应用配置资源的地方。时间已经过去了。

Serverless 架构让开发者在构建应用的过程中无需关注计算资源的获取和运维。平台按需分配计算资源，保证应用执行的SLA（Service Level Agreement）。呼叫次数计费，有效节省应用成本。 ServerLess的架构如上图所示。其优点如下：

低运营成本：在业务突发极高的场景下，为了应对业务高峰，系统必须构建能够应对高峰需求的系统。闲置，导致资源严重浪费，成本上升。在微服务架构中，服务需要一直运行。实际上，在高负载的情况下，每个服务都有多个实例系统架构系列,四种常见系统架构介绍，这样就可以实现高可用；计算即用即付原则，如果没有运行，则无需付费，节省使用成本。同时，通过共享网络、硬盘、CPU等计算资源，用户可以在业务高峰期通过弹性扩容有效应对业务高峰期，在业务低谷期与其他用户共享资源，有效节约成本。

简化设备运维：在原有的IT系统中，开发团队需要同时维护应用程序和硬件基础设施；在 serverless 架构中，开发者将面临第三方开发或自定义 API 和 URL，底层硬件对开发者是透明的，技术团队不再需要专注于运维工作，可以更专注于应用系统开发。

提高可维护性：在无服务器架构中，应用会调用各种第三方功能服务，形成最终的应用逻辑。目前，登录认证服务、云数据库服务等第三方服务在安全性、可用性、性能等方面都得到了很大的优化。开发团队直接集成第三方服务，可以有效降低开发成本，让应用运行流畅。维护流程更加清晰，有效提高了应用的可维护性。

更快的开发速度：这在当前的互联网创业公司中得到了很好的体现。创业公司往往从人员、资金等问题入手，不可能每条产品线同时开发。可以考虑第三方Baas平台，比如微信用户认证、阿里云RDS、极光消息推送、第三方支付和地理位置等，可以快速开发产品，专注业务。在实施方面，更快地将产品推向市场。

但无服务器架构也有其缺点：

Vendor 平台绑定：该平台将向大玩家提供 Serverless 架构，例如 AWS Lambda，并且运行它需要使用 AWS 指定的服务，例如 APIs Gateways、DynamoDB、S3 等。一旦您开发了一个复杂的在这些服务系统上，你会坚持使用 AWS，未来你将不得不让他们涨价或退市。难以满足个性化需求，不能随意迁移或迁移成本比较大，一些损失在所难免。 Baas 行业的典型事件，2016 年 1 月 19 日，Facebook 关闭了巨资收购的 Parse，导致用户不得不迁移在这个平台上产生的数据一年多，这无疑需要很多的人力和时间。成本。

成功案例少，没有行业标准：现状只适合简单的应用开发，缺乏大规模成功案例的推广。 serverless缺乏统一的认知和相应的标准，无法适应所有云平台。

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

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!