Ref: https://insights.thoughtworks.cn/common-architecture-design/

前言

Thoughtworks 作为一家全球软件及咨询公司，每天需要面对各行各业的客户，接触各种各样的系统，因此我们经常需要对新的系统进行架构的设计、对遗留系统进行架构的分析和改造，本文就架构设计这一块，聊一聊架构设计通常都包含哪些内容，并通过一些示例分享，方便大家更加直观的感受。
image.png
架构，又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计，通俗一点说就是 “构建一个架子”。
一个架构是系统的基本结构，它由多个组件以及它们彼此间的关系而组成，并且在一定环境和原则下进行设计和演变。
当我们谈到架构的时候，一般是指两种类型的架构：业务架构和 IT 架构，业务架构关注于业务侧，IT 架构关注于技术侧。IT 架构和技术架构必须紧密联系，通过业务架构来指导 IT 架构的设计，IT 架构最终也必须服务于业务。本文会就业务架构和 IT 架构，以及 IT 架构中常用到的应用架构、数据架构、技术架构、基础设施架构等内容给出具体的设计方法和示例分享。
image.png

业务架构

业务架构用于定义商业策略、管理、组织和关键业务流程，它可以用来告诉业务人员我们的系统可以支持哪些业务，也可以用来指导技术人员针对这些业务设计出相应的技术方案。
业务架构包括业务规划、业务模块、业务流程，对业务进行拆分，对领域模型进行设计，最后把现实的业务抽象出来。
因此设计一个良好的业务架构不但能够减少业务人员和技术人员之间的沟通成本，还能够让业务人员大致了解到未来进行大的业务变更时需要付出的成本，在需求侧进行更加合理的规划。

如何设计

通常可以使用一套方法论（如：DDD 领域驱动模型）对项目需求进行业务边界划分，总体原则是对业务进行拆分、划分出业务边界，比如做一个电商网站，你需要把商品、订单、会员、仓库、采购、支付等业务边界很清晰的划分出来，然后规划出这些业务的周边支持。另外，在设计业务架构的时候不需要考虑技术方案的实现，诸如使用什么技术栈、怎样划分微服务、如何搭建基础设施等。

示例分享

下图是一个虚构的电商平台业务架构示例，包含的主要模块有 “运维基础设施”、“三方服务依赖”、“基础服务”、“核心业务”、“运营支持” 和 “销售平台”，其中 “核心业务” 是重点，需要对业务进行拆分、划分出业务边界。
image.png

IT 架构

IT 架构是支持企业业务运营的一整套信息系统的架构，用于指导 IT 投资和设计框架，因此它不是特定的一种架构，而是一整套架构的集合。IT 架构包含的内容有很多，一般项目上常用的有：应用架构、数据架构、技术架构、基础设施架构，通过这些不同维度、不同层次的架构来展现出整个 IT 系统的设计框架。

应用架构

