单体架构（Mnonlithic Architecture）和微服务架构（Microversices Architecture）是构建应用程序和产品的两种不同方式，每种方式都有自己的优点和缺点。 在云技术与容器技术兴起之前，单体架构一直是构建应用程序的主流架构，然而这两种技术的兴起，为我们快速部署项目以及持续集成带来了很大便利。为了项目能保持高速发展，越来越多的公司开始在新业务的选型上，选择微服务架构；也有不少传统企业与互联网企业对已有业务小心谨慎地转型成微服务架构。

为了让您对微服务有更好的了解，我们对单体架构与微服务架构进行对比，看看两者之间的差异在哪。

单体架构的利弊

我们先来看一下单体架构，单体架构最大的好处部署简单，在一个代码库里完成所有功能。 最常见的是应用程序在负载均衡之后，每次开发人员进行更改，他们都会更新主代码库，然后重新部署整个应用程序。 通过添加更多的应用服务器节点，可以完成应用程序的水平拓展。

除此之外，团队可以对项目进行快速有效地迭代，在发布新版本上，他们可以每天部署一次或多次。通过负载均衡，团队还能使用灰度发布的方式不断用户提供迭代的功能。

有些单体应用可以很轻易地完成集成测试，因为一切都在同一个地方，不需要运行很多额外依赖来进行功能的测试——可能数据库是唯一的依赖项。从传统意义来看，IDE（Integrated Development Environment）是为单体应用设计的：例如在Eclipse中，开发人员只需单击一下即可运行和测试整个应用程序。

随着应用程序变得越来越复杂，上面这些好处都会迅速消失。

越来越大的代码库使开发人员难以处理，特别是对于新员工，他们必须对项目有全面的了解，这使他们的学习成本上升数倍。即使团队拥有丰富的实践经验与良好的编码习惯，使代码得到妥善管理，在部署大型代码库上也会变得越来越慢，因为我们必须确保所有内容被正确部署，并且需要仔细检查我们的更改是不是会影响没有改到的地方。

对新技术的尝试几乎成为不可能，例如新数据库或语言，因为开发人员无法正确隔离代码，也很难评估对整个应用程序有多大风险。

由于这些原因，随着项目规模的增长，单体架构的迭代速度将越来越慢，项目也会因此停滞不前。因为即使对代码库进行少量更改也需要对整个应用程序进行重新部署，如果想重构代码库以此对代码库进行解耦，从根本上来说也不能解决问题，因为对库的每次更改仍然需要完全部署。

从人性的角度，产品发布周期变得更长，创新速度越来越慢，这些问题带来的负面因素最终也会导致管理层和工程团队感到沮丧。团队的整体体验是：任何新的变更或功能都会变得难以实现和发布。团队士气和动力也是开发优秀产品的关键因素，如果由于架构问题开始对团队的工作方式产生负面影响，那么就该考虑及时转型，寻找新的方法。

微服务架构的利弊

微服务架构的精髓是：不同业务逻辑构成的服务可以独立创建，部署和扩展。

采用微服务方式构建应用程序时，您需要认识到处理不同业务逻辑的区域或边界在哪。例如，在电商系统中，存在订单、支付、用户和商品展示等不同的业务逻辑。在面向微服务的应用程序中，架构师可以一开始就将这些不同业务的逻辑每一个解耦为单独的服务，以便某业务逻辑发生变化（例如说新增了一种支付方式，支付系统需要更新）时仅需要重新部署特定服务系统而不影响所有其他功能。

通过不同的服务系统提供不同功能，各业务团队现在可以独立决定服务的上线时间和部署频次，还有对自己的业务进行自由扩展。这些服务将通过接口相互通信，从而忽略它们之间的实现细节。只要产品的功能可以引用其他服务，团队就可以构建不同语言的微服务，使用不同的数据存储方式，并在服务中使用新技术（新数据库，新框架等）。

并且，微服务为新员工提供了更加渐进的学习曲线，他们只需专注于相对集中的功能，而不要求对整个项目有全面了解。

更重要的是，微服务在构建时已实现了业务的隔离和可伸缩。如果一个服务发生故障，其他服务仍是正常运行，不会导致整个应用程序崩溃。如果服务突然经历请求的增加或减少，则可以在不影响其他服务的情况下水平增加或减少。同样，如果一个服务受到威胁，它可以被隔离并脱机，而不会影响整个应用程序，或者让它感染应用程序的其余部分。

在面向微服务的结构的工作方式中，我们不再需要臃肿的大型团队，转而建立小而敏捷的专业团队。现在，每个团队都负责建立，维护和扩展彼此独立的服务。

当然，这些好处伴会带来额外的成本。在微服务架构中，网络需求变得更加重要，因为团队需要确保所有服务都正常启动和运行，对项目多个系统的监控也比监控单个应用程序更难、更复杂。随着数据在每个服务周围移动，确保状态的一致性和数据的可用性也是至关重要的。虽然测试单个的独立服务变得容易，但是测试整个项目会变得困难，因为可能会涉及到多个子系统。

小结

正如我们将要看到的那样，微服务架构有利也有弊，但它已经被多个行业的开发团队广泛采用，因为它提供了以下便利：

敏捷：功能组件化开发使团队能够独立的进行迭代和部署。 技术自由：可以根据业务特性选择最合适的技术，使功能得以快速实现。 弹性：微服务的设计拥有应对故障的能力，涉及到冗余和隔离，使应用程序更加健壮。 效率：相比于单体应用，微服务对项目后期发展拥有更好的效率保证。

创业公司很轻松地采用微服务；对于拥有大量不同应用程序的中大型企业而言，每个应用都有自己存在的初衷，从单体架构迁移到微服务结构的过程可能非常艰巨。但相比于架构转型带来的阵痛，微服务架构对于企业带来的好处显得更为重要。

附：

灰度发布：是一种能够平滑过渡的产品发布方式。让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现以及修复问题。