经典的架构风格及其应用场景

面向对象

• 面向对象架构风格

  面向对象架构风格的核心思想是将现实世界中的事物抽象为对象，对象拥有属性和方法。这些对象之间通过消息传递进行交互，以实现特定的功能。这种架构风格有助于降低系统的复杂性，提高代码的可重用性和可维护性。

• 面向对象的模式

  面向对象模式是在面向对象软件开发中反复出现的问题的解决方案。它们提供了一种通用的设计思路，有助于开发人员快速构建高质量的软件系统。面向对象模式主要分为三类：创建型模式、结构型模式和行为型模式。

• 创建型模式

  创建型模式主要涉及对象的创建过程，包括工厂方法模式、抽象工厂模式、单例模式、建造者模式和原型模式。这些模式有助于管理对象的创建过程，提高代码的可扩展性和灵活性。

• 结构型模式

  结构型模式关注如何将对象组合成更大的结构，包括适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式和享元模式。这些模式有助于降低系统的耦合度，提高代码的可重用性和可扩展性。

• 行为型模式

  行为型模式主要关注对象之间的通信和职责分配，包括策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式和解释器模式。这些模式有助于提高系统的灵活性和可扩展性，使系统更易于维护和扩展。

面向过程

SOA

微服务

微服务指的是一种应用架构，其中的一系列独立服务通过轻量级 API 来进行通信。

微服务架构是一种云原生的软件构建方法，允许应用内的每个核心功能都独立存在。

• 单体式架构与微服务架构

  传统的应用构建方法专注于单体式架构。在单体式架构中，一个应用内的所有功能和服务都锁在一起，作为一个单元来运行。以任何方式对应用进行增添或改进时，其架构会变得愈加复杂。这使得在不拆开整个应用的前提下，优化应用中的任何单一功能变得更加困难。这也意味着，如果应用中的一个进程需要扩展，那么整个应用也都必须扩展。

• 面向服务的架构与微服务架构

  微服务架构是面向服务的架构（SOA）的一种演进。这两种方法的相似之处在于，它们都将庞大、复杂的应用分解为更易处理的较小组件。由于它们的相似性，人们经常将 SOA 和微服务架构相混淆。二者的主要区别是它们的范围：SOA 是一种企业级的架构方案，而微服务则是应用开发团队的一种实施策略。

  在微服务架构中，应用中的每一核心功能独立运行。这样，开发团队可以构建和更新新的组件，以满足不断变化的业务需求，而不必中断整个应用。

• 微服务架构的优势

  • 开发周期

    微服务可通过分布式部署，大幅提升您的团队和日常工作效率。您还可以并行开发多个微服务。这意味着更多开发人员可以同时开发同一个应用，进而缩短开发所需的时间。

  • 高度可扩展

    随着某些服务的不断扩展，您可以跨多个服务器和基础架构进行部署，充分满足自身需求。

  • 出色的弹性

    只要确保正确构建，这些独立的服务就不会彼此影响。这意味着，一个服务出现故障不会导致整个应用下线，这一点与单体式应用模型不同。

  • 易于部署

    相对于传统的单体式应用，基于微服务的应用更加模块化且小巧，所以您无需为它们的部署操心。虽然对部署时的协作要求更高（服务网格可以辅助这一过程），但之后能获得巨大回报。

  • 易于访问

    由于大型应用被拆分成了多个小型服务，所以开发人员能够更加轻松地理解、更新和增强这些服务，从而缩短开发周期，尤其是在搭配使用敏捷开发方法时，例如 DevOps。

  • 更加开放

    由于使用了多语言 API，所以开发人员可以根据需要实现的功能，自由选用最适合的语言和技术。

• 微服务的潜在挑战

  微服务带来的灵活性可能会引发部署新变更的热潮，意味着新模式的诞生。在软件工程中，“模式”是指任何已知奏效的算法解决方案。“反模式”是指犯下的常见错误，本意是为了解决问题，但从长远来看可能会造成更多问题。

  除了文化和流程之外，复杂性和效率问题是基于微服务的架构所面临的另外两大挑战。在使用微服务架构时，警惕这些常见的反模式非常重要。

  扩展：扩展软件生命周期开发过程内的任何功能，都可能带来挑战，尤其是在初期。在初始设置期间，重要的是要花时间识别服务之间的依赖关系，并且注意可能破坏向后兼容性的潜在触发因子。到了部署的时候，对自动化的投入至关重要，因为微服务的复杂性使人工部署变得无能为力。

  日志记录：使用分布式系统时，您需要利用集中式日志将所有相关信息集中到一处。否则，积累的日志数量将让您难以招架。

  监控：您必须通过一个集中式视图来了解整个系统的情况，以便找出问题的根源。

  调试：无法通过本地集成开发环境（IDE）进行远程调试，因为这种方式无法涵盖数十个或数百个服务。不幸的是，关于应该如何进行调试，目前还没有标准答案。

  连接：请考虑使用服务探索功能，无论是集中式的还是集成式。

