Ada云原生时代已经到来，较早发力的企业和新业务率先享受到云原生先进理念和领先架构的红利。然而，传统行业和企业里的存量系统，依旧背负着沉重的技术债务和历史包袱，在技术革新与架构演进道路上举步维艰。
12 月 3-4 日北京 ArchSummit 架构师峰会上，我们就策划了一个专题，专门讲云原生技术应用经验，和遇到问题该如何解决的话题，这里面包括来自百度、作业帮、网易和字节跳动的实战经验。
那么，传统业务如何平滑跨入云原生架构呢？
互联网企业的做法一般是以“纵”“横”架构为核心设计导向。纵，即以关键技术为核心的纵向能力建设，增强技术能力深度；横，即以业务场景为核心的横向能力建设，再结合微服务、负载均衡、服务网格、容器等云原生技术。
在传统行业、企业存量系统里，其实运用以上互联网企业的方法，也可以帮助传统行业业务顺利进入云原生“航道”，高效获得云原生建设的价值回报。
但这里也存在一定的技术痛点，接下来从微服务架构选型、网关负载均衡、容器环境等角度阐述。
纵1——服务框架现状：传统服务框架的引入需要业务研发者有明显的感知，随着服务规模的扩大，需要服务框架引入更多治理功能，随之带来了更多需要业务研发者学习、理解、掌控、维护、升级更多服务治理相关框架的压力。
纵2——服务框架进化难点：服务框架进化的难点在于不是所有业务都可以轻易迁移到服务网格，需要在传统服务框架基础上，具备轻量级的技术方案，以无侵入业务（代码）的方式，快速增强现有业务使用的传统服务框架，具备限流、熔断、降级、认证鉴权、动态配置等全套服务治理能力，且具备模块化、热插拔、完整兼容性等能力，帮助业务快速实现服务治理的提升，并具备后续演进到服务网格的能力。
纵3——服务网格现状：最为流行的服务网格框架 Istio 有良好的背书（谷歌、IBM）和完整的体系能力，但依旧存在协议、注册中心、治理功能支持有限、传统环境支持弱等业务落地问题，性能、稳定性无法达到生产标准等大规模生产支撑问题。
纵4——服务网格建设难点：数据面、控制面等全方面实现协议的扩展、注册中心的纳管、治理功能的扩展，降低业务接入⻔槛；不侵入原生框架的主干代码完成扩展，方便后续沿着社区路线持续演进；延时、配置处理优化等服务网格典型痛点，需要结合组件优化、网络优化、协议栈优化等综合手段实现无限缩小带给业务性能的损耗。
横——实现平滑跨越的难点：服务框架和服务网格解决的问题虽然相近，但技术栈截然不同，且业务希望把使用服务框架阶段遗留的问题能使用服务网格统一解决，就导致在使用传统服务框架的业务，只能通过大量的业务代码改造，才能以新的方式接入服务网格，这在绝大多数企业存量业务都很难实现，给业务的架构和技术转型带了极大阻力。实现平滑跨越需要探寻使用两代技术栈（服务框架和服务网格）业务实现调用互通、互访、统一治理的技术方案，并且构建面向业务迁移、可管控、可观测的横向平台，最终保证业务迁移的平滑性和稳定性。
纵1——Java 异步化网关难点：Java 异步化网关受限于 JVM 性能瓶颈，流量代理能力上限明显。一方面为了应对大规模生产流量考验，需要完成对 Java 异步化性能的极致优化；另一方面需要构建完整的代理、治理、扩展、观测的 API 网关平台能力。
纵2——基于 Envoy 网关构建难点：原生 Envoy 是一个单纯的流量代理软件，构建完整的 API 网关需要围绕 Envoy 构建完整的控制能力、配置管理、插件机制、观测系统以及完善的管控平台。此外，基于 Envoy 实现 API 网关仅仅是一个起点，替代更多传统 L7 的流量代理或负载均衡器（如 Nginx、HAProxy、F5），以及云原生的 Ingress、Serverless 函数网关，需要围绕 Envoy 进行进一步的设计与扩展实现。
横——从多组件、多场景到技术栈、能力统一难点：传统技术和设计理念下，同样处理 L7 流量，不同场景使用了不用技术栈，如 API 网关有 Java 异步化的 Spring Cloud Gateway、Zuul，Nginx+OpenResty 的 Kong；负载均衡有 Nginx、HAProxy、F5；云原生的 Ingress、Serverless 函数网关，等等。基于 Envoy 除了能分别实现传统 L7 流量 代理组件的替代外，还能够构建统一的通用 L7 网关，实现多组件整合统一，以统一组件应对多场景需求。通用 L7 网关，整合覆盖原有多组件、多场景，是“横”的主要难点。
传统环境下云原生组件适应能力弱。以云原生服务网格 Istio 为例，在传统环境下仅提供了纳管虚机节点，且仅支持一台物理机 / 虚拟机部署一个服务 +Sidecar 代理，对不具备实际生产需求。想要实现业务从传统环境到容器环境的演进，需要打通服务网格在传统环境和容器环境的能力，包括支持一台物理机 / 虚拟机部署多个服务 +Sidecar 代理，支持传统环境的 Sidecar 代理生命周期管理，打通注册中心、配置中心等等。
从传统环境到容器环境迁移过程无保障。跨环境的迁移在存量业务系统是常态，迁移过程中流量不中断、业务无感知是主要难点。一方面需要服务框架 / 服务网格东⻄向代理具备区域优先、异常兜底能力，可以智能识别并把流量导向可用的环境和服务实例；另一 方面需要类似 L7 通用网关能力，解决跨环境、跨集群网络不通，注册中心不通的问题。
技术方案听起来都是完美的，但也存在很多实践痛点，例如急功近利，过于强调新技术；支撑业务场景的广度不足，⻓效性不足，架构和方案大多短视，短期造轮子等等。
所以，为了避免这些问题，建议学习业界已有的踩坑教训，少走重构之路。点击“阅读原文”查看会议官网日程，现在 9 折购票，有需求的可以直接联系票务经理：17310043226