正如其他通用的解决方案一样，微服务架构也有自己的优劣；有些东西因它变的更简单，同时另一些东西却变的更复杂。当转换到微服务的时候，最常见的挑战就是在哪里使用共享代码的问题。
起初，把常见代码转换成独立库的这种做法听起来很不错。原因很简单，一般我们要在两个文件中用到相同代码的时候，就会把这段代码写成一个函数，而写成库则是在更高层次上达到相同的作用，何乐而不为呢？
但是并非我们想象中那么简单。共享库会造成微服务之间的强依赖，因此应该事先考虑清楚这些为服务在整个服务群中所扮演的角色后再做决定。我在加入Runnable之后亲身经历过这类问题。
举个例子，假设你把域模型抽象进了一个库中，一旦对该模型进行修改，你必须同时更新所有使用这个库的服务。这包括更新代码，通过review，测试，staging等等。这样一来，微服务构架就变成了一个死板的整体。
那么，是不是说微服务就不能和库共存了呢？并不是。Philipp Hauer在他的文章中（http://t.im/1b7g3）曾解释过一些关于微服务和共享库的特例。
在技术问题（technical concerns）上，使用库是okay的（比如，日志和监控），因为业务需求往往对这些问题没什么影响。
这一点很重要。微服务一般可以分为两类代码：
域特定代码（Domain specific code）。这类代码针对服务需要处理的问题。比如，所有的业务逻辑和域模型都是这类代码。
支持代码（Support code），也就是Philipp Hauer所提到的技术问题。就我自己的经验来说，微服务代码中很大一部分都属于支持代码，所以我们应当花点时间来考虑如何更好的组织这些代码。
在Runnable，我们用到了一些库。其中一些是内部开发的，一些则是第三方代码。这些库是我们建立新的微服务的基石。
下面列出一些与我们的一些库相关的技术问题：
监控（monitor dog）——以标准化方式向Datadog报告数据；例如，在每个时间前加上服务名作为前缀。
错误处理（error cat）——提供错误层级结构，该结构由所有服务继承并向Rollbar报告错误。
配置（loadenv）——保证每个微服务都以同种方式加载环境变量。
worker服务器（ponos）——包含标准监控和错误报告的常规worker服务器。
Docker/Swarm 客户端（loki）——包含标准监控的Docker/Swarm客户端库。
正确性检查（joi）——针对邮箱地址、日期等的正确性检查库。
结论
要正确辨别你的代码中是否需要用到库，这很重要。
这里有几个一般性的经验法则：
如果这段代码中包含业务逻辑或者域特定代码——那这段代码就不应转换为库。
如果这段代码会因新的需求频繁变动——那它也不适合作为库。
如果这段代码会造成消费者间的耦合——它也不适合作为库。
如果以上问题都没有，那就放心去做吧！将一般性的代码转换成独立的库可以加快新服务的开发，因为这样你可以将精力集中在服务需要解决的特定问题上。另外，使用库函数还可以让所有模块的监控、错误处理、和管理配置变得标准一致。
本文为翻译文章，点击阅读原文链接即可查看原文。
