译者 | 李艳林 (彦林)，Nacos 开放源码创办人，阿里云微服务工程项目发动机 MSE 创办人。
本栏参予过百度集团B2C销售业务微服务工程项目的升级换代和改建过程，并一直在全力支持历年来双 11 的大促活动，活耀在全力支持第一线，也参予了 Nacos 开放源码和街道社区产业发展，目前正在阿里云负责管理微服务工程项目的总体开放源码总体规划和微服务工程项目发动机 MSE 的研制管理。因此在微服务工程项目控制技术的应用领域、开放源码和商品化服务工程项目上，有著比较三维的体会和思索。微服务工程项目虽已可有可无，但其创造力之强远远超过许多人的想像。责任编辑将从微服务工程项目产业发展的金融行业态势和控制技术态势两方面进行阐释，热烈欢迎诸位参予文章，一起沟通交流。
控制技术态势大力推进金融行业革新，金融行业态势赋能控制技术价值，二者相辅相成，就可以继续保持控制技术的创造力。我们先来看一看这两年国内的一些重要该事件，这些该事件也不可否认阐明并加速着金融行业和控制技术态势：
4 月，Linux 新一代构架促进会下成立了微服务工程项目控制技术组 SIG（Special Interest Group），协力深入探讨微服务工程项目环境治理技术标准的软件系统
4 月，跨不同合作开发词汇和控制技术构架，微服务工程项目环境治理规范化 OpenSergo 开放源码
5 月，Envoy 街道社区面世 Envoy Gateway 产品，重新加入新一代交换机竞逐
6 月，百度正式宣布开放源码 Spring Cloud Tencent，打造出服务平台微服务工程项目软件系统
7 月，Ingress Nginx 工程项目中止转交新功能，将著眼于灵活性提高
8 月，CloudWeGo 正式宣布正式发布 Rust RPC 开源构架 Volo
8 月，三相信息技术正式发布服务工程项目分层工程项目（GA 版）
11 月，Apache Dubbo 第一个 Rust 词汇版正式宣布正式发布
11 月，百度开放源码新一代云原生植物交换机 Higress，如前所述 Envoy，全力支持 Nginx Ingress 零生产成本加速北迁
12 月，二进制颤动开放源码 kube-apiserver 高可用方案 KubeGateway
12 月，中国开放源码云联盟正式发布第二批开放源码成熟度评估结果，10 个工程项目中微服务工程项目领域的开放源码工程项目有 4 个
此外，百度云 & 华为云先后提供了面向 Nacos 的商业版
微服务工程项目产业发展的金融行业态势
微服务工程项目仍在持续高速增长，关注度从合作开发效率转向交付效率
开放源码工程项目 Star 在一定程度上反应了一个工程项目的热度和创造力，从 Star 的增长上看，目前主流微服务工程项目开放源码工程项目每年以平均 10% 以上的速度在增长，数字上呈现的是不仅是金融行业规模，也折射了每年新晋微服务工程项目合作开发者的水位。
Apache Dubbo：4.3w，YoY 12%
Istio: 3.3w, YoY 11%
Nacos：2.6w，YoY 23%
Spring Cloud Alibaba：2.5w，YoY 15%
Seata：2.4w，YoY 10%
Envoy: 2.2w, YoY 16%
SkyWalking：2.2w，YoY 14%
Sentinel：2.0w，YoY 13%
数据统计自 2022 年 12 月 25 日，计算主子仓库的累加数据。
微服务工程项目的持续高速产业发展，使得他已经和计算、存储、网络、数据库、安全一样成为云计算的基础设施。只不过在每个不同的产业发展阶段，微服务工程项目面临的挑战并不相同。云原生植物普及之前，微服务工程项目合作开发者著眼的是微服务工程项目的构架、迭代、交付和运维。随着云原生植物控制技术的成熟，微服务工程项目也在被云原生植物化，这时候，合作开发者和构架师更关心的是如何借助云的优势，简化微服务工程项目的运维问题，并更著眼在销售业务的交付效率上。
微服务工程项目价值愈加凸显，侧重点转向降本增效
若干年前，百度在做微服务工程项目转型的时候，看重的是微服务工程项目的可扩展性，因为要去加速应对庞大且日益增长的用户体量。但如今，随着人力生产成本的不断上升，以及云的算力生产成本的不断下降，微服务工程项目在帮助企业提高研制效率、落地敏捷合作开发的过程中，其发挥的降本增效价值已经越来越明显，这时候，微服务工程项目的价值侧重点是发生了变化的。过去的两年，我们看到大量的中小型企业开始采用微服务工程项目，加速上量、高效迭代，并将微服务工程项目应用领域建立在云上，加速迈入云原生植物时代。
此外，云拓宽了微服务工程项目的价值边界，其价值不仅体现在合作开发态的效率提高，也体现在了运维态上的价值。以 Nacos 为例，注册配置中心是一个旁路应用领域，但却承载着高频服务工程项目任务，一旦遇到可用性问题，会大面积影响线上销售业务，通过云厂商提供的 Nacos 商业版，可以极大的提高微服务工程项目在运维态上的价值，提高性能、提高可用性，阿里云的微服务工程项目发动机 MSE，以及百度云和华为云都提供了面向 Nacos/ZooKeeper/Eureka 的商品化服务工程项目。
从互联网走向各行各业，控制技术成熟度获得业内公认
这一态势并不是只在 2022 年才出现，提出中台概念的那时候，很多传统企业就已经通过微服务工程项目的拆分来构建中台架构了。近两年，随着各行各业数字化进程的加速，微服务工程项目不仅出现在直面线上用户的客户服务工程项目、市场营销等领域，也在帮助重构设计研制、生产制造、企业内销售财务协作、公司环境治理等领域，以便企业在市场竞争中保持先发优势。例如禾连健康帮助全国 2000 家医院构建在线体检服务工程项目，致景信息技术构建微服务工程项目体系打通全国纺织金融行业信息流、物流和资金流，实现数智化的综合平台，龙湖千丁借助微服务工程项目支撑全国 1000+ 的智慧停车销售业务，波司登全面推动各项销售业务容器化、微服务工程项目化，建立三维的在线销售体系，提高羽绒服销量。
不仅其他金融行业在加速落地微服务工程项目构架，对控制技术引入相当严苛的金融金融行业也正积极拥抱微服务工程项目。
随着金融信息技术的加速产业发展，市场对金融服务工程项目的需求日趋多样化和个性化，对场景金融服务工程项目创新、新销售业务需求敏态响应等提出诸多挑战，这些正不断加速金融企业的微服务工程项目构架转型。但是在传统金融领域，微服务工程项目构架的落地并没有像互联网企业那么迅速，这主要是金融金融行业对系统可用性和灵活性的要求非常高。
然而在过去的几年，随着微服务工程项目产品的成熟和控制技术的技术标准，这一现状得到了极大地改变，我们看到越来越多的金融企业使用微服务工程项目产品改建其核心系统。工商银行通过 Dubbo 将如前所述 JEE 的单体构架改建成微服务工程项目构架，中信、光大、广发银行如前所述 Seata 的分布式事务能力，来解决交易数据间要求极高的数据一致性难题，中原银行的微服务工程项目平台以开放源码工程项目 SkyWalking（APM 应用领域性能管理）为基础，建立了分布式链路追踪系统，为微服务工程项目提供分布式追踪、度量聚合和可视化等一体化软件系统。微服务工程项目在金融这类严苛的金融行业下的实践，也充分证明其控制技术的成熟度和技术标准。
微服务工程项目产业发展的控制技术态势
技术标准，呈现更多市场机遇
事实标准和金融行业标准并行产业发展，技术标准有利于降低控制技术的选型和使用门槛，也是控制技术成熟度的一种体现，微服务工程项目领域开放源码领域呈现出比较明显的头部效应，大部分合作开发者倾向选择主流方案，以下数据来自我们自行举办的合作开发者沙龙或线上直播的调研数据，仅供参考。
微服务工程项目或 RPC 构架：以 Spring 为主，Apache Dubbo 有 20%+ 的市场份额，在强调国产自主可控的金融行业，Dubbo 占比会更多些，grpc 以及一些多词汇的构架也一些忠实的拥趸。
注册和配置：Nacos 占比最高，Eureka/Consul/Apollo 各有一些市场份额，目前这个领域未看到有的开放源码工程项目。
限流降级：Sentinel 占比更高，虽然也有 Hystrix 等一些海外的开放源码软件系统，但由于本地化的文档和全力支持比较受限，合作开发者会更倾向于选择 Sentinel。
分布式事务：分布式事务主要应用领域于对数据一致性有较强需求的金融行业，且具有较高的控制技术门槛，开放源码选项并不多，目前是 Seata 更受合作开发者的热烈欢迎。
云原生植物交换机：主要分为 Nginx/Envoy 两大控制技术流派，APISIX 起步比较早，在国内的开放源码工作大力推进更快些，国外的开源工程项目有很多，例如 Kong/Emissary/Gloo 等，我们今年也开放源码了如前所述 Ingress 标准的云原生植物交换机 Higress。
微服务工程项目环境治理规范化和实现：相比以上的开放源码工程项目，这是一个相对较新的领域，开放源码选项主要是 OpenSergo 和 Polaris。
微服务工程项目开放源码领域的上下游关系
微服务工程项目开放源码虽然趋于技术标准，但从不绑定，各个开放源码工程项目之间都是解耦和开放的。这时候合作开发者选型会侧重在高可用上。例如开放源码工程项目本身是否经历过大量的生产实践，并且是自主可控，避免一些不可控的风险；二是开放源码方是否会提供一些云上的商业版。因为当云成为基础设施的时候，合作开发者会关注开放源码工程项目在云上的灵活性、性能、易用性，这些往往是开放源码版所不具备的。例如面对流量有损的情况，或是版正式发布时，没有做全链路灰度，一个线上故障引发全量销售业务受影响，没有控制爆炸半径，其实，这些场景都是可以通过商业版来避免的。越是主流的开放源码工程项目，越是有可能联合云厂商来提供公共云上的商业版。
因此，当微服务工程项目的各个领域的开放源码选型趋于技术标准，合作开发者们将不再过多纠结在选型上，而是在交付效率和灵活性上时，将给围绕微服务工程项目提供培训、产品服务工程项目的企业呈现出更多的市场机遇，这也会反哺整个金融行业的良性产业发展。
DevSecOps，入口安全关注度提高
在过去的两年里，RPC 和注册 & 配置中心帮助合作开发者解决研制效率和性能问题，领域趋于稳定；服务工程项目分层和服务工程项目环境治理通过流量控制提高高可用能力，领域加速演进；交换机帮助企业在数字化入口建立安全和高可用防线，领域处于兴起阶段，合作开发者关注各种方案的最佳实践和客户案例。
从这些微服务工程项目中间件的产业发展过程中我们发现，以围绕合作开发者为核心，提高微服务工程项目合作开发效率，保障生产运维高可用的 DevOps 实践越来越多，并且正在向 DevSecOps 加速演进。以云原生植物交换机为例，在流量转发等基础运维（Ops）能力之上，企业和合作开发者愈加重视作为微服务工程项目交换机的定制合作开发（Dev）能力，以及作为统一流量入口的安全（Sec）防线能力。
云原生植物交换机，玩家众多、活耀度高
云原生植物交换机领域，新晋的竞争者数量是去年同期的一倍，正在加速云原生植物交换机的技术标准。
控制技术态势离不开内外因的合力作用。微服务工程项目的控制技术态势之所以要单列一项云原生植物交换机，外因是 K8s 逐步成为云计算的新界面，而 Ingress 作为 K8s 的网络通信的标准规范化，定义了外部流量进入集群内部的规则描述。而内因则是交换机领域长期面临着入口网管零散、诉求各不相同的情况，例如 Nginx 发挥流量访问的交换机作用，微服务工程项目交换机发挥微服务工程项目体系下服务工程项目和服务工程项目之间网络访问的作用，API 交换机则实现了不同应用领域或系统之间的互访。当 Ingress 统一网络互访协议后，就催生了云原生植物交换机的出现。
从控制技术优劣势上看，传统交换机构架 API 定义不一致、多层交换机运维代价大、扩展性弱、规则变更连接抖动，越来越不能满足视频 /IOT/ 海外弱网的需求，不能适应云原生植物时代加速迭代、弹性带来的灵活性挑战。而云原生植物交换机将多层交换机进行统一构架和建设，不仅降低了交换机构架的复杂度，也提高了缩短了交换机的转发链路、提高交换机的性能。国内最早开放源码的 APISIX 已经服务工程项目了 1w+ star，并且被 vivo/ 雪球 / 众安保险 / 有赞云应用领域于生产销售业务。
我们今年也顺势将在集团已经服务工程项目生产销售业务两年之久的云原生植物交换机 Higress 对外进行开放源码，他具备技术标准、高集成、易扩展、热更新的优势，目的是加速云原生植物交换机在国内的落地。
数据面和控制面解耦，控制面重要性提高、但短期内较难技术标准
随着 xDS 协议成事实标准，数据面和控制面解耦，控制面作为数据面和环境治理平面的连接越来越重要。微服务工程项目生态可以有很多灵活集成模式，简单的场景注册 & 配置中心可以直接通过 xDS 协议将服务工程项目推到数据面，复杂的场景控制面可以聚合服务工程项目和规则推送到控制面，做更灵活、更复杂的环境治理能力扩展。
控制面的统一将带来诸多好处。
微服务工程项目已经从构架演进到环境治理，从解决如何用好微服务工程项目演进到如何管好微服务工程项目。管好微服务工程项目非常依赖微服务工程项目环境治理，而微服务工程项目环境治理是通过无损上线下、全链路灰度、流量防护等控制技术手段来减少、甚至避免正式发布和管理大规模应用领域过程中遇到的灵活性问题，但微服务工程项目环境治理在落地过程中会遇到各种难题。例如：
在企业内部，往往存在着不同词汇、不同通信协议的微服务工程项目，这会导致环境治理微服务工程项目的过程中，给销售业务合作开发者、构架师平添很多的认知负担，而这类异构会衍生出更多的痛点。
业内对服务工程项目环境治理的能力和边界没有明确的认识，每个企业所定义的服务工程项目环境治理概念不一致，造成很高的理解和沟通生产成本。
开放源码微服务工程项目构架众多，对于服务工程项目环境治理缺乏一些技术标准的约定。例如，Spring Cloud 中定义的微服务工程项目接口和 Dubbo 中定义的接口就没有办法互通，通过 Dubbo 和 Istio 管理的微服务工程项目也没有办法进行统一环境治理。
缺少真正面向销售业务、能够减轻认知负担的抽象和标准。合作开发者真正想要的可能是简单的、指定服务工程项目间的调用关系和配置规则。但现在对于销售业务合作开发者来说，不仅需要了解不同微服务工程项目构架的部署构架，也要了解不同服务工程项目环境治理方式的概念和能力区别，认知生产成本很大。
此时，控制面的统一能很好的解决以上困扰。因此我们今年和 bilibili、SphereEx、中国移动等企业，以及 Kratos、CloudWeGo、ShardingSphere、Nacos、Spring Cloud Alibaba、Dubbo 等街道社区联合发起并开放源码 OpenSergo 工程项目，目的就是构建一个和词汇无关、和控制技术形态无关，但贴近销售业务的统一服务工程项目环境治理规范化和实现。另外，Linux 新一代构架促进会也正在致力于服务工程项目环境治理标准的制定。但控制面的统一并非一朝一夕，需要参予方在实践中不断对标准进行磨合、逐步达成共识。
其他的一些控制技术态势
多词汇：Java 作为国内微服务工程项目合作开发最主流的词汇，正在加速云原生植物化演进，通过 Spring 6.0 / Spring Boot 3.0 / GraalVM 让 Java 能在容器和 Serverless 时代更轻量、更加速运行。随着传统客户数字化的升级换代，之前 C++/C/Python/PHP 研制正在加速向 Go / Rust 演进，目前 Go 微服务工程项目生态逐步完善，前端 Node.js 跨词汇调用后端服务工程项目场景也越来越多，Rust 微服务工程项目生态开始起步，Dubbo、CloudWeGo、Nacos 都在今年正式发布了 Rust 的版，相信后续会有更多开放源码工程项目跟进。
国产化：核心控制技术自主可控越加重要，整个软件金融行业都在加速国产化进程，微服务工程项目开放源码工程项目需要投入资源，全力支持 ARM/IPv6/Dragonwell/PolorDB/OceanBase 等国产化的上下游生态，就可以获得更多合作开发中的青睐。
Proxyless：xDS 协议成为事实标准，从 Lib 包依赖模式到 Sidecar 模式到 Proxyless 模式，Sidecar 模式无侵入带来一些运维复杂度，Lib 包模式有侵入但易运维、性能好，街道社区尝试 Node 级 Proxy 方式，介于二者之间，但目前处于前期状态；从当前的合作开发者体量看，Lib 包依赖是主流，Mesh 是补充。
总 结
技术标准、国产化、DevSecOps、云原生植物交换机、Proxyless、统一控制面和多词汇，给微服务工程项目带来的新的市场机遇。近一两年，国内出现了很多围绕这些领域的初创公司，也给很多成熟企业带来的新的商业方向，两股力量的相互交融延续着微服务工程项目的创造力。
如果你对责任编辑感兴趣，热烈欢迎在文末留言，或重新加入 InfoQ 写作平台话题讨论：https://xie.infoq.cn/
官网专题已正式发布于 InfoQ 官网，点击即可查看，登录 InfoQ 官网注册并将 InfoQ 添加进收藏夹，精彩不错过。
同时，InfoQ 年度展望直播周将于 2023 年 1 月 3 日首场开播，并持续输出精彩内容，关注 InfoQ 视频号，与金融行业控制技术大牛连麦~
