转载

微服务杂谈一微服务治理权

微服务治理权

在前几年刚开始做微服务的时候，面临着一个两难的问题，就是微服务的控制权到底是放到应用内部还是在统一的平台层。Kubernetes具有服务注册和发现、配置、网关路由等功能，spring cloud有自己的服务中心、网关、负载等组件。

这时大家很容易吵起来，从统一运维管理的平台层面自然希望能够使用平台的基础能力来进行统一的管控；从应用开发者层面，希望自己能够在代码中实现这些基础功能而不依赖于某一个具体的运行平台的能力。

到底谁才是微服务治理功能的用户呢？是开发人员吗？当然不是，除非你是DevOps组织，否则上线后你真能找到开发来给你治理吗。

上线后何时限流，何时降级，何时进行扩容，都是运维人员根据线上应用的运行情况进行操作的。

争吵的出发点上都没有任何的错误，并且诉求都是合理的，所以我将两方面的需求进行了融合，即满足服务治理用户的需求，又实现开发微服务化应用开发运行的要求。

首先，让控制面和数据面从应用中独立出来，应用开发者仍旧只需要关注于自身业务逻辑的代码实现，而不需要关注外围设施的能力提供。

然后选择了kong和consul这两个即可以融合到kuberentes平台中又可以独立进行部署提供能力的技术组件，来实现微服务化的核心能力。这样我们实现了微服务本身对重量级PaaS平台的解耦，又通过轻量级的微服务管理平台来实现快速的构建微服务基础设施。

微服务杂谈一微服务治理权

原文 https://blog.csdn.net/cnsword/article/details/105700741

正文到此结束

所属分类：软件架构编程技术

本文标签： PaaS consul 数据开发服务注册开发者组织 Spring cloud UI Kubernetes 希望配置需求 Word 代码 http 部署 https SDN src 微服务 spring 管理 Uber 限流
版权声明： 本文为互联网转载文章，出处已在文章中说明(部分除外)。如果侵权，请联系本站长删除，谢谢。
本文海报： 生成海报一生成海报二

本站定位：个人技术类博客

本站作用：写博客、记日志、闲聊扯淡鼓捣技术。