基于REST微服务的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.弹性实现

如上面所描述的那样,在微服务架构中,想要完成某个业务功能可能会涉及不少的微服务。最多见的情形就是某个微服务挂掉了,致使整个流程都中止了。针对于这种状况,弹性就显得相当重要了,每一个服务都应该实现弹性，从而为最终用户提供无缝体验。当某个服务在必定时间里没有响应,应该配置一个后备路径,这样用户就不须要等待响应,可是会当即获得一个内部错误的提示。其实从本质上来讲这就是一个响应设计。

6.结论

在构建基于REST的微服务时,须要考虑两个方面：

1. 用户体验
2. 开发人员的视角

用户不喜欢等待,他/她须要一个很明确的信息，不是指技术信息，而是指当内部出现某个问题时，能够告诉他/她发生了什么,他/她就能够正常联系服务台。另外一方面,为微服务提供支持的时候,咱们须要知道的全部重要信息都在日志中,事件发生后，须要基于日志进行分析。在开发的时候若是总能站在支持的角度进行思考，这样你就能够跟踪流程，从日志文件中也能够获取到足够的信息。