容器云容器服务治理和微服务治理
很多人在讨论容器云平台服务治理的时候往往把“容器服务”和“微服务”混为一谈，所以在建设容器云平台的服务治理能力时往往使其复杂化。在最初建设容器云平台时，我就有个疑问，为什么kubernetes自身有服务注册机制，部署的SpringCloud服务还要用Eureka注册中心等。后来逐步理解了，这是两套机制。还有很多人把ServiceMesh服务网格看作是微服务治理、也有人叫它“第二代微服务”。其实这都是不同的机制，不同的实现方式，各有适用场景。在实现容器云平台微服务治理时，不能和容器云平台的容器服务治理等混淆。SpringCloud、微服务、ServiceMesh、容器服务等是不同的概念、不同的内容。要在容器云平台实现以服务为中心的服务管理和治理能力，这些概念和内容必须能够深入理解和明确区分。
容器服务和微服务
容器服务和微服务是两个完全不同的概念。容器服务承载的不一定是微服务，微服务也不一定部署在容器中。即便微服务部署在容器中，对外提供微服务能力，但其在容器云平台内部是以容器服务的形式存在的，一个微服务可能包含若干个微服务实例（在容器云平台表现为容器服务实例，kubernetes中由Pod承载），这样，微服务就可以利用容器的弹性伸缩特性，实现自动扩缩容。
也有人把oracle数据库、weblogic等部署在容器中，提供数据库和应用服务器功能，但这些服务就不能称之为微服务。所以微服务和容器服务并等同，在实现服务治理的时候需要考虑是在哪一层实现服务治理，是对容器服务还是微服务实现治理？不同层次实现方式是有差别的。
容器服务治理
我们先讨论容器云平台容器服务治理。Kubernetes提供了容器服务的注册发现、负载分发、资源调度等机制，所以大多数情况下其实是可以不需要关心容器服务的治理能力的。不过kubernetes 本身的一些服务治理机制存在不足，在企业生产环境，需要根据实际的来选择相应的能力实现。
Kubernetes默认利用CPU和Memory的使用量作为弹性伸缩的指标。但是这两个值在实际环境往往是没太大意义的。CPU变化可能很频繁，Memory也可能一直被占用，基于这些指标扩容往往带来问题，所以在容器云平台的弹性伸缩需要通过实现别的指标来满足自动的扩缩容，比如平均响应时间、单位负载等。这就要求基于kubernetes实现的容器云平台具备采集和处理这些指标数据的能力。这也是我们要求博云实现 “三视角四层次一闭环”架构的重要原因，需要在Ingress组件中扩展实现服务的一些能力，或者在容器云平台层跨集群的这样的能力，也是平台良好性能和扩展性的架构设计要求。
很多容器云平台厂商都把容器服务和微服务治理混为一谈，在kubernetes层面去支持SpringCloud服务和其他微服务架构开发的服务，会导致整个设计复杂化。我们提出两层的服务治理体系就是这样考虑，微服务治理放在容器云平台外部，在容器云平台只扩展实现容器服务治理。多集群场景下，需要支持跨集群的容器服务管理和治理能力，这都需要在容器云平台层来实现，所以在kubernetes容器调度管理层之上的实现单独的一层容器云“平台层（业务应用支撑层）”是非常有必要的。
在平台层，可以支持多集群之间的跨集群调度管理，支持多集群之间的流量分发、A/B测试、限流熔断等以及采集集群内部服务处理的响应时间（统计最大、最小、平均等）、请求数、处理链路、处理时间等数据。有了这些数据就可以很容易实现APM和统一监控管理。另外，也可以统一纳管信创集群而不需要更改任何的功能。
跨集群的容器服务治理从某种角度上来看，也可以认为其是微服务治理，不过为了更好地理解和区分容器服务和微服务，我们把基于容器云平台上不管是集群内或集群间的服务治理统称为容器服务治理。
ServiceMesh
我从2017年就开始关注服务网格ServiceMesh，理论上它还是非常适合容器集群内的容器服务治理，虽然也支持跨集群的服务治理，但并不是很好用。另外ServiceMesh通过增加一层代理来代理东西向流量，势必会影响到服务之间调用的性能，增加延迟。我虽然一直关注它，但在实际环境中却没有采用，也在于其一方面不够成熟，另一方面更不愿意通过加层的方式来实现。我一直期望通过容器云平台自身的能力来实现服务治理，包括微服务治理和容器服务治理能力。
我一再强调，用不上的组件不要打包到服务镜像中。你可能无法预计哪些无用的垃圾组件在某一天可能会带来致命的漏洞。所以我一再告诉博云的人员，要删除不必要的组件，做减法，才能达到最优性能。
微服务治理
我们所讨论的微服务通常是从架构（也就是业务和功能划分）角度来说的。微服务是一种架构方式，微服务的实现有很多种方法，比如领域驱动设计方法（DDD），主数据驱动设计方法等。主数据本身就是企业内部共享的数据，所以基于主数据构建企业微服务是一种省力的方式；DDD则略显复杂化。微服务治理可以跟容器没有关系，只不过微服务（无状态的微服务）的分布式特性非常契合容器的轻量、弹性伸缩特性，容器可以承载微服务而运行于容器云平台。所以这种场景下可以说容器服务是在容器云平台内部对微服务实例的承载，是技术视角。可以把他们看作是两个层次，这样在实现服务治理时就相对容易理解和容易实施了。
首先考虑如果不用容器如何实现服务治理？SpringCloud等自身提供了相应的组件来实现微服务的管理和治理能力，这是一种方式。但这种方式严重依赖这些组件，耦合性非常高。一旦出现漏洞等问题，则可能很多个服务都需要更新和重新部署。另一种方式是把服务治理的能力抽象提取出来，比如用API网关来实现服务治理，认证授权、访问控制、路由分发、限流熔断等都在网关层实现。微服务专注于业务逻辑。这样简化了微服务的代码控制逻辑，不过压力都传导给了API网关层。API网关需要支持弹性扩缩容、集群化、负载分发等能力。
其次，如果使用容器来承载微服务，一个业务应用可能由多个分布式的服务组件构建，而每个服务组件可以部署多个实例来实现分布式部署。每个实例可以运行在Kubernetes pod中。Kubernetes提供多种服务暴露方式，比如NodePort、Ingress等，映射容器服务到Kubernetes外部，使其可以从Kubernetes外被访问到。但某些场景下，一个服务的多个实例可能会部署到多个集群甚至多个数据中心的不同集群中，从而实现备份和高可用等，这就超越了Kubernetes服务提供的服务访问能力，需要在多个Kubernetes集群之间实现请求的分发。在容器云平台多集群管理能力上，就需要实现服务的管理和治理能力。最初我们容器云平台设计提出“以应用管理为核心”的一个方面就是基于这样的考虑。
容器云平台微服务治理
容器云平台的微服务治理其实和容器云平台外部的微服务治理实现比较类似了。容器云平台层服务治理一定要考虑跨集群的，要在不同集群之间实现负载均衡、路由分发、认证授权等能力。这和集群所提供的Ingress虽然说功能类似，但是在两个层面。如果容器云平台不具备这样的能力，也可以在平台外部实现，替代平台层的服务治理能力，代为管理多集群。不过这样系统之间的协同要求相对要高。
实践中遇到的问题
Kubernetes提供多种服务暴露方式，Ingress、NodePort都可以实现负载分发。理论上在Kubernetes集群内部，多实例之间自动实现了负载均衡。不过在我们实际实践中，也遇到了实例之间不均衡导致某个实例资源使用高而整体性能下降问题。这和负载均衡的实现有关系，Scheduler和worker最好不要放在一起。
总的来说，在设计实现容器云平台服务治理能力时，需要明确是在哪个层次来实现，采用什么样的方法实现，所面对的对象是什么等。不同的层次所要解决的问题可能是不一样的，比如集群内容器服务和跨集群的微服务等。厘清了这些概念和问题，方案设计和落地就相对容易了。