微服务架构与传统单体架构的对比

本文主要是介绍微服务架构与传统单体架构的对比，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

好记忆不如烂笔头，能记下点东西，就记下点，有时间拿出来看看，也会发觉不一样的感受。

一、概述

说起微服务，在程序界，可算是当下相对火爆的词，那么微服务到底是什么？与传统的服务有什么区别，为什么要使用微服务呐？

需要指出的是：微服务架构并不是为了拆分而拆分，真正的目的是通过对微服务进行水平扩展解决传统的单体应用在业务急剧增长时遇到的问题，而且由于拆分的微服务系统中专业的人做专业的事，人员和项目的职责单一、低藕合、高内聚，所以产生问题的概率就会降到最小。

二、微服务架构描述

先看看微服务的架构图，看看当前火的微服务架构图：

从图得出如下结论：
· 微服务把每一个职责单一的功能放在一个独立的服务中。
· 每个服务运行在一个单独的进程中。
· 每个服务有多个实例在运行，每个实例可以运行在容器化平台内，达到平滑伸缩的效果。
· 每个服务有自己的数据存储，实际上，每个服务应该有自己独享的数据库、缓存、消息队列等资源。
· 每个服务应该有自己的运营平台，以及独享的运营人员，这包括技术运维和业务运营人员：每个服务都高度自治，内部的变化对外透明。
· 每个服务都可根据性能需求独立地进行水平伸缩。

三、传统架构描述

先看看传统架构图，粗略看看传统架构的实现方式：

从上图可以得到如下结论：

·传统单体架构将所有模块化组件混合后运行在同一个服务口而4 进程中。
· 可对包含多个模块化组件的整体川岛f 进程进行水平扩展，而无法对某个模块化组件进行水平扩展。
· 某个模块化组件发生变化时，需要所有的模块化组件进行编译、打包和上线。

· 久而久之，模块间的依赖将会不清晰，互相糯合、互相依赖成为家常便饭。

通过对比来看，微服务架构更灵活并且可水平伸缩，可以让专业的人来做专业的事。

四、微服务架构与 SOA 服务化的对比

我们看到微服务架构的一些特点与 SOA 服务化架构相似，事实上微服务架构与 SOA 服务化架构并不冲突，它们一脉相承，微服务架构是服务化架构响应特定历史时期的使用场景的延续，是服务化进行升华井落地的一种实现方式。 SOA 服务化的理念在微服务架构中仍然有效，微服务在 S OA 服务化的基础上进行了演进和叠加，形成了适合现代化应用场景的一个方法论。微服务架构与 S OA 服务化虽然一脉相承，却略有不同，如下所述。

1. 目的不同
• SOA 服务化涉及的范围更广一些，强调不同的异构服务之间的协作和契约，并强调有效集成、业务流程编排、历史应用集成等，典型代表为 Web Service 和 ESB 。

·微服务使用一系列的微小服务来实现整体的业务流程，目的是有效地拆分应用，实现敏捷开发和部署，在每个微小服务的团队里，减少了跨团队的沟通，让专业的人做专业的事，缩小变更和法代影响的范围，并达到单一微服务更容易水平扩展的目的。

2 . 部署万式不同

· 微服务将完整的应用拆分成多个细小的服务，通常使用敏捷扩容、缩容的 Docker 技术来实现自动化的容器管理，每个微服务运行在单一的进程内，微服务中的部署互相独立、互不影响。
• SOA 服务化通常将多个业务服务通过组件化模块方式打包在一个 War 包里，然后统一部署在一个应用服务器上。

3. 服务植度不同

· 微服务倡导将服务拆分成更细的粒度，通过多个服务组合来实现业务流程的处理，拆分到职责单一，甚至小到不能再进行拆分。

• SOA 对粒度没有要求，在实践中服务通常是粗粒度的，强调接口契约的规范化，内部实现可以更粗粒度。

由此可见，微服务和传统服务的架构特点差别还是很大的，而微服务的特点也更加的突出，再我们选择系统架构的时候，还是要抛弃传统的架构模式，选择向微服务靠拢，从而实现更加灵活多变的系统。

欢迎拍砖！