微服务架构会和分布式Monolith高度重合吗？

对于网络服务来说，首先，前提条件就是要有一个由100+共享库组成的企业级平台，才能确保有能力来运行网络服务，还能够让有权限的网络客户共同讨论构建更强大的微服务（Microservices）。Ben Christensen在最近举办的Microservices Practitioner Summit峰会上分享构建分布式系统经验和微服务趋势的时候如此解释网络服务的要点，尤其是在当前这种对二进制依赖比较强烈的系统正在翻倍增长的情况下，更要搞懂微服务是什么！

不妨在这里简单介绍一下Monolith！网上对微服务进行介绍的文章常常以Monolith作为开头，这里也不例外。原因是，知道了Monolith的不便之后才能更容易地理解微服务架构模式所具有的各种优点。

我们所开发的服务应该都是什么样子呢？通常情况下，这个服务所对应的代码由多个项目所组成，各个项目会根据自身所提供功能的不同具有一个明确的边界。在编译时，这些项目将被打包成为一个个JAR包，并最终合并在一起形成一个WAR包。接下来，我们需要将该WAR包上传到Web容器中进行解压，并重新启动服务器。在执行完这一系列操作之后，我们对服务的编译及部署就已经完成了。

由于按照Monolith组织的代码来运行的话，将只产生一个包含了所有功能的WAR包，因此在对服务的容量进行扩展的时候，我们只能选择重复地部署这些WAR包来扩展服务能力，而不是仅仅扩展出现系统瓶颈的组成。

但是这种扩展方式极大地浪费了资源。比如（上图）：在一个服务中，某个组成的负载已经达到了90%，也就是到了不得不对服务能力进行扩容的时候了。而同一服务的其它三个组成的负载还没有到其处理能力的20%。由于Monolith服务中的各个组成是打包在同一个WAR包中的，因此通过添加一个额外的服务实例虽然可以将需要扩容的组成负载降低到了45%，但是也使得其它各组成的利用率更为低下。可以说，所有的不便都是由于Monolith服务中一个WAR包包含了该服务的所有功能所导致的。而解决该问题的方法就是微服务架构模式。

言归正传，Christensen或许对一些人来说并不陌生，他是Facebook的软件工程师。共享库是运行网络服务必不可少的重要部分，这两者结合起来就被称之为“平台”。比较常见通用的类库包含Spring和Guava，两者通常被用在路由和日志里面。所以说，最后这一系统还是得依靠那100多个类库才能把微服务运行起来。如果一个服务不能和系统进行互动的话，只能说明所有的类库都是可用的，Christensen将这种现象称之为分布式的Monolith。基本上，你在推广所使用的分布式系统的时候，会丢掉很多关于微服务架构的有价值的东西，这些有价值的东西包括“多语言编程”，用Christensen自己的话来说就是，这会让网络服务加大错失接受不同技术、组织结构以及技术解藕的可能性，这样也会阻碍团队在技术层面上的改进升级。

Don’t Repeat Yourself的字母缩写DRY对很多人来说都不陌生，尤其是对开发者。在共享代码的业务逻辑中，孤立的去部署变化条件正在被摒弃，因为这种做法会直接影响服务执行代码的效果。Christensen强调共享代码在服务边界里面是相当完美的，可是一旦泄漏的话，就会有潜在的耦合可能性。Sam Newman在他的新书《Building Microservices》里提到：

服务之间太多的耦合所带来的弊端远超多简简单单复制代码所带来的问题还要严重很多倍。

Christensen认为可替换的方案就是采用契约和协议，服务应该隐藏所有的实现细节，而只将数据契约和网络协议暴露出来。在不依赖服务实现的前提下，用户能够使用任何技术和编程语言，并以自己的速度来发展，这才是网络该做的事情。他指出，虽然在如日志记录，分布式跟踪，路由等领域没有强制的标准化需求，但还是应该启用独立的类库，这样消费者才有权选择是否使用这些网络服务。

Christensen认为，经常性犯这样低级的错误是很容易的，因为我们都知道如何使用使用共享类库，我们也常常在短期内进行优化来达到更高的产出，问题也就是在这个时候产生的。他还指出，虽然推迟解藕的成本较高，可是解决方案也是有的，动动脑经努力在刚开始的时候就把合适的工具放在合适的地方，这样才能物尽所能发挥最大效果。

在最后的问答过程中他认为，使用一个大的框架无可厚非，只要它被当作内部一个独立的服务使用就行，但如果整个系统的架构不采用的话就算了，因为这会导致一个长期的耦合。

微架构或者甚至SOA架构真正发挥所长的地方在于，根据彼此独立部署的逻辑服务，这些逻辑服务可以独立于其他服务进行扩展，而且能够实现独立的故障切换。

红帽公司中间件部门工程副总裁Mark Little博士说：“我在微服务方面担心的问题之一就是，你有一个整体式系统(monolith)，假设你开始把它分解成多个服务，可是分解时很随意，到头来就会分解得过细，最后会有10个、100个甚至1000个微服务。”

“但是这些微服务又彼此高度依赖，以至于如果某一个服务出现故障，其余服务很有可能也会出现故障。这种情况下，你一无所获。你有999个服务就在那里干等着另一个服务恢复正常运行。”

最后，Little认为，那些开始使用微服务的人应该找出未能实现其功能的软件，而不是就因为使用年限而把那些旧软件挑出来。

查看英文原文：Microservices Ending up as a Distributed Monolith