引言
随着越来越多的公司应用服务化，总结下这段时间了解到服务化相关的东西，这里不谈服务到底是SOA，还是微服务，笔者在网上搜了一些相关资料，看得很是懵逼，所以这里只谈谈笔者在项目中理解到的一些东西。
服务化架构图
API Gateway
Gateway 层主要给用户提供统一入口、API配置管理、分流、鉴权、服务监控、协议转换。
服务化治理
服务注册发现
服务在启动的时候会将服务名，集群名，机器ip，端口号等信息 注册到服务治理中心。
消费方在调用服务方提供接口时，会向服务治理中心请求服务方的集群信息，并且订阅集群的变更信息，当集群信息变化时，立即同步给消费方。
服务配置
在服务治理层改变配置之后，变更会同步给服务。
链路追踪
服务化之后，服务会有成千上万个，一个接口可能涉及到好几个服务，中间件，调用关系复杂，怎么样让问题的追踪和定位会变得比较方便，这时候我们就需要一个链路追踪工具。链路追踪工具的实现，著名的有Google Dapper。
负载均衡
consumer服务Client SDK 会内置一些负载均衡策略，目前在项目中内置了轮询、权重轮询、最少连接均衡策略，但是最少连接分流并不是很均衡。一致性hash负载均衡可以内置，在有些时候是可以提高本地内存缓存命中率。
服务健康检查
目前项目中go client实现的健康检查就比较粗暴，只会在拿到一个连接的时候会去调用下provider的ping 接口（接口定义规范）。在java client sdk 中粒度为依赖服务的实例级别的。在应用收到新增服务实例的消息后，会启动一个此实例的后台健康检查线程。删除服务实例的消息后，会停止并销毁此实例对应的健康检查线程。健康检查在线程中循环执行，间隔为0.5s。连续失败3次，视为服务死亡。成功1次，即视为服务存活。
服务熔断
服务熔断是一种服务自我保护机制。在客户端实现，粒度为方法级别。
1. 统计策略
每次请求时统计当前时间点前一定的阈值秒内请求的错误率。若满足以下两点：
请求总数 > 一定的阈值；
请求的错误率 = (非业务异常请求数+超时请求数)/总的请求数 > 一定的阈值。
就会触发熔断，不再向服务端发送请求。
2. 恢复策略
恢复发生在熔断保护期之后最小阈值。
如果有请求到来，则放行一条请求用于测试服务端提供服务的质量（其他并发 来的请求还是处于熔断中。
如果这条测试的请求，正常完成调用，到熔断保护期之后最大阈值之前会随机性的通过一些流量，到最大阈值之后恢复正常；否则，继续1。
3. 熔断期间的行为
熔断之后，client的请求会抛出api 异常。
总结
服务治理设计到很多东西和细节，笔者只是简单的总结下，还有很多东西没有列出来，例如授权、限流、降级、超时，服务端内部状态查询等。
