什么是Monolith(Monolith vs.Microservices)?


目前有一个强劲的趋势microservice并经常讨论将它们与整体结构进行比较。有很多关于将整体分解成微服务的建议,也有两种模式的支持者之间的一些有趣的斗争--见伟大Microservices vs Monolithic Melee。“独石”一词越来越多地被用作一般性的侮辱,就像'Legacy'是!

然而,我相信,对于什么是‘巨石’有很多误解,而那些讨论它的人经常谈论完全不同的事情。

一个整体可以被认为是一种架构风格或一种软件开发模式(或者反模式,如果您从负面的角度看待它)。样式和模式通常适合于不同的视图类型(一个视图类型是一组或一个类别的视图,可以很容易地相互协调[Clements等人,2010年]),我们可以讨论的一些基本视图类型有:

  • 模块-代码单元及其在编译时的相互关系。
  • 分配-软件到其环境的映射。
  • 运行时-软件元素的静态结构以及它们在运行时如何交互。

一块巨石可以指任何的上面的基本视图类型。


模块整体

如果您有一个模块整体,那么系统的所有代码都在一个单独的代码库中,这些代码库被编译在一起并产生一个单独的工件。代码可能仍然是结构良好的(类和包在源代码级别上是一致的和解耦的,而不是一个大球的泥),但是它没有被拆分成单独的模块进行编译。相反,非单块模块设计可能将代码拆分成多个模块或库,这些模块或库可以单独编译,存储在存储库中,并在需要时引用。这两种方法都有优点和缺点,但是这很少告诉您代码是如何使用的--它主要是为了开发管理而做的。

Module Monolith


配置整块

对于一个分配整体,所有代码都是同时发送/部署的。换句话说,一旦编译的代码“准备好发布”,就会将单个版本发送到所有节点。所有正在运行的组件在任何时间点都有相同版本的软件运行。这与模块结构是否为整体无关。在部署之前,您可能已经一次编译了整个代码库,或者您可能已经从多个源和版本创建了一组部署工件。不管是哪种方式,系统的这个版本都会立即部署到各个地方(通常是停止整个系统,推出软件,然后重新启动)。

非单块分配将涉及在不同时间将不同版本部署到各个节点。这再次独立于模块结构,因为模块整体的不同版本可以单独部署。

Allocation Monolith


运行时整体

运行时整体将由单个应用程序或进程执行系统的工作(尽管系统可能有多个外部依赖项)。传统上,许多系统都是这样编写的(特别是诸如工资单,应付帐款,CMS等业务系统)。

运行时是否为整体与系统代码是否为模块整体无关。如果只有一个主节点/组件要部署,则运行时整体通常意味着分配整体(尽管如果一个新版本的软件在一段时间内跨地区,带着不同的用户推出,则情况并非如此)。

Runtime Monolith

请注意,我上面的例子对于viewType来说是稍微强制的,在现实世界中它不会那么硬和快。

结论

Be very carefully when arguing about 'Microservices vs Monoliths'. A direct comparison is only possible when discussing the Runtime viewtype and properties. You should also not assume that moving away from a Module or Allocation monolith will magically enable a Microservice architecture (although it will probably help). If you are moving to a Microservice architecture then I'd advise you to consider all these viewtypes and align your boundaries across them i.e. don't just code, build and distribute a monolith 它在不同节点上公开自身的子集。