一文快速看懂：微服务是什么？微服务架构的优缺点

觉得“将应用拆分为多个核心功能，以免受困于单体式结构陷阱”这种做法很耳熟？这是因为微服务架构模式与面向服务的架构（SOA）类似，而 SOA 已经是一种非常成熟的软件设计模式。

早期在开发应用时，即使要对现有应用做很小的改动，也需要对整个版本及其质量保证（QA）周期进行批量式更新，而这很可能会影响很许多子团队的工作推进速度。这种方案常被称为“单体式”，因为整个应用的源代码都被构建到了单个部署单元（如 .war 或 .ear）中。如果应用因某个部分的更新而出错，则整个应用都要下线，然后缩减，再加以修复。虽然这种方案如今仍适用于小型应用，但是众多正在成长中的企业无法承受停机所带来的影响。

改用面向服务的架构后，应用被构建为可重复使用的离散型服务，这些服务会通过企业服务总线（ESB）进行通信。采用这种架构时，各项服务会分别围绕特定的业务流程来规划，并会遵循相应的通信协议（如 SOAP、ActiveMQ 或 Apache Thrift）通过 ESB 进行共享。在通过 ESB 集成后，这套服务就可以形成一个完整的应用。

一方面，这种架构方式使得各项服务可以同时构建、测试和调整，不会再受限于单体式开发周期。另一方面，虽然使用 ESB 意味着整个系统只会出现单点故障，但在某种程度上，消除单体式结构只会形成新的故障点：即 ESB 本身，因此它可能会成为整个企业的瓶颈所在。