微服务的反模式和陷阱(三) - 共享反模式

布满荆棘的人生 2022-05-20 06:41 184阅读 0赞

# 前言 #

微服务是一种 **无共享的架构**，另一层意思是 **“尽量不共享”** 模式(`share-as-little-as-possible`)， 因为总有一些 **代码** 会在微服务之间共享。然后如果太过频繁的使用 **共享代码** 最终会出现 **依赖噩梦**，这就是共享反模式。

# 正文 #

## 共享反模式 ##

微服务是一种 **无共享的架构**，另一层意思是 **“尽量不共享”** 模式(`share-as-little-as-possible`)， 因为总有一些 **代码** 会在微服务之间共享。比如 **不提供一个身份验证的微服务**，而是将身份验证的代码打包成一个 `jar` 文件：`security.jar`，保证其它服务都能使用。如果安全检查是 **服务级别** 的功能，每个服务接收到请求都会检查安全性，这种方式可以很好的提高性能。

然后如果太过频繁的使用最终会出现 **依赖噩梦**，如图 `1-1` 所示，其中每个服务都依赖于 **多个自定义共享库**。

![Micro_Service_Non_Share1.png][]

这种共享级别不仅破坏了每个 **服务的限界上下文**，而且还引入了几个问题，包括整体 **可靠性**、**变更控制**、**可测试性** 和 **部署能力**。

### 1. 过多依赖 ###

在面向对象的软件开发过程中，经常会遇到 **共享** 的问题，特别是从 **单一分层** 结构迁移到 **微服务结构** 时，图 `1-2` 展示 **抽象类和共享**，它们最终在多数单块分层体系结构中共享。

![Micro_Service_Non_Share2.png][]

**微服务架构** 的主要目标就是共享要尽可能的少，这有助于维护服务的 **限界上下文**，使我们能够快速的 **测试** 和 **布署**。服务之间 **依赖越强**，**服务隔离** 也就 **越困难**，因此也就越难单独进行 **测试** 和 **布署**。

创建 **抽象类** 和 **接口** 是 **面向对象编程** 的最重要做法，那我们如何来处理数百个服务共享的代码？

### 2. 共享代码的技术 ###

要避免这个 **反模式** 的最好办法就是 **代码不共享**，但是实际工作中总会有一些代码需要进行共享，那这些共享代码应该放到哪里呢？

图 `1-3` 给了四个最基本的技术：

*  共享项目
 *  共享库
 *  复制
 *  服务合并

![Micro_Service_Non_Share3.png][]

## 相关链接 ##

1.  微服务的反模式和陷阱(一) - 数据驱动的迁移反模式
2.  微服务的反模式和陷阱(二) - 超时反模式
3.  微服务的反模式和陷阱(三) - 共享反模式
4.  微服务的反模式和陷阱(四) - 到达报告反模式
5.  微服务的反模式和陷阱(五) - 沙粒陷阱
6.  微服务的反模式和陷阱(六) - 无因的开发者陷阱
7.  微服务的反模式和陷阱(七) - 随大流陷阱
8.  微服务的反模式和陷阱(八) - 其它架构模式
9.  微服务的反模式和陷阱(九) - 静态契约陷阱
10. 微服务的反模式和陷阱(十) - 通信协议使用的陷阱

--------------------

欢迎关注技术公众号： 零壹技术栈

![零壹技术栈][1240]

本帐号将持续分享后端技术干货，包括虚拟机基础，多线程编程，高性能框架，异步、缓存和消息中间件，分布式和微服务，架构学习和进阶等学习资料和文章。

[Micro_Service_Non_Share1.png]: http://ols3fdyll.bkt.clouddn.com/Micro_Service_Non_Share1.png
[Micro_Service_Non_Share2.png]: http://ols3fdyll.bkt.clouddn.com/Micro_Service_Non_Share2.png
[Micro_Service_Non_Share3.png]: http://ols3fdyll.bkt.clouddn.com/Micro_Service_Non_Share3.png
[1240]: /images/20220520/08303dc5195644539f4c0a1d55d26e90.png