Distributed monolith (分布一体式)是一个幽默的词,用来暗指那些设计欠佳的架构。如果忽略了微服务设计实践,不仅会无法克服一体式带来的缺点,也会导致出现新的、复杂的问题或恶化已存在的问题。当你在自豪地称之为微服务架构的同时,由于设计上缺少足够目的性的,最终的架构与随机爆破而成的碎片没有什么区别。
避免分布一体式的第一步非常简单:避免同时实现微服务。一体式是简单的,因为无需考虑分布式系统存在的复杂性。一个数据库,一个日志存储位置,一个监控系统,更简单的问题定位,以及端到端测试等等。除非你有充分的理由去使用微服务,否则最好采用同样的理念。
本文将主要关注微服务设计中的松耦合的重要性。我将给出一些简单的、可以避免耦合和导致分布一体式架构设计的例子。
微服务中的松耦合?
两个系统中,如果修改任意一方的设计、实现或行为不会对另一方造成影响,则称两个服务是松耦合的。当涉及到微服务时有可能会发生耦合,即对一个微服务的修改,会立即直接或间接地影响到与其他所有微服务的协作。
下面看一些设计中存在耦合的场景。
数据库共享
数据库共享是实现耦合的一种常见方式。当一个服务修改其实现时,会导致修改另外一个服务的实现。
选择数据存储、方案、以及请求的语言等细节应该对客户端不可见,如果共享了数据库,则可能会暴露所有的实现细节。为什么要隐藏实现细节?这是因为如果暴露了实现细节,那么未来对实现细节进行调整时将有可能会导致客户端代码不可用,除非客户端也同步做了相应的修改(这种方式是不可行或不可持续的)。在图1的左侧,Customers 与 Orders共享了数据库,因此Orders可以访问Customers 的数据模