云原生不是普及问题，更多是落地问题
InfoQ编辑赵钰莹
讲述：丁婵大小：6.51M时长：04:44
云原生是现在的热门技术趋势，很多开发者都对由此而兴起的一众技术十分追捧，但推及到落地实践环节，大部分企业还都处于探索阶段。近日，InfoQ 采访了灵雀云 CTO 陈恺，他表示云原生发展到现在已经不是普及的问题，而是落地的问题了。具体观点如下。
单就某一种技术的概念普及来说，可能并没有什么难点。在科技发展的过往数十年中，技术本身历经了数次更迭，开发者对新兴技术的接受度还是比较高的。随着 CNCF 社区的发展，开发者对于云原生这一概念基本达成了理解和共识，普及并不是非常难的事情，而难点在于落地。
不同技术的落地难度也不一样，容器是相对来说比较简单的，对应用进行容器化并运行在 Kubernetes 上就可以了，目前 Kubernetes 的核心部分已经趋于成熟，从去年年底，很多开发者就开始说 Kubernetes 正在变得 boring 。这有几层意思：
第一，核心的技术变更开始变慢，这是向好的迹象，一方面表明技术已经成熟，另一方面定位和边界非常清晰，哪些东西放在核心里面，哪些东西通过扩展去做非常明确；
第二，创新仍在持续，但创新会转移到技术栈的更上层；
第三，Kubernetes 会变得无处不在，人们会对它习以为常。
Kubernetes 核心社区主要致力于三个主要目标：
第一，持续提升核心技术栈的稳定性、易用性、可扩展性；
第二，将更多的技术集成到以 Kubernetes 为核心的 “云原生技术栈”；
第三，将“云原生技术栈” 扩展到更广泛的应用场景。
此外，CNCF 社区正在将更多的技术集成到 Kubernetes 的生态，越来越多的应用场景和技术会被推到 Kubernetes 中，虚拟机可以用 K8s 管，数据中心承载的内容可以用 K8s 管，Serverless 基于 K8s 实现等。
但是，DevOps 和微服务改造都不是那么容易。具体来说，DevOps 涉及文化、组织架构等与人相关的因素。微服务架构改造则涉及重新开发、重构、重写等问题，如果是核心业务改造，风险又会非常大。
微服务架构本质上是以运维的复杂度为代价去换取敏捷性，这时候要考虑企业是否真的有敏捷性需求，如果答案是否定的，就不要引入更多的复杂度。如果答案是肯定的，需要引入复杂度，那么如何管理多出来的复杂度，就是业界一直在讨论的微服务治理的原因。微服务治理不只是 Service Mesh 或者 Spring Cloud，它需要一个完整的基础设施去支撑。
微服务最大的挑战是引入运维的复杂度，所以自动化运维非常重要，尤其是可观测性。在微服务后面需要各种后端数据服务，如何管理后端的数据服务，把这些服务暴露给应用，是要考虑的问题。
最后，聚焦到微服务内部，服务和服务之间的连接和通讯治理，这是狭义上的微服务治理。这个问题的解决方案现在有一个很时髦的名词叫 Service Mesh，微服务治理进入到后 Kubernetes 时代。早期，微服务作为一个需求、一个用例在推动容器和 Kubernetes 的发展，当 Kubernetes 变成标准之后，它会反过来驱动，重新定义微服务治理的最佳实践。
如今的云原生已经在业界达成共识：如果基于 Kubernetes 平台做微服务治理，ServiceMesh 就是最佳实践。在数据层面，Envoy 差不多是一个标准，各种选型包括 API 等都会倾向于使用 Envoy，因为其对标准的支持力度最大。在控制层面，虽然还没有形成所谓的标准，但 Istio 也是目前唯一的选择，未来是不是会出现更多方案是值得期待的。
总体来说，如果需要调整业务代码和架构，改造过程就会比较困难。因此，陈恺建议对于新技术有必要先想清楚再挑一部分慢慢沉淀，直接大刀阔斧的改革不是很有必要。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论