微服务架构——独立系统的架构原则（ISA）

最新推荐文章于 2024-09-26 22:36:16 发布

wanglei1598

最新推荐文章于 2024-09-26 22:36:16 发布

阅读量590

点赞数 1

分类专栏：微服务文章标签：微服务

本文链接：https://blog.csdn.net/wanglei1598/article/details/124059347

版权

微服务专栏收录该内容

8 篇文章 0 订阅

订阅专栏

ISA: Independent Systems Architecture

独立系统架构微服务原则

Introduction

ISA (Independent Systems Architecture) is a collection of best practices based on experience in particular with microservices and Self-contained Systems and the challenges faced in those projects.

Far too often microservices are adopted but the projects then fail to succeed. This set of best practices ensures that common pitfalls are avoided and the promised benefits of microservices are achieved.

However, ISA principles don’t always apply - see the FAQ for details.

Speaker Deck PowerPoint

Terms

The principles use “must” for aspects that cannot be compromised about and must be present in the system. “Should” is used in principles that have a lot of benefits, but can be left out in some cases. The principles described here talk about a system. Usually the IT landscape of an enterprise contains many systems. Each system might be built with a different set of principles or maybe even a completely different approach.

Principles

The system must be divided into modules that provide interfaces. Access to other modules is only possible through these interfaces. Therefore modules must not directly depend on implementation details of other modules, e.g. the internal data representation in a database. The rest of the principles define how modules might be implemented, and how ISA differs from other modularization approaches.
The system must have two clearly separated levels of architectural decisions:
- The Macro Architecture comprises decisions that cover all modules. All further principles are part of the Macro Architecture.
- The Micro Architecture considers decisions which may be taken individually for each module.
Modules must be implemented as separate processes, containers, or virtual machines to maximize independence and enable a separation between Macro and Micro Architecture.
The choice of integration and communication options must be limited and standardized for the system. The integration might be done with synchronous or asynchronous communication, and/or on the UI level. Communication must use a limited set of protocols like RESTful HTTP or messaging. It might make sense to use just one protocol for each integration option.
Metadata, e.g. for authentication, must be standardized. Otherwise the user would need to log in to each microservices. This might be done using e.g. a token that is transferred with each call / request. Other examples might include a trace id to track a call and its dependent calls through the microservices.
Each module must have its own independent continuous delivery pipeline. Tests are part of the continuous delivery pipeline so the modules must be tested independently.
Operations should be standardized. This includes configuration, deployment, log analysis, tracing, monitoring, and alerting. There might be exceptions from the standard if a module has very specific requirements.
Standards for operations, integration, or communication should be enforced on the interface level. For example, the communication protocol and data structures could be standardized to a specific JSON payload format exchanged using HTTP, but every module should be free to use a different REST library/implementation.
Modules must be resilient. They must compensate unavailable modules or communication problems. They must be able to cope with unexpected shutdowns without losing data or state. It must be possible to move them to other runtime environments (hosts, networks, config etc).

独立系统架构

简介

独立系统架构（ISA，Independent Systems Architecture）是基于经验的最佳实践的集合，特别是微服务和自包含系统以及这些项目所面临的挑战。

通常采用微服务的项目都未能成功。这套最佳实践可确保避免常见的陷阱，并实现微服务所承诺的优势。

但是，ISA原则并不总是适用 - 有关详细信息，请参阅常见问题。

术语

这些原则中对于不能在系统中妥协且必须存在于系统中的方面使用“必须”。“应该”用于具有很多好处的原则，但在某些情况下可以省略。这里描述的原则谈论一个系统。通常在企业的IT环境中会包含许多系统。，每个系统可能使用不同的原则构建，甚至可能采用完全不同的方法。

原则

原则一：模块

模块是一个存在已久的概念，一个系统由多个模块构成。

系统必须分为提供接口的模块。只能通过这些接口访问其他模块。因此，模块不能直接依赖于其他模块的实现细节，例如：数据库中的内部数据表示。其余原则定义了如何实现模块，以及ISA与其他模块化方法有何不同。

长期以来模块化被认为是处理大型复杂软件系统的重要工具。使用术语“模块”重用了这些想法。模块意味着例如：高凝聚力和低耦合作为架构的目标，或单一责任原则。信息隐藏也意味着任何其他模块都不得访问数据和数据库。因此，没有必要明确说明这些想法。

原则二：宏架构和微架构（The Micro Architecture）

系统必须具有两个明确分离的架构决策级别：

宏架构包含涵盖所有模块的决策。所有进一步的原则都是宏架构的一部分。

