02 | 单体系统时代：应用最广泛的架构风格
大型单体系统
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
单体系统架构在软件开发中扮演着重要角色，尽管在微服务兴起后备受质疑，但实际上它仍具有诸多优势。文章首先澄清了单体系统并非一定是“不可拆分”的“巨石系统”，而是可以在纵向和横向上进行拆分和扩展的。从纵向角度看，单体系统可以采用分层架构，实现不同层次的拆分和数据流转传递；从横向角度看，单体系统也可以支持按技术、功能、职责等角度进行模块化拆分，以便重用和团队管理。此外，单体系统在开发、部署、测试等方面也具有便捷性，且可以轻松实现横向扩展以分摊流量压力。 对于小型系统来说，单体系统不仅易于开发、测试、部署，而且由于各功能、模块、方法的调用过程在进程内进行，因此运行效率也高于分布式系统。因此，单体系统并非一定落后于微服务，而是根据软件的性能需求和开发人员规模来选择合适的架构风格。文章强调了单体系统的灵活性和适用性，为读者提供了对单体系统的全面了解和认识。 总的来说，本文通过对单体系统的优势和误区进行了深入探讨，帮助读者更好地理解了单体系统架构的特点和适用场景。文章内容简洁明了，为读者提供了全面的技术视角，使读者能够快速了解单体系统架构的重要性和优势。文章还提到了单体系统的缺陷，如隔离与自治能力上的欠缺，以及在系统规模扩大时的部署成本和技术升级迁移成本的问题。这些观点有助于读者全面了解单体系统的优劣势，为其在实际应用中做出明智选择提供了参考。
请先领取课程
全部留言(64)
- 最新
- 精选
小高单体架构并不是一无是处，在公司的初始阶段，为了业务的快速上线，必须得采用单体架构，随着业务的增长，架构才得以演进，还是那句话，架构不是一层不变的，是持续演进的，或许，微服务也不是终点。作者回复: 这个观点我完全认同。
2020-11-20336
超超不会飞单体架构在“小卖部”阶段很合适，随着“小卖部”越来越大，会被拆分成微服务，而随着微服务的不断迭代，肯定会有某个微服务变成另一个大单体，还是得继续手动拆分，我觉得如果有一种架构可以”自适应“业务的大小，就想前端网页自适应屏幕大小一样，那就非常爽了。作者回复: 小卖部到大超市的过程中，业务需求变得更复杂，算力要求变得更高。 算力需求变得更高这个方面，确实有“自适应”的方案，即目前所说的无服务架构。 业务需求变得更复杂这个方面，涉及到人与技术的管控，这点估计在很长时间内都只能靠开发者自身知识的进化来适配。
2020-11-21220
Frank个人觉得说白了还是单体，比如你做微服务后，每一个服务其实还是单体，还是需要一些单体的理念去看待服务的生命周期等。微服务只不过是在规模大了之后，如何更好的发挥出单体的价值逐渐演化而来。作者回复: 微服务确实可以理解为“一群能够配合良好工作的、关注各自领域的小单体”，或者说它们最终会是殊途同归的。 微服务与单体之间的关注点差异不在于“大与小”，而在于一群小单体“能够配合良好工作”， 这中间涉及到许多既麻烦又不得不去处理的事情。
2020-11-21315
zhanyd单体系统适合小项目，小并发，快速开发的项目。 单体系统应该是朝着越来越简洁，标准化的方向发展，可以单独部署成为一个独立的系统，也可以非常方便的加入微服务体系，成为分布式系统的一部分。 就像一个有完整功能的标准件，能够单独使用，也可以组装成大型机器。作者回复: 这确实是单体的优势，未来单体不会消失。
2020-11-207- 流云老师您好，文中提到单体架构不兼容fenix特性，这句话怎么理解呢？单体架构通过集群方式部署不也是具有一定的可靠性吗
作者回复: 多数生产中的单体系统也会做集群部署，也会有服务冗余，也会进行主从热备。但是这些是运维阶段的“补救措施”，在开发阶段，单体系统是不会考虑也很难去考虑服务崩溃、恢复等弹性措施，也很难去考虑容错、治理等韧性措施的。 举个例子，当你开发单体系统时，会不会在设计期去考虑“一旦程序发生OutOfMemory，该如何处理？”这样的问题？如果真的想过，你是否有什么有效的处理措施？
2020-11-2035 - Geek_15ebb6单体架构对于“小卖部”而言，是特别适用的。但如果“小卖部”越开越大，就要做好向微服务转型的准备。未来的发展方向，我觉得是如何快速，平滑地从单服务到微服务地转换。
作者回复: 随着产品规模的扩大，许多单体都会向微服务发展，但单体本身并不会消失。简单程序、小项目的需求不可能消失，所以单体一定会继续存在。
2020-11-2024 
tt我觉得，单体架构从业务视角来看，是端到端的，一个系统就可以把某个业务流程全部搞定，比如订单、支付、库存，而分布式会把这些业务域拆分到不同的服务中。 单体架构会往哪个方向转变？我觉得会向分布式学习，不会出现巨大的单体了，可能会变成单元式架构。比如以前的缴费业务单体架构是支付、冲正在一起，商户端处理与银行主机端在一起，以后可以变成四个单元，每个都有自己的数据库，然后通过消息队列连接在一起，这样业务逻辑处理简单多了，即一个大单体变成了四个小单体。作者回复: 微服务确实可以理解为“一群能够配合良好工作的、关注各自领域的小单体”，或者说它们最终会是殊途同归的。 微服务与单体之间的关注点差异不在于“大与小”，而在于一群小单体“能够配合良好工作”。
2020-11-203
Wacky小恺我认为未来的单体架构，应该会朝着多个服务冗余负载的方向发展，单体架构的劣势是每当系统某一模块出现问题时会影响其他部分，而排除模块本身设计或实现缺陷之外，是完全可以使用主备切换的方式来快速解决问题的。 因此如果继续采用单体架构，那么我们就应当允许冗余部署，增加服务数量，来提高容错率。作者回复: 主备的想法我赞同。不过今天这样得想法很难说是“未来的发展”了。用于生产的单体系统，无论是为了应对更高的流量，还是为了更可靠的服务，冗余部署都已十分常见。
2020-11-203- STOREFEE如果可以很明显预估到项目的开发规模不会很大，但是对性能要求很高，局部范围需要经常迭代，而且需要多点部署的场景，就非常适合单体架构。 我观察到，凡是和互联网沾边的流行的软件项目基本规模都在不断膨胀，趋向于包罗万象。因为现在很多用户会觉得软件越来越多，去切换不同的东西太麻烦了，有的还得申请账号，填写资料等繁琐的事情。最明显的例子就是石墨和飞书。前几年感觉石墨文档很贴近word, 挺不错的。现在飞书，企业微信等工具整合企业聊天，会议，文档，存储，绘图等等一些列的东西。 这样就是一站式服务，绝对会是采用的非单体架构。
作者回复: 是的
2020-11-281 
尹恒我觉得Serverless是另一个层面的单体啊，只不过把操作系统、运行时换成云基础设施，从开发者的角度，反而更像我们以前写单体程序的感觉了，甚至更单了，连纵向分割都没有了作者回复: Serverless某种意义上就是另一种单体。
2020-11-231