调整微服务代码结构的一些常见技术

在微服务大行其到的当下，究竟哪些代码应该放在具体的某一个微服务中一直是一个值得探讨的话题。本文不对这个主题展开讨论，而是关注于助于调整现有微服务架构中代码结构的相关技术，包括共享库、共享服务、代码转移、代码冗余、提取新服务和重写服务。这些对于如何重构现有的服务体系有一定的参考意义。

1. 共享库

如果两个服务想要共用一些代码，那么这些代码就可以被提取并放到一个共享库中。共享库体现的是一种代码复用思想，公共代码从某一个服务移到共享库就可以被其他服务所使用。共享库技术的示意图见下图。

共享库实施过程中的主要挑战在于如何判断某些代码应该移到共享库而不是放在本地服务中。微服务架构实际上并不是非常关注代码复用，因为代码复用会导致服务与服务之间产生新的依赖。微服务架构崇尚服务独立性，过多的把代码提取到共享库可能会引来一些不必要的问题。而且，共享库也会对服务部署结构产生一定影响。

当然，共享库的优势也很明显。本来存在bug或不合理设计的代码通过在共享库中的一次修正就能完成所有场景下的代码升级。通过合理管理共享库的版本可以降低代码错误率。

2. 共享服务

共享服务的思路与共享库类似，只不过在共享服务中，被提取的代码并不是放到一个独立的公共库中，而是直接转移给了另一个服务（见下图）。与共享库相比，共享服务的优势在于不用产生新的依赖关系，因为服务与服务之间的交互方式并没有任何改变，而服务内部的任何调整并不会产生架构上的影响。

共享服务是保持服务大小合理性的一种手段，借助共享服务机制，我们可以对规模比较大的服务进行“瘦身”。但是共享服务在不增加服务依赖关系的同时却会转移服务与服务之间的交互需求。当我们把部分代码从一个服务转移到另一个服务时，本来只需要依赖一个服务的场景，就可能变成需要依赖几个服务。

3. 代码转移

从一个微服务中抽取一部分代码放到另一个微服务中的做法称之为代码转移。通常，我们进行代码转移的主要目的是为了降低两个微服务之间的耦合，提高单个服务的内聚度。当一个微服务需要依赖另一个微服务完成某个功能时，我们认为两者具有一定耦合度，当把两者之间的交互部分代码进行转移之后，这种耦合度就能得到缓解。代码转移的示意图如下图所示。

代码转移与前面提到的共享库有点类似，但被转移的代码往往到不了高度复用的程度，所以没有必要提取为共享组件。另一方面，共享库的提取具有技术约束性，即使用共享库的几个微服务一般都需要采用同一种技术实现体系。而代码转移则可以更加灵活，我们完全可以采用另一种技术实现方式重写这些需要转移的代码。微服务一般规模都不大，而需要转移的代码通常只是其中的一小部分，所以基于代码重写的实现方案成本可控。

4. 代码冗余

与其把代码转移到另一个微服务，有时候我们也会选择代码冗余的方式降低服务与服务之间的耦合度。在主流的方法论中，普遍认为代码冗余是一项反模式，因为当代码被冗余在两个地方时，一旦有问题就需要同时修正这两个地方。这是一个架构腐化的危险信号，所以我们一般都尽量避免重复代码的产生。但在微服务架构中，代码冗余有一个非常明显的优势，即两个微服务之间能够保证高度的独立性，从而实现微服务架构所提倡的独立部署。

针对独立部署，我们有时候不禁要问一个问题：现实中真的存在一个完成独立的系统或组件吗？很多时候，我们花了很大代价提取代码到共享库或共享框架，会发现这些共享库或共享框架用起来也有很多问题。这时候，冗余部分代码可能是一个更好的选择。代码冗余的方式见下图所示。

5. 提取新服务

当然，我们也可以通过提取部分代码的方式创建一个新服务（见下图）。提取新服务具有与共享服务同样的优点和缺点，但是两者具有不同的初衷。当一个服务的规模逐渐增大，提取新服务的目的在于通过减小服务的规模从而降低服务的维护成本，或者把该服务所承载的一部分职责转移到另一个团队。这时候，这个新服务就不会像共享服务那样被多个服务所共同依赖。

举个例子，假如在移动医疗系统中，注册流程可能非常复杂，因为需要依赖就诊卡等医疗媒介，也需要区分不同的用户群体，因此我们可以把注册服务拆分成几个服务，分别处理不同的用户注册场景。这种拆分在降低服务复杂度的同时，也会从组织架构上推动团队结构的优化和业务的聚焦。

6.重写服务

最后，如果我们认为一个微服务的结构已经不再合适，我们就只能重写它。相较其他的架构设计方法，微服务架构中的重写并不是一件非常困难的事情，因为微服务的规模较小，同时具备明确的服务契约。

我们有时候会鼓励重写服务，一方面可能来自于技术体系的发展和演进，使用新技术重写一个老服务会带来更好的发展前景。另一个更重要的方面，重写服务驱使我们再次审视服务背后的领域模型，从而为该领域模型提供一种崭新的、更好的实现。

更多内容可以关注我的公众号：程序员向架构师转型。