【51CTO.com原创稿件】2020年，在诸多不确定因素的影响下，全球经济受到巨大打击。得益于数字化领先的企业，可以更加快速应对，从而减少损失。虽然受到了疫情的影响，但用友云服务业务却在今年也取得了大幅增长。根据用友的财报显示，今年前三季度，用友云服务业务（不含金融类云服务）同比增长76.4%。

在云服务业务高速增长的背后，离不开技术创新的支持。相信，在大多数人的眼里，用友是一家软件公司，主营业务更加集中在企业的业务应用层。其实不然。用友网络副总裁兼iuap云平台事业部总经理杨鹏在接受51CTO采访时表示，早在2006年，用友就开始在平台层布局建设，毕竟，承载着千万企业的业务应用架构，不是某个服务商的产品就可以直接满足的。于是，用友选择了自主打造高控制力的PaaS平台，基于云原生技术架构，满足企业业务快速交付、应用服务化、运维自动化等需求，实现业务快速创新，从而转型成为数智化企业。

演进：软件架构的变迁

过去，企业中的架构大都是单体架构，所有的计算资源、数据处理等全部集中在一个服务内进行，业务之间无需通信，所有业务之间的调用也都是在进程内完成。但是随着业务需求不断增加，单体架构也变得更加臃肿，并发能力和扩展能力都相对有限，单个服务若想快速迭代或者上线是无法满足的。

为了缓解单体架构的压力，分布式架构出现了。将大型、复杂的系统进行功能拆分解耦为多个业务模块，不同业务模块部署在不同设备，以此来缓解集中式架构的业务以及设备压力。然而系统间的交互需要使用远程通信，开发增大工作量。

后来有了SOA面向服务架构，也是分布式架构的一种落地方法，将应用的不同服务进行拆分，各个服务之间定义良好的接口和协议进行调用，而这就需要企业服务总线ESB。ESB将消息进行转化、解释以及路由等，让不同服务互联互通。虽然ESB可以解决公用逻辑的问题，但是ESB是中心化的，服务框架的扩展能力有限，服务调用方式也会带来业务的影响和扩展成本。

随着云计算的快速发展，底层资源也从原有的数据中心变成了公共服务，微服务架构随之诞生。微服务架构可以看做是SOA架构的演进，也是一种分布式架构。微服务架构采用轻量化的网络协议进行调用，打破了SOA架构下的服务总线的集中式限制。服务拆分后，每个服务高度自治，每个服务由独立的团队进行开发维护。微服务架构能够提升系统的稳定性和性能，服务间的松耦合以及独立团队的支撑，能够降低系统间的耦合度、加快局部业务的创新。但微服务架构下大量微服务的存在，对服务的配置管理、部署运维、服务监控等都带来了很大挑战，云原生很好的解决了以上这些问题。

云原生是一个技术开发管理方法的集合，发展至今一直在不断演进；它利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用；云原生以容器和Kubernetes为核心，解决了微服务应用的部署、运维、监控、应用迁移等问题。微服务与云原生相互促进、相辅相成。

盛行：云原生架构如此追捧

云原生的概念最早是Paul Fremantle在2010年的一篇博客提及，后来到了2013年 Matt Stine在推特上迅速推广云原生概念。2015年，由Linux基金会发起的云原生计算及基金会（The Cloud Native Computing Foundation，CNCF)）成立，标志着云原生正式进入高速发展轨道。如今，CNCF更新的云原生定义包括微服务、DevOps、持续交付和容器化四大部分。

如今，云原生架构普遍被企业所认可，众多企业也都开始加速云原生的落地实践。为何云原生如此受到欢迎呢？杨鹏认为，主要来自IT架构转型以及商业模式升级两方面的需要。

传统的IT架构已经无法满足目前企业快速变化和高性能、高并发的要求，企业技术架构在向互联网、微服务架构转型；此外，云原生能够很好地解决微服务架构带来的配置、部署、运维、服务管理和监控等方面的问题，降低研发部署复杂度。

随着IaaS、PaaS、SaaS的深入发展，基础计算资源、公共平台能力、软件服务能力的云化发展已经成为新的IT商业模式；而云原生是PaaS的核心构成、已经实现对SaaS的事实支撑标准。

云原生的出现，让业务开发不必过分关注非业务需求，如可靠性、可用性、弹性等，我们可以把那些非业务需求都下沉到云平台，让云平台提供基础设施的各种能力，最终达到解耦业务和非业务功能。当然，非业务需求都为业务提供服务的。

业界有种说法认为，云原生架构更加适合需要快速迭代，业务发展创新速度较快的应用。而杨鹏却认为，云原生架构适用于一切企业应用以及所有场景，只看企业是否愿意使用。“未来的企业IT架构都应该是云原生架构，只是时间问题；尤其是对系统的可靠性、可用性、弹性要求高的业务，更是需要优先进行云原生架构的升级。云原生架构从基础设施层面解决了服务的弹性扩缩，周边衍生的DevOps、微服务治理与监控等解决了大规模微服务应用的关键问题，是微服务架构的最佳搭档。”

