总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 程序猿DD 「DD」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

最近看了 Simon Martinelli 在 Spring I/O 2025 的演讲：《Say Goodbye to Microservices, Say Hello to Self-Contained Systems》（如果英语观看困难的小伙伴，推荐使用Chrome插件「YouTube中文配音」），其中提到了大家在微服务实践过程中的痛点，并引出了新的解决方案：Self-Contained Systems。看到标题，DD还是挺激动的，感觉是个新鲜知识，但是进一步了解之后，又有一些其他感触，跟大家聊一聊。

什么是 SCS（Self-Contained Systems）

对于微服务，相信大家都已经不陌生了，那什么是 SCS（Self-Contained Systems）呢？

SCS是一种将大型系统的功能分离为许多独立协作系统的架构方法。其具备以下特点：

  • 自治：每个SCS都是一个自治的Web应用程序。对于SCS的领域而言，所有数据、处理数据的逻辑以及渲染Web界面的所有代码都包含在SCS内部。一个SCS可以独立完成其主要用例，无需依赖其他系统的可用性。
  • 单一团队：每个SCS由一个团队负责。这并不意味着只有一个团队可以修改代码，但负责的团队对代码库的内容拥有最终决定权，例如通过合并拉取请求（pull-requests）。
  • 异步依赖关系：与其他SCS或第三方系统的通信尽可能采用异步方式。具体来说，其他SCS或外部系统不应在SCS自身的请求/响应周期内被同步访问。这实现了系统解耦，减少了故障影响，从而支持自治性。目标是实现时间上的解耦：即使其他SCS暂时离线，SCS也应能正常工作。即使技术层面的通信是同步的，也可以通过数据复制或请求缓冲等方式实现这一点。
  • API是可选：SCS可以有一个可选的服务API。由于SCS拥有自己的Web UI，它可以直接与用户交互，而无需通过UI服务。不过，为移动客户端或其他SCS提供API可能仍然有用。
  • 自有数据与逻辑：每个SCS必须包含数据和逻辑。要真正实现任何有意义的功能，两者都是必需的。SCS应自行实现功能，因此必须同时包含这两部分。
  • 自有UI：SCS必须通过自己的UI让最终用户能够使用其功能。因此，SCS不应与其他SCS共享UI。SCS之间可能仍有相互链接，但异步集成意味着即使另一个SCS的UI不可用，当前SCS仍应能正常工作。
  • 无共享业务逻辑：为避免紧密耦合，SCS不应与其他SCS共享业务代码。为某个SCS创建拉取请求或使用通用库（如数据库驱动程序或OAuth客户端）可能是可行的。
  • 极少共享基础设施：为使SCS更健壮并改善解耦，可以最大限度地减少共享基础设施的使用。例如，共享数据库会使SCS的故障安全性和可扩展性依赖于中央数据库。不过，出于成本等考虑，为每个SCS使用具有独立模式或数据模型的共享数据库可能是一种有效的替代方案。

SCS 与 微服务的比较

以下是官网的原文（https://scs-architecture.org/vs-ms.html）说明：

SCS 方法与微服务有许多共同的概念，包括通过独立可部署单元来实施隔离、组织边界与架构边界的对齐、对技术选择多样性的支持，以及无集中式基础设施等理念。如果您愿意将这些视为微服务的核心，那么可以将 SCS 视为微服务的一种特殊化形式。但与许多人所认为的微服务关键属性的其他方面相比，两者存在一些重要差异：

  • 微服务的规模可能比 SCS 更小。一个 SCS 的规模可能大到足以让一个团队持续忙碌，并提供更具意义的业务价值。
  • SCS 的数量通常比微服务少。一个逻辑系统（如电商平台）可能包含 5 到 25 个 SCS（例如用于计费、订单处理等），而一个电商平台可能包含数百个微服务。
  • 理想情况下，SCS 之间不应相互通信，而微服务之间的通信则是被允许的。
  • SCS 拥有用户界面（UI），而微服务可能将 UI 与逻辑分离为独立的服务。不过，某些微服务的定义也将 UI 包含在微服务中。
  • SCS 更倾向于在 UI 层进行集成，而微服务通常专注于在逻辑层进行集成（当然，某些微服务的定义也允许在 UI 层集成）。

当然，SCS 也可以进一步拆分，使其由微服务组成（尤其是在业务逻辑层面）。在这种情况下，这可以视为一种特定的微架构方法。

SCS 显然专注于大型项目和多团队拆分，而微服务则可用于其他目的：小团队甚至单个开发者经常使用微服务，例如为了更轻松地实现持续交付、构建更健壮的系统，或对每个微服务进行独立扩展。因此，微服务的用途更为广泛，而 SCS 则专门解决大型项目的架构和组织管理问题。

根据以上内容结合《Say Goodbye to Microservices, Say Hello to Self-Contained Systems》的演讲内容，做了一下整理：

比较维度 微服务（Microservices） SCS（重点中心系统）
拆分粒度 单个服务粒度更小，聚焦单一功能，代码量通常较少。 服务规模更大，承载完整业务模块，需团队协作开发。
服务数量 系统中服务数量众多（如电商平台可能包含数百个）。 服务数量较少（如电商平台通常为5-25个）。
通信机制 允许服务间通过API、消息队列等直接通信。 理想情况下避免服务间直接通信，强调独立性。
UI处理 部分定义中UI与逻辑分离（如独立前端服务），也有定义包含UI。 每个SCS通常包含独立UI，形成完整业务单元。
集成方式 主要通过逻辑层（如API接口）实现服务集成。 更倾向于在UI层（如前端界面）进行集成。
应用场景 适用于小团队、个人开发，或追求持续交付、独立扩展的场景。 专注于大型项目，解决多团队协作的架构与组织管理问题。

小结

在总结完SCS与微服务的比较之后，我的第一感觉是SCS更像是以前我们常说的SOA，他们都有这些特点：

  • 服务规模比微服务更大
  • 服务数量比微服务少
  • 通信主要采用异步（企业总线）
  • 有自己独立的UI，完整的业务，比如：OA系统、财务系统等专业系统
  • 集成方式，比如：前端集成组件、一段JS代码等

所以，个人感觉这里所说的SCS更像迎合目前微服务实践痛点的冷饭热炒？还是缺乏深入探究没有掌握其精髓？

不知道您对SCS是怎么看的呢？欢迎评论区一起聊聊！

参考资料

文章目录
  1. 1. 什么是 SCS（Self-Contained Systems）
  2. 2. SCS 与 微服务的比较
  3. 3. 小结
  4. 4. 参考资料