四大理由解析你需要微服务架构

为什么我们需要微服务架构？我们如何才能从中受益？

10年前，正值或差不到了 SOA炒作的巅峰。那时候，你的服务部署可能涉及到J2EE应用 服务器，要进行基于EAR文件的部署，或者是一种更加面向集成的办法—通过ESB聚焦于遗留的集成点并以基于SOAP的服务将其暴露出来。你所有的服务可能都是一两支团队的，因为他们是唯一理解这一技术的人。尽管Thomas Erl当初那本有关SOA的书很火，但大多数服务并未遵循他的服务导向原则。应用服务器或ESB生产时仍然部署在物理硬件上。

时光冉冉，再看看现在，情况已经大为改观。组织已经有了多得多的服务，且分别由许多不同的团队拥有。这一切都不是用Java写的。服务被部署到虚拟机（VM）上，也许甚至是 企业数据中心以外的公有云上。那么，我们为什么仍然需要微服务架构呢？这些变化我们一个个来看看吧。

我们仍然需要微服务架构的理由

首先，你的服务多得多了。实际上，你多的可能是操作，但那些被捆绑进了服务里面。只需看看那些操作的使用情况，我敢打赌，它们将遵循帕累托原则：你得流量里面80%（或更多）来自于20%（或更少）的服务。如果这些服务的每一个都由同样规模的基础设施来提供的话，你的资源利用率可能就会非常糟糕。此外，哪怕是在服务里面，也可能不是所有的操作消耗的流量都一样的。对于特定的操作你却不能（单独）伸缩能力；而是在整个服务水平上进行。如果你还使用J2EE服务器的话，在同一集群下你甚至还会有多个EAR 软件，且不得不针对全部增加或移除能力。简而言之，你无法根据处于独立操作级的依赖性和需求做出基础设施决策。

其次，这些服务被扩散到了更多的团队中间。这会恶化资源利用率的问题，因为此两支不同的团队往往不希望共享基础设施。因此，就得提供更多的服务器，哪怕能力本来就够。更糟糕的是，组织总是在变的。一旦管理层做出的改变组织无法匹配服务的组织形式该怎么办？你能否轻易绕开这些东西？记住，这不仅仅是这些基础设施，还包括底层源代码以及相关项目。

其三，并非所有的东西都是用Java EE或.NET写的。带框架的应用服务器服务天下的日子已经一去不复返。不要误解我的意思，那些框架还在，如果说有什么区别的话，现在的趋势正朝着你只需部署所需的模式发展。

最后一点是云。尽管我们还没有到达那种程度，但会继续看到越来越多的按需付费模式的出现，而不是2005年那种为固定能力付费的模式，无论你的应用场景如何。尽管这一模式在财务方面并不简单（涉及到资本支出、运营支出等等），但你很难否认这一趋势在近期内会有所改变。这意味着基础设施会继续朝着实用模式发展，最终消费者可以按照需要提高或降低能力。如果情况是这样的话，我们需要一种能力能尽快就绪的模式，且负载应该仅可能的低。这意味着我们不能等应用服务器加载完一堆未必需要的东西。相反，我们希望扩充的部分正好是我们需要的，不多也不少。

那么，当我们把这些要素一起考虑时，微服务架构模式的情况就很明了了。尽管2005年的SOA的好处仍然有效，基于云的基础设施、DevOps等这些带来的变化现在已经使得颗粒度到操作级的服务管理成为可能。我们仍处在这一努力的早期阶段，在管理所有这些移动组件上仍存在着最大的鸿沟。幸运的是，我们有很多好的例子可以学习。找一位老一点的有大型主机经验的同事问问看，他们是如何在主机航管理所有那些独立的微服务的。只需记住把那叫做事务。