Microservice架构模式简介

本文选自1 月 5 日最受欢迎文章 Top 3，作者 loveis715，感谢 雨旸 分享。

欢迎分享：http://toutiao.io/contribute

在2014年，Sam Newman，Martin Fowler在ThoughtWorks的一位同事，出版了一本新书《Building Microservices》。该书描述了如何按照Microservice架构模式设计及搭建一个具有良好扩展性并可持续开发的系统。除此之外，该书还将基于该模式的系统演化流程与Continuous Delivery等当前甚为流行的开发流程结合在了一起，使得Microservice架构模式看起来非常具有吸引力。基于这些原因，该架构模式迅速被业界所熟知，并在多个产品中被尝试着使用。这其中就包含了我们公司的产品vRA。

在这一年多的时间里，我们不但真正地体会到了Microservice所具有的一系列优点，也犯过一系列错误。因此在这篇文章里，我会对Microservice架构模式进行简单地介绍，并将我们所得到的经验和教训介绍给大家。

Monolith

网上对Microservice进行介绍的文章常常以Monolith作为开头，我也不会例外。原因是，知道了Monolith的不便之后才能更容易地理解Microservice架构模式所具有的各种优点。

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

这种将所有的代码及功能都包含在一个WAR包中的项目组织方式被称为Monolith。在项目较小的情况下，这种代码组织方式还是可以接受的：更改完代码后，软件开发人员可以趁着编译器编译代码的时候冲杯咖啡，并在回到座位后花费一分钟部署刚刚编译出来的WAR包以便测试自己刚刚所做的更改。但随着项目的逐渐变大，整个开发流程的时间也会变得很长：即使在仅仅更改了一行代码的情况下，软件开发人员需要花费几十分钟甚至超过一个小时的时间对所有代码进行编译，并接下来花费大量的时间重新部署刚刚生成的产品，以验证自己的更改是否正确。