微服务与SOA

yolo_sec

于 2022-01-29 12:24:39 发布

阅读量826

点赞数

分类专栏：学架构摘要文章标签：微服务 soa

本文链接：https://blog.csdn.net/m0_60725291/article/details/122690255

版权

37 篇文章 2 订阅

订阅专栏

微服务与SOA的关系

关于 SOA 和微服务的关系和区别，大概分为下面几个典型的观点：

微服务是 SOA 的实现方式(X)

如图这种观点认为 SOA 是一种架构理念，而微服务是 SOA 理念的一种具体实现方法。例如，微服务就是使用 HTTP RESTful 协议来实现 ESB 的 SOA
微服务是去掉 ESB 后的 SOA(X)

如图这种观点认为传统 SOA 架构最广为人诟病的就是庞大、复杂、低效的 ESB，因此将 ESB 去掉，改为轻量级的 HTTP 实现，就是微服务
微服务是一种和 SOA 相似但本质上不同的架构理念（✓）

如图这种观点认为微服务和 SOA 只是有点类似，但本质上是不同的架构设计理念。相似点在于图中交叉的地方，就是两者都关注服务，都是通过服务的拆分来解决可扩展性问题。本质上不同的地方在于几个核心理念的差异：是否有 ESB、服务的粒度、架构设计的目标等。

整体上来说，SOA 的服务粒度要粗一些，而微服务的服务粒度要细一些。例如，对一个大型企业来说，员工管理系统就是一个 SOA 架构中的服务；而如果采用微服务架构，则员工管理系统会被拆分为更多的服务，比如员工信息管理、员工考勤管理、员工假期管理和员工福利管理等更多服务。

SOA 采用了 ESB 作为服务间通信的关键组件，负责服务定义、服务路由、消息转换、消息传递，总体上是重量级的实现。微服务推荐使用统一的协议和格式，例如，RESTful 协议、RPC 协议，无须 ESB 这样的重量级实现。

SOA 对服务的交付并没有特殊要求，因为 SOA 更多考虑的是兼容已有的系统；微服务的架构理念要求快速交付，相应地要求采取自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践。

SOA 更加适合于庞大、复杂、异构的企业级系统，这也是 SOA 诞生的背景；
微服务更加适合于快速、轻量级、基于 Web 的互联网系统，这类系统业务变化快，需要快速尝试、快速交付；

SOA 和微服务本质上是两种不同的架构设计理念，只是在服务这个点上有交集而已，且两者并不存在孰优孰劣，只是应用场景不同而已

服务划分过细，单个服务的复杂度确实下降了，但整个系统的复杂度却上升了，因为微服务将系统内的复杂度转移为系统间的复杂度了。
从理论的角度来计算，n 个服务的复杂度是 n×(n-1)/2，整体系统的复杂度是随着微服务数量的增加呈指数级增加的，如下图：

一个简单的需求开发需要涉及多个微服务，微服务之间的接口很多，无论是设计、开发、测试、部署，都需要工程师不停地在不同的服务间切换。
对于必须要拆分的情况，在服务数量增多后，需要基础设施跟上，如持续继承，自动化测试，自动化部署等服务治理，否则还不如不拆分来的更可靠。

微服务之间一般是通过 HTTP 或者 RPC 调用的，每次调用必须经过网络，一个请求经过过多服务调用会增加响应时间，对于高性能场景可能就不好满足，通过改善硬件设施，又会增加成本。

系统拆分为微服务后，一次用户请求需要多个微服务协同处理，任意微服务的故障都将导致整个业务失败。然而由于微服务数量较多，快速定位到底是哪个微服务故障是一件复杂的事情。
如果多个微服务同时发生不同类型的故障，则定位故障更加复杂。

如果没有相应的自动化系统进行支撑，都是靠人工去操作，那么微服务不但达不到快速交付的目的，甚至还不如一个大而全的系统效率高。

随着微服务种类和数量越来越多，如果没有服务治理系统进行支撑，微服务提倡的 lightweight 就会变成问题:

服务路由：假设某个微服务有 60 个节点，部署在 20 台机器上，那么其他依赖的微服务如何知道这个部署情况呢？
服务故障隔离：假设上述例子中的 60 个节点有 5 个节点发生故障了，依赖的微服务如何处理这种情况呢？
服务注册和发现：同样是上述的例子，现在我们决定从 60 个节点扩容到 80 个节点，或者将 60 个节点缩减为 40 个节点，新增或者减少的节点如何让依赖的服务知道呢？

如果以上场景都依赖人工去管理，整个系统将陷入一片混乱，最终的解决方案必须依赖自动化的服务管理系统。

--------来源《极客课程》∙ 学习摘要

关注