云原生那么多选择，别光盯着一个技术栈或者平台不放，风险太大了

（来源：InfoQ社区多位资深架构师的线上讨论分享）

云原生这个概念现在火得不行，感觉不提云原生就落伍了，但问题也跟着来了，很多人一提到云原生，脑子里立马蹦出来的就是Kubernetes，就是Docker，再不然就是Service Mesh里那几个常见的名字，比如Istio，好像整个云原生的世界就被这几样东西给框住了，这种想法其实特别危险，相当于把所有的鸡蛋都放到了一个篮子里，技术这东西，变化比翻书还快，今天还是行业标准，明天说不定就有更优的解决方案冒出来，或者现有的方案暴露出你无法承受的缺陷，你要是把整个公司的技术架构都死死地绑在单一的技术栈或者平台上,那风险可就太大了。

（来源：某中型互联网公司CTO在技术复盘会上的内部发言）

我们公司就吃过这方面的亏，前几年，我们看准了容器化的趋势，决定全面拥抱Kubernetes，当时团队热情很高，把所有应用都往K8s上迁，开发、测试、运维都围绕着这一套东西来搞，也确实享受到了它带来的标准化和弹性伸缩的好处，去年我们遇到了一个非常具体的问题：我们核心业务里有一个对性能要求极高的组件，在K8s的网络模型下，始终无法达到我们预期的性能指标，我们花了大量人力去排查、优化，甚至去研究K8s的底层源码，效果还是不尽如人意，这时候我们才发现，自己已经被K8s“套牢”了，整个技术体系都是基于它构建的，想换个环境或者引入其他调度方案，成本高得吓人，几乎等于重写一部分核心架构，最后我们不得不采取了一个折中的、很别扭的方案来解决性能问题，这件事给我们敲响了警钟：再好的技术也不是万能的银弹，过度依赖单一技术栈,会让我们在遇到特定问题时失去灵活性和选择权。

（来源：Hacker News上关于“供应商锁定”话题的热门讨论帖）

这种风险不仅仅是技术层面的，还有商业层面的，也就是常说的“供应商锁定”，如果你把所有业务都构建在某个单一的公有云平台上，比如就认准了AWS，或者就只用了阿里云，那你其实就在无形中给了这个平台巨大的议价权，刚开始他们可能会给你很多优惠和便利，让你觉得物超所值，可一旦你的业务深度依赖了他们的特定服务（比如某个独有的数据库服务、消息队列或者函数计算服务），你的数据、你的业务逻辑都和这个平台紧密捆绑，再想迁移到其他平台，那个成本会让你望而却步，到时候，平台方提高服务价格，或者改变服务条款，你很可能就没有什么讨价还价的余地了，只能被动接受，这就像租房子，你把全部家当都按照这个房子的格局定制了家具，房东突然要涨租金，你搬家的代价太大,只能忍气吞声。

（来源：CNCF基金会发布的云原生景观图及其演进分析）

其实大家去看看云原生计算基金会（CNCF）那张著名的“云原生景观图”就明白了，那上面密密麻麻布满了成百上千个项目和工具，覆盖了编排、服务发现、监控、日志、安全、存储等十几个大类，这张图想传达的核心信息之一就是：云原生是一个庞大的生态系统，充满了多样化的选择，Kubernetes只是这个生态中在编排领域目前最受欢迎的一个项目而已，但它绝不是全部，比如在服务网格方面，除了Istio，还有Linkerd、Consul Connect等值得关注的选项；在无服务器领域，有Knative、OpenFaaS等开源框架；在监控领域，Prometheus也只是一套非常流行的组合中的一环，还需要搭配Grafana、Alertmanager等工具一起使用，死盯着一个点,你会错过整片森林的精彩和可能性。

（来源：多位技术博客作者关于“最佳工具”与“最适工具”的辨析）

那我们应该怎么做呢？关键是要转变心态，从寻找“唯一的最佳技术栈”转变为选择“最适合当前场景的技术组合”，这意味着我们要有意识地去构建一个具备韧性和可塑性的技术架构，在设计微服务时，可以遵循一些通用的标准协议（如HTTP/gRPC），但允许不同的服务根据自身特点选择最合适的编程语言和轻量级框架，而不是强制所有服务都必须用Java和Spring Cloud，在基础设施层面，可以尽量使用抽象程度更高的、跨平台的管理工具（如Terraform、Crossplane），让你在底层资源的选择上保有灵活性，今天可以跑在A云上，明天如果B云有更吸引人的特性,可以相对平滑地迁移一部分工作负载过去。

（来源：实践经验总结）

拥抱云原生是对的，但一定要保持开放的心态和清醒的头脑，别把云原生等同于某一个具体的技术或平台，它更像是一种方法论，一种构建和运行应用的方式，它的精髓在于利用云计算的优势，实现应用的敏捷、弹性和可扩展性，而实现这些目标的道路有很多条，多了解、多评估、甚至在非核心业务上进行小范围的试点和尝试，保持技术选型的多样性，这样才能在技术浪潮的快速变迁中，让你的系统架构更具抗风险能力，让你们的业务发展之路走得更稳、更远，只盯着一个技术栈不放，无异于一场豪赌,而赌注就是你业务的未来。