构建微服务-第一章-什么是微服务_007其他功能分解技术

我们认真思考微服务的时候，基于微服务的架构好处来自于其细粒度，而且微服务给你很多技术选择来解决问题。但是我们这里也考虑一下其他的解耦技术是不是可以实现同样的效果？

共享库

共享库是一个标准的解耦技术，通过将一个代码库分解为多个库文件，这些库文件可能来自第三方、也可能是自己开发的。共享库给人们提供的共享功能一个途径。人们可能创建一系列有用的功能比如统计库来给大家复用。

团队可以通过这些共享库来组织，而这些代码库是可以复用的，但是其实也是有缺点的。首先，我们失去了技术的多样性，共享库一般情况下需要是同一个语言来实现，或者至少

在同一个平台上来运行。其次当我们想缩减系统的某些部分使之互相独立会变得更加困难。再次，除非你使用动态连接库，否则你每次部署都需要重新部署整个进程，所以隔离那些只改动的部分来部署变得困难。还有可能反对者说我们缺乏可靠的架构安全措施来保证系统的弹性。

当然共享库有它们自己的用处。我们有时候会发现我们可以写一些代码来完成一下公共的任务，很显然这些代码就能成为共享库候选者。服务应该尽可能多地使用第三方库来复用通用的代码，但是共享库不能解决我们所有的问题。

模块化

有的语言提供内置的模块化解耦结束，这比起简单的共享库要先进。它允许某种程度上地对模块的生命周期进行管理，所以模块可以在运行时进行热部署，不需要停下整个进程。

OSGI是一种模块化解耦技术，Java本身没有什么模块的概念，我们可能要等到Java9的时候或许可以看到。OSGI提供一个可以安装在Eclipse里的插件，它提供我们在Java里实现模块化的技术。OSGi的问题主要是对模块化的支持不是语言级别的，需要模块的作者做一些工作，也很容易导致各个模块之间过于耦合而导致一系列的问题，OSGI引出的这些问题很容易盖过它带来的好处。Erlang语言走的是另外一条路，在语言级别上支持模块可以独立停止、启动、升级，而不会有什么问题。Erlang甚至支持同时使用不同的Erlang版本，支持更加优雅的升级。

Erlang语言级别的模块化支持确实给人很深的印象，但是仍然共享库类似的缺点：不能使用其他新的技术、不能独立地伸缩系统、有过度耦合的倾向、不能提供架构层面无缝整合。

技术上来讲，如果能够允许我们在一个单一进程里创建一个独立的模块那就是比较完美的解决方案，但是目前为止还没有发现有哪个技术提供这样的功能。模块们很容易变得互相依赖从而失去了我们模块化的初衷。使用独立的进程才可以完美地解决这些问题。

所以进程内部的模块化可以某种程度上解耦我们的系统，但是不能解决所有的问题。如果你使用Erlang，需要一个很长的过程来创建一个晚上的Erlang模块。对于不使用Erlang的我们，模块化可以提供和共享库一样的优缺点。