应用架构描述了设计和构建应用的模式与技术，体现了 IT 系统功能和技术实现的内容。应用架构包含前端和后端服务，前端开发事关应用的用户体验，而后端开发则侧重于提供对数据、服务及其他现有系统的访问，以确保应用正常工作。应用架构细分下来也有很多种，这里介绍四种比较常用的架构：单体架构、微服务架构、事件驱动架构和 SOA 架构。

  • 单体架构：是很多遗留系统的架构模式，一个应用中包含所有功能，属于紧耦合的，更新或扩展单体式应用的某一方面会对整个应用及其底层的基础架构产生影响，对应用代码的任何更改都需要重新发布整个应用。
  • 微服务架构：是我们现在采用较多的一种架构模式，微服务采用分布式、松耦合结构，它们之间不会相互影响，可以按需扩展或部署单个服务，也可以让不同的开发团队各自维护自己的服务，而不是更新整个应用，从而减少开发时间和增加发布频率。
  • 事件驱动架构 (EDA)：是一种以事件为媒介，实现组件或服务之间最大松耦合的方式。事件驱动不同于传统的面向接口编程，调用者和被调用者不需要知道对方，两者只和中间消息队列耦合，在我们很多项目中其实都使用到了消息中间件（如 RabbitMQ、Kafka）来实现事件驱动。

  • SOA 架构：是一种粗粒度、松耦合服务架构，将应用构建为可重复使用的离散型服务，这些服务会通过企业服务总线（ESB）进行通信，微服务其实本质上也属于 SOA 架构。

    如何设计

    在设计新项目的应用架构或评估遗留项目的应用架构时，首先要确定企业或产品的战略目标，然后再设计支持该目标的应用架构，而不是先选择应用架构再尝试来适应它，另外还需要考虑应用的发布频率、开发团队和运维团队的结构等客观因素。应用架构的设计并不只是一个单纯的技术问题，以微服务为例，自从微服务架构开始流行之后，单体架构似乎就不太受人待见，好像 “单体” 就比较 low，而 “微服务” 就显得高大上。但你试想一下，在一个只有 3~5 个人员的开发团队中开发一个中小型应用时，如果只是为了追求技术先进而选择微服务架构，带来的问题可能远多于收获，如系统复杂度更高、开发测试成本更高、运维要求更高等，不能 “为了微服务而微服务”。
    我们可以尝试通过一种通用的表达方式来描绘应用的架构，既能用来指导设计微服务架构，在单体架构下也能方面我们更好的拆分各个模块、理解各个功能之间的关联，这种通用的方式可以使用分层模型来实现，通过各个层次的内容来描绘整个应用，一般可分为基础设施层、数据存储、中间件、基础服务层、业务服务层、UI 层。

    示例分享

    下图是一个虚构的电商平台应用架构示例，通过 “基础设施”、“数据存储”、“中间件”、“基础服务层”、“业务服务层” 和 “UI 层” 等不同的层次，描绘了 IT 系统功能和技术实现的内容。
    image.png

    数据架构

    在大数据时代，数据的地位越来越重要，数据成了很多企业的核心资产，数据架构也应运而生。数据架构是对存储数据（资源）的架构，在设计时需要考虑系统的业务场景，需要根据不同的业务场景对数据进行异构设计、数据库读写分离、分布式数据存储策略等。数据架构包含的元素有：数据源、数据集成、数据存储、计算和调度等。

    如何设计

    数据架构的设计可参考以下原则：

  • 统一数据视图，保证数据的及时性、一致性、准确性和完整性

  • 数据和应用分离，应用系统只依赖逻辑数据库，不直接访问其他应用的数据库，只能通过接口访问
  • 数据异构，在源数据和目标数据内容相同时做索引异构，在商品库不同维度的内容不同时（如订单数据中的买家库和卖家库）做数据库异构

  • 数据库读写分离，将访问量大的数据库做读写分离，将数据量大的数据库做分库分表，将不同业务域的数据库做分区隔，设置主从数据库备份，合理使用 NoSQL 数据库

    示例分享

    下图是一个虚构的电商平台数据架构示例，展示了不同业务系统中数据的不同存储方式和应用场景。
    image.png
    ETL 全称 Extract Transform Load，用来描述将数据从来源端经过抽取 (Extract)、转换 (Transform)、加载 (Load) 至目的端的过程，常用于数据仓库中。
    数据集市是数据层仓库的一个子集，是为了满足特定的部门或者用户需求，按照多维的方式进行存储，包括定义维度、需要计算的指标、维度的层次等，生成面向决策分析需求的数据立方体。

    技术架构

    技术架构简单来说就是从技术的视角来来描述整个系统，列举出实现整个系统所需要使用到的主要技术框架，包含开发语言、平台、组件和依赖库、开源或商用软件等。

    如何设计

    技术架构的边界相对来说比较模糊，详细程度也不尽相同，在设计时可以参考应用架构的方式，通过分层模型（如持久层、数据层、业务逻辑层、应用层、表现层等），列举出每层使用到的主要技术框架（如 Spring Boot、JPA、Postgres、Redis、Kafka 等），确保在设计阶段对技术选型有一个整体的把控。 另外，针对在开发阶段和运维阶段所需要使用的工具和框架也可以体现在技术架构的设计中。

    示例分享

    下图是一个虚构的电商平台技术架构图示例，展现了 “基础设施”、“数据存储”、“基础服务”、“业务服务”、“网关” 和 “UI” 层等使用到的具体技术和服务，也包含了从 “开发平台” 到 “运维平台” 使用到的各种技术和工具。
    image.png

    基础设施架构

    基础设施架构是指运行和管理企业 IT 环境所需的组件，可以部署在云计算系统中，也可以部署在企业自己的本地服务器中，这些组件包括硬件、软件、网络组件、操作系统（OS）和数据存储，它们共同提供了各种 IT 服务和解决方案。基础设施架构可以分为传统基础设施架构和云基础设施架构。

  • 传统基础设施架构：在遗留系统采用较多，所有组件（如数据中心、数据存储及其他设备）由企业自己所有和管理，运行成本相对较高，并且需要大量的硬件（如服务器、网络设备）以及相应的物理空间。

  • 云基础设施架构：在现代应用中采用较多，可以使用专有资源来自行构建私有云，也可以通过云提供商（如阿里、Amazon、Google 或 Microsoft）提供的服务来使用公有云，还可以创建混合云。
    普通的开发人员可能对传统的基础设施架构接触较少，但得益于现在越来越多的项目部署在云上，团队中的技术人员都可以去了解项目中的云基础设施架构，在一些小型项目上可能没有专门的 devOps，基础设施的架构直接是由 dev 来负责，进行云基础设施的架构设计和部署。

    如何设计

    良好的基础设施架构需要考虑到高性能存储、低网络延迟、安全性、高可用和高并发等重要的非功能性需求，在网络、网关、服务器和数据库等多个层级 / 维度进行设计。

    示例分享

    下图是一个基于 AWS 云平台的基础设施架构的示例：
    image.png
    对上图示例中各个 AWS 组件的说明：

  • Route53：Amazon Route 53 是一种高度可用且可扩展的云域名系统（DNS） Web 服务，用于将终端用户路由到 Internet 应用程序。

  • WAF：Web 应用程序防火墙服务，可通过根据您指定的条件来允许或阻止 Web 请求，帮助保护 Web 应用程序免遭常见 Web 漏洞的攻击，这些漏洞会影响应用程序可用性、降低安全性或占用过多资源。
  • S3 Bucket：Amazon Simple Storage Service（Amazon S3）是一种对象存储服务，可提供行业领先的可扩展性，数据可用性，安全性和性能。上述示例中用于托管前端静态代码。
  • CloudFront：Amazon CloudFront 是一项快速的 CDN 服务，可在以低延迟，高传输速度安全地向全球客户交付数据、视频、应用程序和 API。上述示例中通过 CloudFront 来访问托管在 S3 上的前端静态页面。
  • VPC：Virtual Private Cloud (VPC) ，它是仅适用于个人专属 AWS 账户的虚拟网络。
  • Internet Gateway：Internet 网关是一种横向扩展、冗余且高度可用的 VPC 组件，支持在 VPC 和 Internet 之间进行通信。Internet 网关有两个用途，一个是在 VPC 路由表中为 Internet 可路由流量提供目标，另一个是为已经分配了公有 IPv4 地址的实例执行网络地址转换 (NAT)。
  • API Gateway：一项完全托管服务，使开发人员能够轻松地创建、发布、维护、监控和保护任何规模的 APIs。
  • Application Loader Balancer：一项 Web 服务，它可将传入流量分布到两个或多个 EC2 实例，以提高应用程序的可用性。ALB 最适合 HTTP 和 HTTPS 流量的负载平衡，并提供针对现代应用程序体系结构交付的高级请求路由，包括微服务和容器。Application Load Balancer 根据请求的内容将流量路由到 Amazon VPC 内的目标。
  • Availability Zone：可用区，一般可以将应用程序部署在多个可用区，当一个可用区发生故障时自动将流量切到另一个可用区，提高系统的可用性。
  • Public Subnet：公有子网，该子网有通向 Internet 网关的路由，流量能够被路由到 Internet 网关。
  • Private Subnet：私有子网，该子网没有通向 Internet 网关的路由，流量不能被路由到 Internet 网关。
  • NAT Gateway：网络地址转换网关， NAT 网关允许私有子网中的实例连接到 Internet 或其他 AWS 服务，但阻止 Internet 发起与这些实例的连接。
  • Auto Scalling：弹性伸缩，一项完全托管的服务，可以快速查找作为指定应用程序一部分的可扩展 AWS 资源并配置动态扩展。
  • ECS：Elastic Container Service 是一项完全托管的容器编排服务。
  • EKS：Elastic Kubernetes 服务可以灵活地在 AWS 云或本地中启动，运行和扩展 Kubernetes 应用程序。
  • RDS：Relational Database Service 关系型数据库服务可以轻松在云上设置、操作和调整关系型数据库的规格大小，同时自动执行了耗时的管理任务，例如硬件供应、数据库设置、修补和备份。它使您可以将精力集中在应用程序上，从而为它们提供所需的快速性能，高可用性，安全性和兼容性，提供了 6 种数据库引擎：Amazon Aurora、PostgreSQL、MySQL、MariaDB、Oracle Database 和 SQL Server。
  • ElastiCache：Amazon ElastiCache 允许无缝设置、运行和扩展开源的缓存数据库（如 Redis、Memcached），通过从高吞吐量和低延迟的内存中数据存储中检索数据，构建数据密集型应用程序或提高现有数据库的性能。

    最后

    本文通过从业务架构到 IT 架构，以及 IT 架构下的应用架构、数据架构、技术架构和基础设施架构的介绍，配合一些示例的展示，描绘了架构设计中一般包含哪些内容。有些架构可能在某种程度上有重叠的部分，比如技术架构和应用架构，但他们的差异点也很明显：技术架构在设计时会考虑到具体的技术选型，需要列出使用到的技术栈和框架，提供具体的技术实现方案；应用架构介于业务架构和技术架构之间，不需要列出具体使用到某一个技术栈，主要职责在于描绘出系统的功能。
    上面介绍的这些常用的架构类型都是以方块的形式描述的，相对简单明了，还有一种方式是使用带有连接线和方向的形式来描述，如用于软件架构的 C4 模型。除此之外还会有一些其他的架构类型，如微前端架构、Service Mesh 架构、Hadoop 架构等，我们可以根据项目的实际情况按需使用。另外需要强调的是，架构的设计应该在满足业务的基础上尽可能简单明了，追求小而美、而非大而全，避免过度设计。
    诚然，就像 “世界上没有完全相同的两片树叶” 一样，也很难有完全一样的业务和用户，所以很难在不同的系统间套用完全一样的架构，更多的是套用通用的架构设计方法和思想。
    此外，架构虽然是在项目初期设计的，但并不意味着无法改变，没有一劳永逸的架构设计，架构也需要根据业务规模、技术迭代、组织架构的变化而不断演进，正如 “这个世界一直在变，唯一不变的就是变化”。