看到标题几乎所有人都会产生疑问，K8s作为一个部署应用容器的编排工具为什么和Dubbo、SpringCloud放在一起讨论？事实上我们应当从他们三者产生的背景、要解决的问题已以及历史的演进上来看。本质上三者要解决的问题和最终要实现的目标是一致的，只不过他们解决问题的方式有所不同。K8s作为后起之秀，他较前两者所处的层次更高。
事实上笔者在从业生涯当中，有见过使用SpringCloud应用的案例，但这些大多处于SpringCloud向K8s迁移的过渡阶段。当然这三种微服务的架构方式都各有优劣，生产过程中不存在银弹，只有最合适，没有完美的解决方案。
通常情况下，微服务作为一种架构手段，其目标都是为了实现交付业务价值，脱离业务场景和实际生产环境的架构都是假想的架构，合适优秀的架构他所实现的质量属性(也可以称为非功能性需求)价值一定要能最终产生业务价值。要想快速交付业务价值，使得开发人员更多的关注业务本身，它需要一些底层的基础设施的支撑，这些支撑都是微服务一般需要关注下图的一些目标。
Dubbo是阿里巴巴经过多年大规模生产沉淀的产物，应用可通过高性能的 RPC 实现服务的输出和输入，同时具备成熟的流量治理能力。但是它对SpringCloud和K8s而言，技术相对陈旧，组件之间的耦合性较高。
SpringCloud则是以Netflix为背书，社区相对更加活跃。它抽象出来的各个组件使用相对灵活，使得对于开发者而言更加友好，但是和SpringBoot结合相对紧密，嵌入式的容器更耗资源。
K8s由于问世相对较晚，所以它思考和解决问题的层级更高，将微服务关注的几个目标以平台的方式抽象出来，真正做到了语言无关，对微服务的关注点覆盖也更全面。但是相对于前两者而言，那面有“过重”的嫌疑，它更偏向于运维层面，具有更高的技术门槛。下面可以针对微服务的关注点在它们三者之间作横向的对比。
通常情况下，微服务对上述几个关注的问题会随着业务规模的变化，它的侧重点也会随之发生变化，这要求我们在选型的时候需要根据业务模式和整体的运营环境和场景综合考量。
同时，不同的技术路线尽量不要混合使用，这可能使得技术架构过于复杂，同时增加开发人员和运维的负担，应尽量趋近于一致的体系。对于中小型的企业，尽量避免自建基础设施，这些基础设施可以外包给公有云服务厂商。
当然，如果因为某些历史或其他原因导致产品架构不得不经历混搭的过程，那么对于他们共有的功能需要有对应的取舍。例如纯粹的SpringCloud应用部署在K8s上时，可以退化SpringCloud本身的部分功能，继而直接使用K8s的服务发现和配置管理等功能。SpringCloud官方提供SpringCloud Kubernets就是一个案例，但一般来讲，个人更倾向于使用SpringBoot + K8s的微服务架构。
