微服务的设计和拆分一直是个难点。笔者也多次跟包括容器云平台厂商在内的很多人讨论过，如何使用微服务架构来实现容器云平台的设计。有句话叫 “ 灯下黑 ” ，在设计实现容器云平台支持微服务应用的时候，往往没有考虑到容器云平台自身的微服务组件划分。就像很多做 DevOps 咨询和 DevOps 平台的公司自己还没有实现 DevOps ，所以并不真的能体会到 DevOps 的精髓。不是说指鹿为马、称之为 “ 微服务 ” ，它就真的是 “ 微服务 ” 了。如果自己不真正用容器云平台支撑自己的业务，可能就无法真正理解容器云平台微服务架构的设计需求，也就很难理解客户的关心和真实需要。

一、 从用户体验说起

引入微服务很重要的一点是为了松耦合单体系统架构，减少依赖，实现敏捷更新，降低变更所带来的影响，同时便于快速扩展，使终端用户无感，给用户带来好的体验。当前我们过分强调微服务的优势而有意无意忽略了微服务所带来的麻烦，这导致用户体验就很不好。任何一个事物都有两面性，需要辩证的去看待它。如果为了微服务而微服务，就会使简单的问题复杂化。以前笔者也提到过，有容器云平台 Portal 划分了 20 多个微服务，但这些微服务并没有分布式部署的需求，也没有扩展的需求，彼此之间还紧耦合，部署之后有 20 多个容器，最重要的是，还做不到一个组件一个组件独立升级，每次都要等几个月升级整个版本。说到底这还是单体竖井系统思维，使运维和管理复杂化。这样的微服务设计纯粹是不懂微服务，纯粹是为了微服务而微服务，把简单问题复杂化。

二、 容器云平台架构设计及微服务化

容器云平台作为企业的一个基础设施平台，核心能力是支撑业务应用的部署运行，需要考虑频繁的迭代升级需求。单体竖井系统之所以发展为微服务架构，就在于为了减小变更所带来的影响和提升迭代的效率。容器云平台采用微服务架构并不是因为微服务架构比较流行，而是微服务架构可以解决容器云平台自身的松耦合、敏捷变更、分布式部署等需求。

在最初容器云平台架构设计时我们提出的 “ 三视角四层次一闭环 ”架构设计，用微服务架构的设计思路比较好的解决了平台各组件的松耦合问题。“三个视角”是从管理的角度来设计的，“管理员视角”侧重平台的管理、组件的对接和基础设施资源的维护，其目的是为了租户用户便利地使用平台来管理和运维业务应用。“租户视角”是“以应用管理为核心”实现微服务业务应用的部署、配置、运行、监控、弹性扩缩容、负载分发、安全管控等管理和治理能力。“标准化交付视角”以镜像仓库为媒介分离研发和运维之间的耦合关系，以镜像为标准化交付物，封装服务运行环境和运行配置细节，实现环境一致性，减少因环境变化带来的异常和故障，保障生产环境的稳定性，从而提升运维的可靠性。“四层次”的“业务应用层”关注业务的管理和治理等运维体验，由平台层赋能，提供相应的管理治理能力。“平台层”是在 Kubernetes 之上对业务应用管理和治理能力的封装，同时映射 kubernetes 的管理、治理和调度能力，特别需要考虑认证权限准入的访问控制能力映射。 “ 资源调度层 ” 则基于 “ 基础设施资源层 ” 所能提供的资源服务能力实现资源调度，比如虚拟化、物理服务器、行业云、公有云的资源调度，这基于基础设施资源层的封装能力。这也是我们一直强调用云管平台来统一管理基础设施资源的原因。 “ 一闭环 ” 则侧重研发、运维的 DevOps 闭环过程自动化、自服务能力实现。

在这个架构设计中，平台层的很多组件比如认证、权限、配置、镜像仓库、日志、监控、告警等都是独立的组件，以插拔的方式和容器云平台无缝融合在一起。这些组件都可以独立成为企业内的一个平台，其能力用微服务架构用于构建可复用的技术中台服务。

作为终端用户，关注容器云平台的核心资产是业务应用。业务应用层，也就是 Portal 是管理租户和租户业务应用的入口和工具。容器云平台不能用开发人员的思维来设计，需要从终端用户视角来设计，给用户好的使用操作体验。另外 portal 的组件服务划分就需要基于实际的情况来定义。需要认识到的是，微服务的划分和具体的部署方式是两个层面。单个微服务可以打包部署，多个微服务也可以一起打包部署。这要基于是否有分布式部署的需求。如果 Portal 的组件都部署在一台机器上，没有必要分几十个服务独立部署，特别打包成几十个镜像。不说组件之间的交互额外带来性能损失，也导致节点上资源的很大浪费，而且带来很多资源分配和调配及维护工作量。如果资源分配不合理，就可能导致一些组件服务异常，或不断重启。微服务不是小服务，微服务的范围划分需要基于实际的组件服务关系和部署需求来确定。

平台组件对系统资源的需求往往会随着节点的增加和 pod 的增加而增长。比如说监控组件和日志组件，最具有代表性。这些组件如果使用容器部署，需要配置纵向弹性伸缩。理论上，平台自身的组件数量不应该太多，占用的资源也不能太多，这要求厂商对平台组件去做优化，而不是随随便便就扔给客户。节点上不能因为系统容器而导致节点资源消耗过大，不能让业务容器没有资源可用。

Kubernetes 本身就是组件化、插件化服务架构，因此基于 kubernetes 的容器云平台的微服务设计重点在于 Portal 和平台层组件封装以及节点的组件上。

三、 平台组件容器数量及资源占用问题

由于梳理容器云安全问题，发现在数千个容器中也只有四分之一的容器是业务容器，另外的近四分之三竟然都是容器云平台自身带来的容器。这为容器云平台的运维管理带来很大的工作量，也充分说明了容器云平台组件设计的不合理性。每个容器节点理论上不应该有那么多平台的容器。笔者也理解每个节点都需要实现众多的功能，比如日志采集、监控、容器网络组件、存储插件、安全管控组件等等，但是这些组件如果不进行整合和重新设计，就会喧宾夺主，占用很多节点的资源，导致整个容器节点部署不了几个业务容器，会造成极大的浪费，也带来额外的运维工作量。容器有轻量的特点。但再轻量也架不住数量众多。因此在进行微服务设计的时候，需要从整体上来考虑微服务组件的定义，每个节点上的平台容器占用节点的资源不应该超过 10% ，数量也尽可能少，服务组件尽可能整合优化。

容器云平台其实并不像很多厂商所宣称的那样节省资源。某些情况下还会更浪费资源。容器资源的使用取决于容器中运行的应用及应用架构、应用运行编排、资源限制等。想要节省资源，就需要做好微服务的设计，以及容器云平台自身的微服务设计，同时还要规划好业务应用的资源使用时段，实现不同类型应用的分时段资源占用，这样才能充分的利用资源。但就容器云平台本身的架构设计来说，需要充分考虑业务资产管理和资源使用的问题。

总的来说，容器云平台微服务架构设计是平台弹性、可扩展性的要求，是容器化 PaaS 平台建设和容器化云操作系统建设的要求。不过微服务拆分的能力直接关系着整个平台的可维护性和稳定性，以及客户的体验和运维成本。如果要做好容器云平台产品，采用微服务架构实现弹性和可扩展性，就必须在微服务组件设计方面以用户思维，深入实践和思考，真正解决客户关注的问题。