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

微服务治理权

开发和运维吵架

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

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

微服务治理的用户

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

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

微服务的统一运维

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

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

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