单体服务-微服务-分布式 [三兄弟的区别]

大家好，我是晓星航。今天为大家带来的是 单体服务-微服务-分布式 [三兄弟的区别] 相关的讲解！😊

文章目录

1.单体服务

1.1单体服务架构的基本介绍

单体服务：一种软件开发模型，它将所有的服务组件集成在一个独立的系统单位中进行开发、部署和维护。在这种架构中，前端用户界面、后端服务器逻辑、数据库操作等组件通常紧密耦合在一起，形成一个统一的程序。这种架构模式易于开发和部署，特别是在项目规模较小、复杂度较低的情况下。然而，随着项目规模的扩大、复杂度的增加，单体架构可能会导致应用变得难以维护、扩展和理解。

图解：

1.2单体服务的优缺点

优点：

• 更少的横切问题：与整体架构相关的一个主要优点是你只需要担心一个应用程序的横切问题，例如日志记录或缓存。
• 减少运营开销：将你的业务集中在一个应用程序上，意味着你只需为一个应用程序设置日志记录、监视和测试。由于你不需要进行多个部署，单体应用的部署通常也不太复杂。
• 更容易的测试：使用单体架构，自动化测试更容易设置和运行，因为一切都在同一个屋檐下。对于微服务，测试需要适应不同运行时环境中的不同应用程序——这可能会变得复杂。
• 性能：与微服务相比，单体应用还具有性能优势。这通常归因为使用本地调用而不是跨网络的 API 调用。

缺点：

• 过度紧密的耦合：虽然单体可以帮助你避免前面提到的纠缠，但单体越大，它就越容易受到纠缠。由于一切都如此紧密耦合，单体应用中的服务隔离变得非常困难，使得独立扩展或代码维护变得困难。
• 更难理解：与微服务相比，单体应用更难理解，这一点在新团队成员入职时就会出现。有时，这是紧密耦合的直接结果，而且可能存在依赖性和副作用，当你查看特定服务或控制器时，这些依赖性和副作用并不明显。

2.微服务

2.1微服务架构的基本介绍

微服务：由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。

2.2微服务架构的优缺点

优点：

• 测试容易
• 可伸缩性强
• 可靠性强
• 跨语言
• 协同开发
• 方便系统迭代

缺点：

• 运维成本高，人力成本比较大，部署项目多
• 接口兼容版本问题
• 分布式系统的复杂性
• 分布式事务

3.分布式

分布式和微服务概念类似，我们来说一下它们两者的区别：
微服务：将模块拆分成一个独立的服务单元通过接口来实现数据的交互。简单来说微服务就是很小的服务，小到一个服务只对应一个单一的功能，只做一件事。这个服务可以单独部署运行，服务之间可以通过RPC来相互交互，每个微服务都是由独立的小团队开发，测试，部署，上线，负责它的整个生命周期。

分布式服务：服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。逻辑架构设计完后就该做物理架构设计，系统应用部署在超过一台服务器或虚拟机上，且各分开部署的部分彼此通过各种通讯协议交互信息，就可算作分布式部署，生产环境下的微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的，比如集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用。

关系：分布式只是一种手段，把不同的机器分散在不同的地方，然后这些机器间相互协助完成业务。微服务是一种特殊的分布式，微服务架构是分布式服务架构的子集。微服务架构通过更细粒度的服务切分，使得整个系统的迭代速度并行程度更高，但是运维的复杂度和性能会随着服务的粒度更细而增加。微服务重在解耦合，使每个模块都独立。分布式重在资源共享与加快计算机计算速度。

图解：

4.三兄弟之间的区别

单体服务：传统架构。集所有功能于一身构建一个项目，不可分开部署

分布式：一种部署方式。一定部署在不同的服务器上，其项目功能可以是相同的业务（集群部署），也可以是不同的业务

微服务：一种软件架构。通常是把不同的业务拆分出来做多个服务，可以部署在相同的服务器上，也可以部署在不同的服务器上

感谢各位读者的阅读，本文章有任何错误都可以在评论区发表你们的意见，我会对文章进行改正的。如果本文章对你有帮助请动一动你们敏捷的小手点一点赞，你的每一次鼓励都是作者创作的动力哦！😘