微服务服务治理

引入微服务后出现的服务治理的新问题，例如：动态服务发现、负载均衡、TLS加密、HTTP/2 & gRPC代理、熔断器和重试、路由规则、故障注入和遥测
业务服务演进到微服务架构后，服务治理问题是否就此终结？远远没有。在微服务架构下，出现了新的服务问题，从而需要对微服务进行服务治理。那微服务又有哪些问题需要治理？
1、服务注册与发现。单体服务拆分为微服务后，如果微服务之间存在调用依赖，就需要得到目标服务的服务地址，也就是微服务治理的”服务发现“。要完成服务发现，就需要将服务信息存储到某个载体，载体本身即是微服务治理的”服务注册中心“，而存储到载体的动作即是”服务注册“。
2、可观测性。微服务由于较单体应用有了更多的部署载体，需要对众多服务间的调用关系、状态有清晰的掌控。可观测性就包括了调用拓扑关系、监控（Metrics）、日志（Logging）、调用追踪（Trace）等。
3、流量管控。由于微服务本身存在不同版本，在版本更迭过程中，需要对微服务间调用进行控制，以完成微服务版本更迭的平滑。这一过程中需要根据流量的特征（访问参数等）、百分比向不同版本服务分发，这也孵化出灰度发布、蓝绿发布、A/B测试等服务治理的细分主题。
4、安全。不同微服务承载自身独有的业务职责，对于业务敏感的微服务，需要对其他服务的访问进行认证与鉴权，也就是安全问题。
5、控制。对服务治理能力充分建设后，就需要有足够的控制能力，能实时进行服务治理策略向微服务分发。而对于微服务治理，传统的做法都是需要引入微服务研发框架，配合控制平台完成如上服务治理能力的建设。比较常见的微服务研发框架包括SpringCloud、Dubbo等。讲到微服务框架本身，不妨多说一些。服务本身需要治理，其实传统微服务框架本身也存在一些问题，同样需要”治理“：
1、微服务框架本身的引入需要业务服务有感知，需要修改代码或引入框架；
2、框架本身的升级成本高，需要结合业务状态重启业务以更新框架；
3、多语言支持不足。
SpringCloud、Dubbo都是Java语言主打框架，要想支持更多语言就变得十分困难