微服务如果管理不当的话，可能会给工作带来一点麻烦。Tom Nolle解释了恰当的微服务设计意味着什么。

微服务是代码小型的功能捆绑，旨在通过适当的使用来促进可重用并改善QoE以及可用性。如果使用不恰当的话，它们就会成为应用生命周期管理和资源效率的“噩梦”。

要想解决这一问题，你不仅仅需要把目录和注册结合起来，更要把你的微服务作为一个虚拟应用来看待，聚焦于可重用来进行微服务设计，微服务的分类要能够确保新服务和实例能够适配，以及最后让应用架构师和ALM团队来判断创建了不必要服务的情况。

微服务应该是什么样的？

微服务本来是要促进可重用的，但是往往创建出来之后并没有达到那个目的。微服务应该是一项公司资源，应该是能保证在尽可能广泛的范围内加以重用的。对此的推论应该是任何项目创建微服务之前都应该进行审查，确定是否已经存在相同或者类似服务，以及对那些决定要新建的服务的所有应用前景进行评估。

最简单方式是把微服务当作一项广泛应用来考虑，这项应用的持续变化是由新的微服务、变更的微服务的结合来推动的，这样才能适应更广泛的使用或者撤销微服务。这个虚拟应用应该服从常规开发审查，与其他开发团队进行协调，从而确保微服务实际上得到使用并且使用得当，同时与ALM活动进行协调以确保微服务变化不会中断已有应用。

除非应用架构师习惯于在应用设计中寻找微服务的机会，并且在需要新建时创建尽可能通用的微服务，否则微服务策略就不可能取得成功。这意味着微服务使用最有效的控制过程要以专门的负责微服务审查的应用架构师小组为基础。然后由这支团队来进行这一微服务虚拟应用的协调。

在应用设计的早期阶段，其目标应该是用微服务来实现应用功能并且满足应用性能和安全需求。在开发的应用架构点做这件事可确保微服务设计针对的是可重用。

如果微服务不能胜任怎么办？

如果用当前微服务不能满足一项需求的话，那么可选的做法可以用嵌入式的传统逻辑，或者增强当前微服务来适应需求，或者开发新的微服务等。嵌入式逻辑这个选项被认为是不存在广泛价值的功能，或者工作流需要外部微服务支持，会影响到体验质量（QoE）。增强当前微服务是最好的方案，对现有微服务进行最小的改造和逻辑扩展就可以满足需求（避免尴尬的功能结合）。如果这两种方案都不可行的话，那就得考虑新的微服务了。

审查每一项新的微服务以确保广泛可重用非常重要。一般而言，这是从使用一项简单的RESTful接口并且实现该服务的无状态操作开始的。这些简化了对服务的多并发使用，还可以在负载变化的情况下对服务进行水平伸缩。在此之后，尝试设计服务让它在任何应用背景下支持其功能。

解决这一问题的办法之一是审查当前应用什么地方可以或者应该使用新的的微服务。这是防止微服务在不知不觉间重复了嵌入逻辑的重要一步。发生了这样的事，只会引起性能或者安全/合规性的问题，把共同代码放入到嵌入逻辑和微服务的步骤应该要考虑避免给后面的开发者造成混淆。

下一步就是考虑以哪种方式来发现微服务。常见的办法是利用某种形式的注册，但是准确的机制应该取决于所使用的编程语言以及对微服务动态的预期。如果微服务调用是在开发时显式引入到应用代码里面的话，那么可以考虑把注册作为开发者工具，这几乎就像是一个类库一样。如果微服务调用的动态性预期更强的话，则需要运行时发现流程，这更像是SOA应用的目录。

不管是哪种情况，最佳实践都要求微服务要在欠载的情况下伸缩，这意味着注册/发现机制必须在微服务的实例数发生变化的情况下更新，必须把请求引导到一个实例来实现负载平衡。用来进行负载均衡和实例管理的机制必须包括在注册之内，不管微服务是以静态还是动态方式调用均是如此。

微服务管理的最后一步是“去重”。尽管有了控制微服务部署以及消除重叠或者完全重复的努力，一些问题还是有可能忽视的。一些问题可以在常规软件架构师的审查中发现，但另一个抓住“漏网之鱼”的机会是在ALM。

如果你接受把整个微服务当作虚拟应用来看待的建议，那么你就会有ALM的步骤来专门验证微服务的变化。这些步骤可暴露任何现有微服务存在的问题。在“正常”应用层级的ALM也会要求对每一个应用相关的微服务进行测试，这个步骤会把任何审查流程漏掉的新的微服务暴露出来。一旦发生了这样的事，要对这些“行为不合常规”的微服务进行审查，要么通过合并来撤除，要么把它们添加到正规的注册表和虚拟应用流程内。