转载

独立系统架构

独立系统架构

简介

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

独立系统架构

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

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

术语

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

原则

原则一:模块

模块是一个存在已久的概念,一个系统由多个模块构成。 独立系统架构

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

独立系统架构

原则二:宏架构和微架构(The Micro Architecture)

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

  • 宏架构 包含涵盖所有模块的决策。 所有进一步的原则都是宏架构的一部分。 独立系统架构
  • 微架构 考虑可以针对每个模块单独进行的决策。 独立系统架构

原则三:容器

独立系统架构

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

原则四:通信集成

独立系统架构

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

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

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

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

独立系统架构

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

原则七:标准化运维

独立系统架构

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

原则八:标准化

独立系统架构

应在接口级别强制执行运维,集成或通信的 标准化 。 例如,通信协议和数据结构可以标准化为使用HTTP交互的特定JSON有效载荷格式,但每个模块应该可以自由使用不同的REST库/实现。

原则九:弹性

模块必须具有 弹性

  • 它们必须对不可用的模块或通信问题进行补偿。
  • 它们必须能够应对意外停机而不会丢失数据或状态。 独立系统架构
  • 必须可以将它们移动到其他运行时环境(主机,网络,配置等)。 独立系统架构

其他原则

ISA(独立系统架构)是最佳实践的集合。 但是ISA没有定义完整的体系结构。 以下内容介绍了不属于ISA的其他原则以及它们被忽略的原因。

ISA定义了模块技术层面的内容。但系统如何拆分为模块超出ISA的范围。 领域驱动设计 和 限界上下文 是很好的指导原则。 但有时技术模块需要因为可扩展性等原因的分离也很重要。 正确拆分为模块非常困难,因此不能轻易地将其放在一些原则中。

架构可以产生巨大的组织和文化影响。 该方法允许更好的分离模块,允许独立,自组织的团队。 康威定律 指出,软件架构反映了团队中的社会边界,因此组织与架构之间存在着密切的关系。 但是,ISA在不调整组织结构的场景下工作,因此这种想法可以通过这种方式更广泛地应用。

ISA不偏好通信协议或运维技术。 它陈述了一般原则,而不是具体的技术决策。

遵循这些原则可提供独立可扩展性,负载平衡和高可用性等优势。 然而,这些好处是遵循原则的结果而非原则本身,所以它们未被明确提及。

这些原则带来了不一致的数据等问题。 这些是分布式系统的基本挑战,需要加以解决。 这超出了ISA的定义。

参考资料

  • https://isa-principles.org/index.html
原文  http://kaelzhang81.github.io/2019/08/30/独立系统架构/
正文到此结束
Loading...