博客昵称：架构师Cool
最喜欢的座右铭：一以贯之的努力，不得懈怠的人生。
作者简介：一名Coder，软件设计师/鸿蒙高级工程师认证，在备战高级架构师/系统分析师，欢迎关注小弟！
博主小留言：哈喽！各位CSDN的uu们，我是你的小弟Cool，希望我的文章可以给您带来一定的帮助
百万笔记知识库， 所有基础的笔记都在这里面啦，点击左边蓝字即可获取！助力每一位未来架构师！
欢迎大家在评论区唠嗑指正，觉得好的话别忘了一键三连哦！😘

微服务治理

服务注册发现

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

服务的负载均衡

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

监控-日志

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

监控-metrics

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

监控-调用链埋点

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

限流熔断

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

安全-访问控制

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

rpc & rest

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

序列化

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

代码生成

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

统一异常处理

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

文档

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

集中配置中心

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

后台集成MQ，Cache，DB

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