微服务：云驱动的应用架构变革

我们正处在由云驱动的应用开发和IT管理的改变之中。快速，灵活，低成本，可大规模扩展的云基础架构，和提供自助服务，按量付费的计费方式，可大幅提高运营效率，并快速体现业务价值。容器的出现，快速启动，标准化的应用程序打包和隔离模式，又进一步提高了运营效率和敏捷性。

但是，许多公司发现，使他们的应用程序具有高可用性，可扩展性和敏捷性仍然面临挑战。竞争的商业压力要求应用程序不断迭代，添加新的功能和特点，同时保持7*24可用。例如，银行网站是不可接受维护宕机的。同样，一个电子商务网站即使短时间内宕机，也会导致客户流失到其它可提供7*24服务的竞争对手网站去。不能满足这些要求，意味着可能导致丢失业务。

这些业务压力正在推动开发人员采用"微服务"的应用程序架构模型。在这篇文章中，我将讨论微服务体系结构如何以及为什么能够帮助应用程序开发和生命周期任务，并描述平台可以提供的支持这些体系结构的功能。然后，我将列举开发人员通常使用的一些被作为微服务应用程序基础的平台。

1. 传统应用模型

数十年来，提供新硬件（无论是物理的还是虚拟的）的成本，时间和复杂性都强烈地影响了应用程序的开发。当这些应用程序是关键系统时，这些因素更为明显，因为高可用性需要高度可用的基础架构，包括昂贵的硬件（如SAN和硬件负载平衡器）。由于传统IT基础设施是静态的，即使在虚拟化的情况下，应用程序也被编写为静态的大小和设计用于特定的硬件。即使将应用程序分解，去尽量减少硬件需求并提供某种级别的敏捷性和独立扩展，通常也将其纳入传统的三层模式，即Web，业务逻辑和数据层，如下图所示：

图1.三层应用

但是，每一层仍然是一个整体，实现了不同的功能，这些功能被组合成一个应用系统，并部署到预先安装的用于高峰负载的硬件上。当业务导致应用负载超出其硬件配置时，解决方案通常是"升级硬件"，以避免数据中心重新配置和软件重新架构。

整体应用模型是基础架构局限性的自然结果，但是导致效率低下。静态的基础设施和较长的开发周期意味着即便将应用程序分解为几层以下，也几乎没有优势，所以开发人员在层之间的不相关的应用程序服务之间建立了紧密的耦合。对任何应用程序服务（即使是小应用程序服务）的更改都要求对整个层进行重新测试和重新部署。一个简单的更新可能会对其他层次产生无法预料的影响，使得变更风险增大，并延长开发周期，以便进行更严格的测试。它们依赖于静态分配的资源和高度可用的硬件，使得应用程序容易受到负载和硬件性能的变化影响。一个硬件故障可能会使整个应用系统陷入困境或使其性能严重下降。

最后，利用分层方法的应用系统所面临的另一个挑战是通过存储在后端层中的数据提供快速的性能。一个典型的方法是引入中间缓存来缓冲计算和数据分离造成的低效率，但是通过增加未使用的硬件资源提高了成本，并且创造了额外的开发和更新复杂性。

图2.使用缓存的三层应用系统

2. 微服务架构