微服务框架需要考虑的治理环节

原文：https://juejin.im/user/58a2aadb570c35005782847b/posts

一个国家如果人多了那么就需要一个*，这个*需要对这个国家的人民进行管理和治理。在微服务的体系也是如此，如果在一个公司的微服务体系多了也需要有管理和治理的能力。

下图把跟微服务治理相关的环境列举了出来，一个好的微服务需要关注哪些治理环境

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

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

日志对于我们后期排错找出问题，定位问题是非常关键，我们一套好的监控治理框架需要集成日志服务

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

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

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

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

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

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

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

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

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

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

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