混合微服务模式

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

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

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

混合微服务的概念和来由

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

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

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

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

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

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

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

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

微服务有很多优势，但是也有其固有的缺陷：把系统变得更复杂。这种额外的复杂性，直接提升了开发和运维工作的难度。

正因如此，混合微服务的方式就很有意义了，可以尽可能的降低微服务引入的复杂性。例如哪一部分的 API 调用更少，或者哪一部分可以打包为独立的容器。如果优先对这些组件进行重构，就能够有效的减少 API 调用，降低容器化的难度。

和混合云一样，混合微服务策略不是一蹴而就的。这是个持续的过程。可能起初只有一小部分的组件被独立出来成为了微服务，从而形成了混合微服务架构，但是不必止步于此，随着时间的推移和环境的变化，可能会有更多的重构需求。

所以在踏上混合微服务之路的时候，应该设计一个微服务的路线图。就算不具体到时间，至少也应该对你的混合微服务应用有一个基本的演进设想。

我们都希望改善我们的单体应用，但实际情况是，多数情况下我们不会有足够的开发资源把单体应用迅速的重构为微服务架构。与其全盘放弃，不如考虑一下这种混合微服务架构。可以参考上面提出的标准，来决定需要进行微服务改造的模块，需求不够迫切的其它部分，继续以单体应用的模式提供服务。