微服务框架需要考虑哪些治理环节？

一、微服务框架需要考虑哪些治理环节？

• 服务注册发现

微服务当中有很多服务，几十个上百个，它们当中有错中复杂的依赖关系，这个时候就存在服务的消费者怎么发现生产者，这个就是服务注册发现需要解决的问题。

• 负载路由

为了应对大的流量，我们的服务提供方一般都是大规模部署，这个时候就存在服务的负载均衡的问题，另外我们的服务需要路由，这个能力非常重要，如果我们需要灰度发布或者蓝绿发布的机制，那么需要考虑软路由的机制。

• 监控-日志

日志对于我们后期排错找出问题，定位问题是非常关键

• 监控-Metrics

当我们需要对服务的调用量进行监控，对服务延迟出错数有一个好的监控手段，这就是me监控环境

• 监控-调用链

微服务有错综复杂的调用关系，就像一个网状一般，如果没有好的调用链监控，开发人员很容易迷失在当中，出问题很难定位，有了好的调用链监控会帮助我们快速定位问题，更好的理解整套微服务系统。

• 限流熔断

微服务是一个分布式系统，如果没有好的限流熔断措施，当一个服务出现故障或者出现延迟，会造成整个系统瘫痪。

• 安全&访问控制

有些服务并不希望所有的人都能去调用到，涉及到一些敏感信息，比例跟钱相关的信息，那么我们需要安全和访问的控制策略，来限制对这些服务的访问。

• REST/RPC

rpc和rest根据之前的对比，两者各有优劣，如果一个微服务框架中能支持这两个调用，能兼容更多的技术栈，会更加的灵活

• 序列化xml/json/二进制

序列化中，有高性能但对开发人员不优化的二进制序列化，也有对开发人员相当友好的但性能未必最佳的文本式序列化，这个需要根据场景进行灵活的配置，消息系列化协议

• 代码生成

现在在大规模开发的情况下，比较推从一个契约驱动开发的方法，开发人员先定立契约，代码自动生成的方式生成对应的代码脚手架，这个在大规模开发的时候更能确保代码的一致和规整

• 统一异常处理

我们希望服务治理的环节能集成统一的服务异常处理的能力，这样的化异常能够达到更加标准化，出现问题能更好定位好属于什么类型的问题。如果说没有这样的一个环节，大家各自的玩法不一样，抛的异常各异，出现问题难以定位和无法标准化友好输出。

• 文档

微服务最终是要给消费者去使用，暴露出去的API如果没有好的文档，只提供出一些代码，接入方接入的成本会变成比较高，好的文档体系是各方协调和效率的保证。

• 配置集成

微服务框架需要集成集中式的配置能力，避免各个服务间各自配置，增快参数调整的速度和规范统一格式。

• 后台服务集成 DB、MQ、Cache

微服务治理的核心思路就是把上面讲到的各个环节沉淀下来，变成平台和框架的一部分，开发人员可以更加专注业务逻辑的实现，在实现业务逻辑的时候不需要去关注外部环节的，从而提升开发的效率，治理环节沉淀在框架之中有专门的平台架构团队去进行管控

二、微服务监控系统分层和监控架构？

• 监控分层：（从上到下）

• 端用户体验监控：性能、返回码、城市、地区、运营商、版本、系统等。

• 业务监控: 核心指标监控、登录注册、下单、支付等；

• 应用层监控：url,service,sql，cache可用率,响应时间，qps;

• 系统层监控：物理机、虚拟机、OS，cpu,memory,network,disk等。

• 基础设施监控：网路、交换机、网路流量、丢包、错包、连接数等。

• 监控指标：

• 日志监控

• Metrics监控

• 健康检查

• 调用链监控

• 告警系统

三、微服务调用链监控

	CAT	zipKin	pinpoint
调用链可视化	有	有	有
报表	非常丰富	少	中
ServerMap	简单依赖图	简单	好
埋点方式	侵入	侵入	不侵入字节码增强
Heartbeat 支持（心跳）	有	无	有
Metric支持	有	无	无
Java/Net客户端支持	有	有	只有java
Dashboard中文支持	好	无	无
社区支持	好，文档较丰富， 作者在携程点评	好，文档一般 暂无中文社区	一般，文档缺 无中文社区
国内案例	携程点评、陆金所	京东、阿里不开源	暂无
源头祖先	eBay CAL-Certralized Application Logging	Google Dapper	Google Dapper

文章内容参考：杨波老师的微服务核心架构20讲