微服务是技术领域的一个热门趋势，由Netflix，亚马逊和谷歌等公司开创。伴随着容器技术与云技术的发展，微服务已成为高速增长公司中构建应用程序的首选。了解微服务架构之前，我们先来看看什么是单体应用，因为只有当知道了单体应用的不便之后才能更容易地理解微服务架构模式的优点。

单体架构：Mnonlithic Architecture

单体应用很容易理解：一个代码库包含一切，包括业务处理逻辑与数据处理逻辑。

当产品从零到一，想要快速投入市场时，Monolithic是个不错的选择，因为代码库特别小，只需要一个很小的团队就可以完成任务，也没有其他依赖性需要考虑。

如果想要扩展单体架构，您可以引入负载均衡，将流量分配到每台应用服务器的单体应用上。这种架构会给后端服务器带来过多负载，同时也使单体架构的拓展变得困难。

如果代码库很小，可以肯定地说，单体架构选择带来的挑战也很小。但是，随着代码库的增长，问题开始出现，开发软件变得越来越具有挑战性，因为即使是很小的更改也需要完整地重新部署整个应用程序。如果出现问题，这通常也会影响整个应用程序，甚至导致应用不可用。在这种情况下，单体架构以前的优势也会成为缺点：

• 业务逻辑捆绑在一起，随着代码库变得越来越大，开发人员在编译和部署的时间上明显增多；
• 当我们的项目越变越大，引用的技术越来越多，由于技术的不兼容性，想要继续在单体架构上拓展功能，就存在对某些功能在技术选型上进行妥协的情况，不得不放弃最合适的技术；
• 庞大的代码库会给新加入的成员带来很大压力，无法让他们在短时间内快速上手工作，并且新人贡献的代码也会增加应用的出错几率。

微服务架构：Microversices Architecture

至此，您应该明白，解决上述问题的办法是使用较小的应用程序，而不是一个大的单体应用。

我们可以把这些较小的应用程序称为组件（components），组件必须满足以下两个要求：

• 能够独立构建、独立部署；
• 组件的开发任何工作将由构建该组件的特定团队负责。

由于组件之间相互独立，因此需要有一种方法来连接各组件，通常是通过接口，或者说API。通过这种方式，我们能够独立部署以及拓展组件，并且对组件进行版本化管理。每一个组件都将很好地完成一件特定的事情，而且一个大的组件也能够再细分成更小的组件，以更小的粒度实现功能。当组件在实际业务中提供了服务，我们就会把组件称为服务，这些实现特定功能的一组API也就是我们所说的微服务（a suite of microservices）。

小结

本文通过讲述单体架构与微服务架构的发展，让你对这两种架构有一个初步认识。下一章，我们将详细探讨这两种架构的优缺点，帮助您在实际情况中进行架构选型。