微架构考虑可以针对每个模块单独进行的决策

这里提出的架构允许大量自由。但是，所有模块仍然需要显示为一个整体。因此需要在宏架构层面上做出一些决策。一经定义，宏和微架构清楚地说明了在哪个级别上必须决定什么。目标是在宏架构级别上尽可能少地定义，以便在没有充分理由的情况下不受限制。并非每个细节都应在宏架构中定义。此外，宏架构应该专注于从长远来看相当稳定的决策，而微架构决策则不那么稳定。宏架构影响所有模块，因此更难改变。所以不应该过于频繁地改变它。

原则三：容器

模块必须作为单独的进程，容器或虚拟机实现，以最大限度地提高独立性并实现宏架构和微架构之间的分离。

将模块分成进程，容器或虚拟机允许如每个模块在不同平台上以不同的编程语言实现。因此，技术决策仅针对一个模块。此外，这种分离意味着每个模块都可以在没有任何其他模块崩溃的情况下崩溃。如果所有模块只是一个过程的一部分，那么这将是不同的。这有助于弹性能力。

原则四：通信集成

必须对系统的集成和通信选项的选择进行限制和标准化。可以使用同步或异步通信，并且/或者在UI级别上进行集成。通信必须使用一组有限的协议，如：RESTful HTTP或消息传递。为每个集成选项使用一个协议可能是有意义的。

模块被划分为多个进程。因此无法使用本地方法调用集成它们，但需要不同的集成方法。标准意味着创建真正的系统。如果每个模块的集成方式均不相同，则很难将集成结果视为一个系统。乍看似乎只有一种融合方式就足够了。但事实上，集成通常会在UI层和逻辑层上完成。这已经需要两种不同类型的集成。在同一系统中可能存在不同的情况，例如，同步和异步集成可能很有用。通信定义了模块用于交互的底层协议。当然，通信和集成之间存在关联。但是例如REST允许同步和异步集成。与集成一样，一种通信选择可能还不够。对于通信和集成，原则仅考虑系统内模块之间的通信。与其他系统的通信可以使用一组不同的集成和通信技术来完成。有时，通信和集成已经定义，因此系统无法更改。系统的公共接口也不同于架构的观点：更难于更改，因为更改将影响其他系统。

原则五：身份认证&元数据

元数据，例如对于身份认证，必须标准化。否则，用户需要登录每个微服务。这可以使用例如：与每个调用/请求一起传输的令牌。其他示例可能包括跟踪调用的跟踪ID及其通过微服务的相关调用。

用户不必登录每个模块，而是登录到整个系统。因此，传输身份验证信息（包括主体及其角色）也是标准化的一部分。授权与领域逻辑密切相关，应该在每个模块中完成。因此，每个模块都可以允许访问或特定操作。除认证信息之外的其他元数据也可能需要标准化。例如，跟踪微服务之间的调用，必须传输调用和所有相关调用的唯一ID。

原则六：独立的持续交付流水线

每个模块必须有自己独立的持续交付流水线。测试是持续交付流水线的一部分，因此模块必须独立测试。

只有每个模块都可以自行部署，才能实现真正的独立性。架构只是一个先决条件。换句话说：如果架构允许独立模块，但它们仍然需要作为一个整体进行部署，那么该方法仅提供所需独立性的一部分，但仍然需要花费大量精力。在某些情况下，存在共享集成测试阶段。每个模块最终传播到此阶段并进行独立测试，即所有其他模块必须等到该模块通过集成测试阶段。这是部署流水线中的依赖性瓶颈的示例：在模块通过阶段之前，其他流水线无法继续。必须避免这种情况，例如通过使用消费者驱动的契约测试和通过Mock来测试模块之间的接口，或通过分离集成测试阶段。

原则七：标准化运维

运营应该标准化。这包括配置，部署，日志分析，跟踪，监控和告警。如果模块有非常具体的要求，标准可能会有例外。

每个模块都是一个单独的进程、容器或虚拟机。运维部门必须处理每一项问题，因此面临着巨大的挑战。标准化有助于应对这种复杂性。但是，可能仍然存在具有特殊要求的服务，这些服务可能使用不同的操作方法。另外：在“You build it - you run it”组织中，每个团队都应该负责选择最适合它们的操作方法。大多数情况下，这仍然是一种标准化方法，因为这会减少团队的工作量。请注意，该标准仅涵盖该技术。当然，每个模块可能都有自己的一组指标，告警等。ISA需要高度成熟的运维：大多数运维程序必须自动化。必须处理许多模块。缺乏这种成熟度可能会导致无法成功实施ISA。