我们
开发系统 而不是
服务的集合。我们使用基于微
服务的
架构来
优化系统的
设计 而不是
设计独立的服务。无论别人怎么说 微服务不能 也永远不会完全解耦 和独立。 *你不能打造用完全独立的组件来打造系统 * 现在我们看下“系统”的定义[7]
1. 一组连接在一起并可一起操作的物件或
设备
2. 一组为了一个特定目的一起使用的计算机
设备或程序
服务会与其他服务进行不断交互来形成系统。如果你通过
优化服务来设计一个系统 却忽略了他们之间的交互 最终你可能是这样的结局
这些“微服务”可能自身很简单 但系统却变成了复杂性的地狱
所以我们如何不只是处理了服务的复杂性 而是也考虑了整个系统的复杂性来进行微服务设计呢
这是个困难的问题 但幸运的是 在很早以前就有答案。
# 系统视角的复杂性
四十年前 还没有云计算 没有全球规模的需求 不需要每11.7秒部署一次系统。但
工程师仍然需要控制系统复杂度。尽管这些工具与现在不一样 但挑战 - 更重要的是 解决
方案 - 都是类似的 也可以被用于基于微服务设计的系统。
在他的书里 “组合/结构设计”[8],Glenford J. Myers讨论了如何用结构化的过程代码来降低复杂度。在书的第一页 他写到
关于复杂性的主题中有比简单的尝试最小化程序中一部分的本地复杂度更重要的事。一个更重要的复杂度类型是全局复杂度 程序或系统的全局结构的复杂度 比如 程序主要部分的关联或独立程度 。
在我们的语境里 *本地复杂度就是每个独立微服务的复杂度 *而*全局复杂度是整个系统的复杂度*。 本地复杂度以来与一个服务的*实现部分* 全局复杂度是被服务间的*交互和依赖*所定义的。
所以哪一个复杂度更重要 - 本地还是全局 让我们看看当只有一种复杂度被关心时的情况。
要将全局复杂度降到最小实际非常简单。我们只要评估下任何系统组件间的交互 - 即 将所有功能在一个单体服务中实现。就像我们早前看到的 这个策略在某些特定场景是有用的。而在其他场景 它会导致恐怖的*大泥球 - 可能是最高级别的本地复杂度。*
从另一方面 我们很清楚当你只优化本地复杂度而忽视系统全局复杂度时会发生什么 - 更大的*分布式大泥团。*
因此 当我们只关注复杂度的某一种 选哪一个并不重要。在一个复杂分布式系统 对向的复杂度都会暴涨。所以 我们不能只优化一个。相反 我们要平衡本地和全局复杂度。
有意思的是 在“组合/结构设计”一书中描述的复杂度平衡不仅与分布式系统有关 其也提供了如何设计微服务的见解。
# 微服务
让我们先从精确定义什么是服务和微服务来开始。
## 什么是服务
根据OASIS标准 [9](https://docs.oasis-open.org/soa-rm/v1.0/soa-rm.html) 一个服务是
通过规定好的
接口提供能访问一种或多种能力的机制
规定好的
接口这部分很重要。服务的接口定义了它暴露给外界的功能。根据Randy Shoup [10](https://www.youtube.com/watch?v E8-e-3fRHBw)的说法 服务的公共接口简单来说就是任何让数据进出服务的机制。它可以是同步化的 如简单的请求/响应模型 或者异步化的 一个
生产事件一个消费事件。不管怎么说 同步或异步化 公共接口只代表让数据进出一个服务。Randy也表达了服务的公共接口就跟**前门**是一样的。
服务是被公共接口定义的 这个定义对于定义什么服务是微服务也足够了。
## 什么是微服务
如果一个服务是被它的公共接口定义的 那么 -
**一个微服务是指一个用了微型公共接口的服务 - 微型前门**
这条在过程式编程中被遵守的规则 如今在分布式系统领域更加有关联性。你暴露的服务越小 它的实现越简单 它的本地复杂性越小。从全局复杂度来看 更小的公共接口会在服务间产生更少的依赖和连接。
微接口的概念也解释了广泛使用的微服务不暴露数据库的实践。没有微服务可以访问另一个微服务的数据库 只能通过其提供的公共接口。为什么 因为 数据库实际是一个巨大的公共接口 只要想想你可以在一个关系数据库上能执行多少种操作。
因此 再重申下 在分布式系统中 我们通过将服务的公共接口最小化的方式来平衡局部与全局复杂度 然后服务就变成了微服务。
## 警告
这听起来很简单但其实不然。如果一个微服务只是有微型公共接口的服务 那我们可以直接将公共接口限制到只有一个方法。由于这个“前门”已经小的不能再小了 这应该是完美的微服务 对吗 为了解释为什么不这么做 我会使用我另一篇博文[11](https://vladikk.com/2018/02/28/microservices/)里的一个例子
加入我们有如下库存
管理服务
如果我们将它拆成八个服务 每个只有一个简单的公共方法 我们可以得到完美的低本地复杂度的服务
但我们能将它们连入系统来真正
管理库存吗 并不行。要形成系统 服务需要与其他服务交互并共享对于每个服务的状态。但它们不行。服务的公共接口不支持。
因此 我们要继承这个“前门”并让这些公共方法可以支持服务间的集成
完了 如果我们通过将每个服务完全独立的方式来优化复杂度 那么解耦的是很彻底。但是 当我们将服务连入系统 全局复杂度又升高了。不只是导致系统卷入了一团乱麻 为了集成 - 继承公共接口也超出了我们原来的意图。引自Randy Shoup 除了
建设了一个小“前门” 我们也建了一个巨大的“员工专用”入口 这告诉我们一个重要的观点
**一个服务有比业务方法更多的集成方法有成长为分布式大泥球的巨大可能 **
因此 一个服务的公共接口可以被最小化到什么程度不只是依赖于服务本身 也取决(主要)于它在系统中是哪一部分。一个微服务何时的解耦应该同时考虑系统的全局复杂度和服务的局部复杂度。
# 设计服务边界
“要找到服务边界太难了... 完全没有流程图!” -Udi Dahan
上面Udi Dahan说的话对于基于微服务的系统来说也很对。设计微服务的边界很难 基本上第一次很难做对。折让设计一个合适复杂度的微服务变成了一个迭代流程。
因此 从更大的边界开始是比较安全的 - 从上下文边界开始比较合适[12](https://vladikk.com/2018/01/21/bounded-contexts-vs-microservices/) - 有更多关于系统各它的业务域的知识后 再将它们解耦成微服务。这对那些包含了核心业务域的服务特别重要[13](https://vladikk.com/2018/01/26/revisiting-the-basics-of-ddd/)。
# 分布式系统之外的微服务
尽管微服务只是最近才被“发明”出来 你仍可以在工业界发现很多有同样设计理念的实现。这些包括
## 跨功能团队
我们知道跨功能团队是最有效的。这种团队让不同专业能力的小组工作在同一个任务上。一个有效的跨功能团队能最大化团队内的交流 最小化团队外的交流。
我们的工业只是最近才发现跨功能团队 但任务组是一直存在的。其底层的原理与基于微服务的系统是一样的 在团队内高聚合 团队间低耦合。团队的“公共接口”通过需要达成任务的技能来进行最小化 如实现的细节 。
## 微处理
我要通过Vaughn Vernon那经典的[相关主题的博文](https://kalele.io/microservices-and-microservices/)来举这个例子。在他的博客里 Vaughn描绘了一个微服务与微处理器间有趣的相似点。他讲述了处理器与微处理器间的不同
我发现了一个通过大小规格来帮助确定一个处理器是中央处理器(CPU)还是微处理器 数据总线[21](https://kalele.io/microservices-and-microservices/)的大小
本文转自网络，原文链接：https://developer.aliyun.com/article/784801
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！