支撑：商业创新平台的技术底座

早在2013年，用友就开始研究容器技术，并在2014年将容器作为平台能力对外输出，也就是当时的UAP平台的职责。杨鹏表示，当时用友的各云产品在进行互联网技术的换代，云原生架构下的容器技术可以解决互联网架构下的环境问题、高弹性问题和高可用问题，另外云原生架构下的微服务技术，可以解决服务治理和多微服务跨主机异构调用的问题，因此，用友也是很早就关注并研究容器技术以及微服务。

今年8月，用友发布YonBIP用友商业创新平台，也标志着用友云服务从产品服务模式升级到平台服务模式。技术平台作为YonBIP平台的底层技术支撑，基于云原生技术，集容器云、DevOps、服务治理、Hubble(链路追踪)、分布式事务一致性、测试与运维工具于一体。在继承原有的云服务基础上，深入践行DevOps理念，为技术人员提供资源管理、容器服务、持续集成、持续交付、镜像仓库、链路追踪、微服务治理、事务一致性等技术服务；同时通过应用监控、集群监控，容器监控，中间件监控等能力，全方位监控业务应用及其基础资源，并针对影响系统响应、稳定性的问题做深入分析，满足企业业务快速交付、系统稳定运行、运维自动化等需求，助力企业业务快速迭代试错，实现业务快速创新。

YonBIP用友商业创新平台的客户分为两类：云原生企业和云重生企业。对于云原生企业，YonBIP能够支撑应用的开发和管理，高并发、高可用、高弹性等特点可以满足企业快速发展、快速创新的业务需求；对于云重生企业，YonBIP有很多的集成和过渡迁移的工具；例如YonLinker是BIP的集成服务，帮助企业实现新旧系统、企业内外部业务的连接集成，实现新老业务的集成应用，支撑向新IT架构的转型；YonBuilder可以加速新业务开发创新的过程，缩短并行过渡期。因此，无论企业是采用云原生架构，还是混合模式架构，YonBIP都能很好地支持。此外，企业的云原生架构也可以采用其他云平台的技术，YonBIP也都可以进行集成连接，

特色：构建企业级云原生能力

对于云原生的支持，国内有很多IaaS服务商在大力支持，同时也有一些初创企业专注于云原生方面。升级到平台服务模式的用友，在云原生方面又有哪些特色呢？

杨鹏告诉51CTO，首先是企业级的特性，企业级云原生架构下，微服务的数量众多，服务之间的关系复杂，服务的权限控制难，而这些都会加大企业在云原生技术的使用门槛以及管理的复杂。用友的云原生充分吸收了B端企业领域用户的特点，结合技术普惠的理念，降低客户使用云原生技术的门槛，并且可以将DevOps中的CI、CD与容器、微服务全流程打通，更加简单便捷。

此外，用友开发了与YonBIP开发框架实现无缝整合的全链路追踪工具，有利于大规模微服务调用的问题排查，真正地适合企业级管理场景。例如采购场景，在员工提交采购单据点击保存时，则需要调用几个甚至十几个服务来进行校验。需要校验库存是否有货，当库存有货时，则需要校验预算是否充足，是否具有采购权限，检验完成后产生入库单，入库单合规后产生财务单据。而这一过程还会涉及到缓存、数据库、ElasticSearch等等，用友的技术平台则会记录下校验链路中的每一步，并存储在时序数据库中。如果检验失败，服务又要求事务性一致，则这些服务通过分布式事务框架进行回滚；如果校验成功，服务不要求强一致性，则由管理员查看失败位置并进行相应补偿，也可以设置为自动补偿。

杨鹏指出，企业级服务之间的逻辑关系很强，用友全链路追踪工具，可以详细记录调用微服务的每步操作，从而保障复杂的企业级流程的有效执行。将企业的数智化程度直接加速到一个高阶水平，有利于业务的展开。

未来：加大云原生探索及实践

云原生的概念一直在变化，也是在跟随技术的发展以及企业的应用而不断演进。杨鹏表示，我们坚信企业将会在云原生的技术红利中不断受益，用友也会持续加大在云原生方面的探索及实践力度。

首先，服务网格作为第二代微服务，将会成为用友构建云原生应用的重要一环，从云原生的基础设施层解决微服务治理的问题；其次，无服务架构也会基于函数业务的扩展能力，凌驾于微服务之上的更细粒度的扩展，也是下一步用友的发展方向；第三，Kubernetes已经成为云原生的基础设施，用友的产品也在此之上不断完善，构建更加弹性的计算能力，结合AIOps理念，让企业应用的构建和管理更加智能便捷。

【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】