• 支持微服务的工具和技术

  • 容器和 Kubernetes

    容器是一种软件单元，其中应用代码与运行应用所需的所有文件打包在一起。这种结构让您可以在不同环境之间轻松迁移容器化应用，同时还可保留应用的全部功能。

    Kubernetes 作为一个容器编排平台，可在不影响其余技术堆栈的情况下更新应用中的单个组件，因此非常适合用于实现微服务应用的自动化管理、扩展和部署。

  • API

    应用程序编程接口（API）是应用中负责与其他应用通信的部分。在微服务架构的基础架构中，API 发挥至关重要的作用，促使微服务中的不同服务能够共享信息并作为一个整体来运行。

  • 事件流

    微服务服务中发生的任何事情都可被定义为事件。例如，有人向他们的在线购物车中添加或删除商品时。

    多个事件形成事件流，反映系统行为的不断变化。通过监控事件，企业可以得出有关数据和用户行为的有用结论。事件流处理允许立即采取行动，可以实时直接作用于运行的工作负载。 公司可以将事件流应用于从欺诈分析到机器维护等所有方面。

  • 无服务器计算

    无服务器计算是一种云原生开发模型，让开发人员能够构建和运行应用，同时由云提供商负责置备、维护和扩展服务器基础架构。开发人员可以简单地将代码打包到容器中进行部署。应用是从底层基础架构中抽象而来，因此无服务器可以帮助企业加快创新。

架构设计中的质量属性设计、质量属性提升策略

可用性

性能

安全性

可修改性

可测试性

易用性

架构评估的过程、方法和技术

评估过程

评估工作按照时间的先后顺序可以分为五个阶段即：评估分析阶段、评估设计阶段、信息获取阶段、评估综合分析阶段、评估报告阶段。

评估方法

• 基于调查问卷

  组织相关人员进行评估，这种方式最简单易行，但是主观性强

• 基于度量

  强调量化指标，最客观，但是这种方式实施难度大，因为需要评估者对系统非常熟悉，不然很难量化清楚各项指标

• 基于场景

  • 软件架构分析法(SAAM)

    最初用于分析架构可修改性，后扩展到其他质量属性。软件架构分析法分为6个步骤：1、形成场景；2、描述架构；3、对场景进行分类和确定优先级；4、对场景进行单个评估；5、评估场景的交互作用；6、形成总体评价。

  • 架构权衡分析法(ATAM)

    在SAAM的基础上发展起来的，主要针对性能、可用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。整个评估过程强调以质量属性作为评估核心。分为4个阶段：1、场景和需求收集；2、架构视图和场景实现；3、质量模型构造和分析；4、质量模型折中。

评估技术

架构的建模和描述方式

根据建模的侧重点不同，可以将软件架构模型分为结构模型、框架模型、动态模型、过程模型和功能模型。Kruchten在1995年提出了“4+1”视图模型，将5种模型有机的统一在一起。 “4+1”视图模型从5个不同的视角来描述软件架构，每个视图只关心系统的一个侧面，所有视图结合在一起才能反映系统的软件结构的全部内容。这5个不同的视角包括逻辑视图、开发视图、进程视图、物理视图和场景。

• 逻辑视图

逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。在该视图中，系统分解成一系列功能的抽象，这些抽象主要来自问题领域。在面向对象技术中，通过抽象、继承和封装，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。

• 开发视图

该视图也称为模块视图，在UML中被称为实现视图。它主要侧重于软件模块的组织和管理，要考虑软件内部的需求。

• 进程视图

该视图侧重于系统的运行特性，主要关注一些非功能性需求，并且强调并发性、分布性、系统集成性和容错能力，以及逻辑视图中功能抽象如何适应进程结构等，并定义了逻辑视图中的各个类的操作具体是在哪一个线程中被执行。进程视图可以描述成多层抽象，每个级别分别关注不同的方面。

• 物理视图

该视图在UML中被称为部署视图，主要考虑如何把软件映射到硬件上，它通常要考虑解决系统拓扑结构、系统安装和通信问题。

• 场景

场景可以看做是那些重要系统活动的抽象，使4个视图有机联系起来，它对应UML中的用例视图。