转载本文需注明出处：微信公众号EAWorld，违者必究。
引言：微服务架构下，服务拆得越细，服务的粒度越小，可组装性就越好；与之相对的服务之间的调用关系就会变复杂，为了保证服务更好的运行，需要对这些服务进行监控和管理。本文大家介绍下EOS微服务平台如果对微服务进行日志查看、API调用统计、限流、熔断、负载均衡的管理。
目录：
1.EOS微服务平台简介
2.微服务监控统计
3.微服务治理1.EOS微服务平台简介
1、域是平台中一组系统的统称，通常为一组系统定义成有业务含义的域，比如信贷域。一个域有多个系统，一个系统只能属于一个域。一个域下可以日志中心、注册中心、配置中心、APM监控中心已经断路器监控中心
2、系统是平台中一组应用的统称，通常为一组应用定义成有业务含义的系统，比如信贷系统。一个系统有多个应用，一个应用只能属于一个系统。
3、应用（微服务应用）是平台开发出的基本部署单元，一个应用只能属于一个系统，一个应用有1到多个应用实例组。
4、应用实例组是平台中应用的实例分组，每个应用可以有1到多个应用实例分组，不同的应用实例组拥有独立的应用配置与管理能力，不同的应用实例组之间可以通过流控策略，实现应用的灰度发布能力。应用实例组下面有多个应用实例。
5、应用实例是平台下实际部署应用的进程，应用实例属于某一个应用实例组。2.微服务监控统计1、应用监控
通过应用监控可以查看一个系统内应用之间的调用关系。单个应用的平均响应时间、平均吞吐以及慢的端点访问。2、实例监控
通过实例监控可以查看一个实例的运行情况包括：平均吞吐、平均响应时间、CPU、内存以及SQL的执行。3、请求监控
通过请求监控可以查看一个请求是成功还是错误，它的响应时间，以及它的调用链路：经过了几个微服务，在每个微服务内的耗时是什么情况。4、API调用统计
API调用统计可以按照应用、实例组、实例、API来统计汇总请求信息，包括：响应状态码，请求数，最小响应时间，最大响应时间，平均响应时间以及响应时间总和。支持按应用、实例组、实例、API、时间段等条件进行查询以及按请求数和响应时间排序。5、应用日志查看
应用日志汇聚多个应用实例的日志，进行统一查看。查看时支持按实例以及时间段进行查询过滤，应用日志自带traceId, spanId这些请求追踪号。3.微服务治理1、实例上下线
通过设置实例的状态，使得实例不会被其他应用调用。这个是在客户端实现，客户端是通过ribbon做负载均衡，ribbon会过滤掉状态为OUT_OF_SERVICE的服务提供者实例。2、API上下线
通过设置API的状态，使得API不会被其他应用调用。这个是在服务端实现，通过在服务端增加Filter拦截器，对已下线的API的请求访问，返回403的状态码。3、熔断
EOS的熔断实现使用的是Hystrix，通过在页面配置熔断对象以及触发条件来设置断路器。熔断对象对应的是Hystrix的CommandKey，触发条件包括：
- 手工熔断（强制打开熔断器）
- 取消熔断（强制关闭熔断器）
- 自动熔断（规定时间内请求数超过阈值并且失败率达到阈值才会触发熔断, 熔断后指定时间内尝试取消熔断）
这个配置通过写入到配置中心及时下放到各个应用，实现动态配置能力。4、限流
EOS现在的限流是对于每个应用实例独立计算，如设置每秒访问10次，一个应用有3个实例，则这3个实例每个都允许每秒访问10次。限流是通过在服务端的Filter里使用Guava的RateLimiter实现。这个配置通过写入到配置中心及时下放到各个应用，实现动态配置能力。5、负载均衡
EOS的负载均衡使用的是Ribbon实现，可以针对每个目标客户端设置规则类型，支持：随机、循环、自定义等；另外还支持容错，容错是指当对某个实例的调用超时后的补救措施：
- 快速失败（Failfast）：什么也不做，直接抛出异常
- 失败自动切换（Failover）：尝试访问新的实例，按指定次数尝试
- 失败原地重试（Failback）：尝试访问同一实例，按指定次数尝试
这个配置通过写入到配置中心及时下放到各个应用，实现动态配置能力。以上向大家分享了普元EOS 8 微服务平台里治理与统计分析，希望对大家有所帮助。不足之处，也请多多指正。
精选提问：
问1：配置生效要重启应用吗？日志统计的实时性如何？
答：配置可以是热更新的，不需要重启应用；接口统计暂时不是基于日志分析的，直接从每个实例中获取统计信息。
问2：EOS微服务平台底层是基于哪些技术？这个系统我们公司购买， 需要多少钱？
答：主要用到的是 Spring Cloud，Apollo，SkyWalking，ELK。可以拨打400-820-5821进行产品咨询、了解详情。
问3：微服务治理的本质是什么，除过熔断、限流，微服务治理还包括哪些，特别是微服务的安全体现在哪些方面？
答：个人觉得治理还是为了保证业务系统正常平稳的运行。只是微服务架构下，进程更多，交互更多，管理复杂，异常错误会容易放大。除了熔断、限流，比如实例上下线，统一配置，流量管理，应用分组(多版本)等。我们现在是在网关上做的鉴权，每个系统都有一个网关，系统对外的接口需要先在网关上发布，并对接口进行授权指定哪些客户端可以调用，发放授权码。
问4：数据共享安全管控中如何对非结构化的数据资源进行安全控制，如影像地图等，如何进行按地理区域来控制访问的权限及安全？
答：数据共享安全管控中对影像地图类非结构化的数据资源很难从内容上去做控制，可以配置地理区域标识与服务的对应关系、地理区域IP与服务对关系，从服务访问的角度来控制。
关于作者：王文斌，普元高级软件工程师，开源技术爱好者，容器技术专家，曾参与浦东发展银行BPM项目、银联PAASV1等项目。
关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享。