独立系统架构
独立系统架构
简介
独立系统架构（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
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
