译者注：微服务现在已经很流行了，作者在本文介绍了5个最佳实践。如果想以后调整尽量少，那么在设计架构时遵循这些最佳实践，微服务体系结构将会更加适合开发人员的需求。以下为译文。
如果想让微服务架构开发变得友好，而且可以让开发者管理起来轻松一些，跟踪误差更容易，那么只要遵循本文中讨论的5个最佳实践就可以了。
1.用户代理：在请求头里面命名有意义的名字是非常重要的,如果出现了类似于系统运行缓慢,内存访问量骤增,甚至出现飙升的情况,那么从该微服务发起的请求头中，开发人员就可以很容易定位问题。在服务请求头的User-Agent属性提供逻辑名称/{service id }，这就是一个最佳实践。例：User-Agent：EmployeeSearchService
2.API版本控制：在基于REST的架构中，微服务之间是通过API互相访问对方资源。在微服务里面，API就充当着接口的角色。在编写API时，头脑一定得清晰，确保这样API不会经常变更，这件事非常重要，因为其它的微服务会调用改API,所以API方法签名只要发生调整，代码也就需要跟着进行调整。但是改变是不可避免的,因为我们不知道未来会发生什么，这真的是很讽刺的一件事,所以今天的商业策略可能在几天以后就要被淘汰掉,因此API也就必须进行修改。
作为一名架构师,面临的最大挑战就是如何应对这些变化。答案就是版本维护。对于那些重大的变化,你可以在更新API版本的同时，给消费者发起通知,告知它已经有了新版本,这样他们就可以在既定期限内迁移到新版本。在这个时间内,作为API提供者,就必须维护两个版本,然后不断发送重要通知给消费者，让他们的代码库调用新版本,在这之后，就不再需要维护旧版本了。
3.相关ID：很多人都知道在微服务的架构中，业务功能是分布在多个微服务里面,所以从客户端内部发出的某个请求会扇出许多单独的请求，最大的原因就是有可能某个微服务变慢了，或者down掉了。但作为一名开发人员需要知道在微服务森林如何定位出哪个微服务变慢了,所以我们需要在逻辑上对请求进行分组。为客户端请求生成一个随机的UUID，然后将该UUID传递到每个内部请求中，因此在日志里面就可以通过UUID进行追踪，然后找到相应的调用轨迹。
4.ELK实现：微服务是用来自动定量的,所以在某个复杂的业务领域中是很难管理微服务的日志文件。假设在某个系统中包含了50个微服务,每个每个服务有10个实例;那将会生成50 * 10 = 500个日志文件。作为开发人员,不可能登录到每个实例，然后收集日志，再去调查问题,所以我们需要一个集中的机制,这样所有的日志都可以导出,然后在日志中再做一些智能搜索,比如找出错误或某个特定的异常,再或者还可以通过主机以及相关ID等进行搜索。ELK提供了这一功能,E代表ElasticSearch,L是Logstash,K是Kibana。ElasticSearch会转储日志，也提供了模糊搜索的功能,Logstash用于从不同来源收集日志，然后对它们进行转换,Kibana是一个图形用户界面,开发人员可以搜索他们需要的日志。或者还可以使用Splunk或其他开源框架分析日志。
5.弹性实现：如上面所描述的那样,在微服务架构中,想要完成某个业务功能可能会涉及很多的微服务。最常见的情形就是某个微服务挂掉了,导致整个流程都停止了。针对于这种情况,弹性就显得至关重要了,每个服务都应该实现弹性，从而为最终用户提供无缝体验。当某个服务在一定时间里没有响应,应该配置一个后备路径,这样用户就不需要等待响应,但是会立即得到一个内部错误的提示。其实从本质上来说这就是一个响应设计。
结论
在构建基于REST的微服务时,需要考虑两个方面：
- 用户体验
- 开发人员的视角
用户不喜欢等待,他/她需要一个很明确的信息，不是指技术信息，而是指当内部出现某个问题时，可以告诉他/她发生了什么,他/她就可以正常联系服务台。另一方面,为微服务提供支持的时候,我们需要知道的所有重要信息都在日志中,事件发生后，需要基于日志进行分析。在开发的时候如果总能站在支持的角度进行思考，这样你就可以跟踪流程，从日志文件中也可以获取到足够的信息。
