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架构可能具有挑战性。

如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯，请关注我的微信订阅号：

作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 该文章也同时发布在我的独立博客中-Petter Liu Blog。