转载

混合微服务模式

原作者： Sonya Koptyev

原标题： Why a Microservices Hybrid Model Is What You Probably Need Instead

在听到别人谈及微服务的时候，你会注意到他们讨论的是一个非此即彼的问题：重构成微服务？还是固守单体形态？这种想法很合情理：微服务是个复杂的话题，把这个复杂性简化成一个二选一问题，就轻松了。

然而微服务实际上并不是一个非黑即白的概念。在应用中部分使用微服务，其它组件仍然保持单体应用的状态，这是一种完全有可能的情况。

这就成了一种混合模式的微服务。本文中我希望能解释一下混合微服务的具体含义，为什么会用到这种模式以及如何构建混合模式的微服务。

混合微服务的概念和来由

简单来说，混合微服务应用意味着应用的一部分是用微服务的方式来进行开发和部署，其它部分则还是单体形式。

可以将其与混合云相类比，混合云中包含了公有云、私有云，可能还有其它的自有基础设施。目前来看，混合云是一种流行的实践方式；实际上，可能很难找到一个完全单一云模式的组织。

如果我们能和混合云共处，那么也应该能够应对混合微服务架构。这种做法能够比较简单的获得微服务在弹性、容量和安全方面的好处，又无需使用微服务架构将传统应用完全重构。

对多数组织来说，将一个单体应用完全重构为微服务的过程中，对开发资源的调动是一个很严峻的问题；采用混合微服务策略是一个较好的方式，对开发团队来说，这种方式让微服务架构触手可及；否则的话，开发团队可能会因为时间、经验等方面的欠缺，无法接受对单体应用的重构工作。

混合微服务架构的基本概念很容易理解，但是实现起来就颇值得玩味了。首先面临的问题就是，需要对你的应用进行鉴别——哪些部分需要微服务改造，哪些部分需要保持单体形态。这里给出一些提示。

最醒目也是最重要的事情就是，应用的哪些部分重构为微服务会获得最大收益。

哪些部分需要重构？要解答这个问题很明显根据实际情况来进行判断，但是还是存在一些指导性的微服务改造原则的：

伸缩性：你的应用中，可能有些部分需要比其它部分更多的实例数量。例如一个系统的首次访问可能需要登录，这就可能使得认证模块在某一时间出现峰值，而其它模块则不存在这种波动。这种情况下，将认证模块拆分出来形成独立的微服务，就能让你用更少资源来满足认证的峰值需要。
安全性：应用中哪一部分最多暴露在安全威胁之下？哪一部分最有可能被入侵从而影响到其它部分的安全？这些组件应该优先转换为微服务，这样有利于进行有效的隔离，降低安全风险。
更新：微服务的一个重要优势就是能够在不打扰其它微服务的情况下进行独立更新。有时一个应用中的不同组件会有不同的更新频率。有时候你会在很少更新后端的情况下，频繁的变更接口。这种情况下，可以把前端重构为一个或多个微服务，从而能够更容易的进行这部分的更新工作，让原有的后端继续以单体应用的形式进行。