SCS(- )架构介绍

SCS(- )架构介绍

SCS(- )架构介绍

SCS(- )架构定义与特性

• 自主Web应用：SCS是一个自主的Web应用程序，包含Web UI、逻辑和持久化层。这种完整性确保了一个用户故事通常可以通过修改一个SCS来实现。
• API的可选性：SCS可以有一个服务API，但这并非必需。如果SCS内的逻辑仅由SCS内的UI使用，则无需API。
• 无共享UI：SCS之间不应共享UI，以避免紧密耦合和不必要的复杂性。

1. SCS与微服务的关系：

• 类似但更精确：SCS与微服务在可独立部署和解耦方面相似，但SCS的定义更为精确，通常粒度更粗。
• 单个功能实现：SCS确保一个功能仅在一个SCS中实现，从而通过单一部署即可将其投入生产。

2. Bounded Context与DDD：

• Bounded Context：每个SCS应实现一个Bounded Context，通过用户故事分组来找到这些Bounded Context。
• 用户故事与旅程：通过用户故事和用户旅程来确定SCS的划分，每个步骤或需求可能是一个SCS的候选。

3. SCS的沟通与交互：

• UI集成：UI集成是首选的SCS间沟通方式，包括JavaScript转码、ESI和SSI等技术。
• 异步与同步通信：异步通信（如事件和消息传递）是推荐的沟通方式，同步通信则作为最后手段。

4. 团队与所有权：

• 单一团队拥有：每个SCS由单一团队拥有，确保团队可以独立工作，并减少协调需求。

5. 技术优势与限制：

• 技术优势：SCS提供了高开发生产力和低技术复杂性，因为它们通常是传统的Web应用程序。
• 限制：SCS主要适用于Web系统，且可能需要对前端开发有一定的技能要求。

6. 实际应用与案例：

• Otto案例：Otto等大型电商公司采用SCS架构，证明了其在复杂Web应用中的有效性。

7. 迁移与实现难度：

• 迁移挑战：如果现有架构依赖于不同的方法，迁移到SCS架构可能具有挑战性。
• 实施要求：对Web应用程序的深入理解是实现SCS架构的重要前提。

单体

微服务

SCS

为什么自包含系统 （SCS） 比微服务更具优势：

更广泛的范围：SCS 具有更广泛的范围，包括边界上下文中的 UI、业务逻辑和数据存储
降低运营复杂性：由于管理许多较小的、相互依赖的服务，微服务可能会导致高水平的运营复杂性，而 SCS 更重要、更自主。
数据一致性：SCS 管理其数据，从而在每个系统内实现更好的数据一致性，而微服务通常依赖于共享数据存储。

使用SCS架构优势

1. 自治 - 每个 SCS 都独立运行，具有其数据库、业务逻辑和用户界面。
2. 领域对齐 - SCS 围绕特定的业务领域构建，确保每个单元代表一组连贯且有意义的功能。
3. 去中心化数据管理 - 每个 SCS 的单个数据库确保其边界内的数据一致性，减少跨服务依赖性。
4. 技术多样性 - 允许在其他 SCS 中使用不同的技术堆栈，以满足每个领域的特定需求。
5. 显式发布的接口 - 定义明确的接口，用于与其他系统的交互，在保持封装的同时保持清晰的契约。
6. 独立可部署性 - 每个 SCS 都可以独立部署、扩展和更新，而不会影响其他系统。

结论

SCS是一种微服务架构的实践方法，它通过将系统划分为自主的Web应用程序（SCS），实现了高度的解耦和独立部署。SCS强调每个SCS实现一个Bounded Context，并通过UI集成和异步通信等方式保持低耦合。SCS适用于复杂的Web系统，并提供了高开发生产力和低技术复杂性的优势。然而，其实现需要对Web应用程序有深入的理解，并且迁移到SCS架构可能具有挑战性。

今天先到这儿，希望对AIGC，云原生，技术领导力， 企业管理，系统架构设计与评估，团队管理, 项目管理, 产品管理，信息安全，团队建设 有参考作用