架构淘宝虚拟主机

白皮书TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud生于云长于云爆发于云企业数字化转型最短路径编写说明顾问组成员定义贡献者(征集活动优选)编写组成员(按目录排序)编写单位:阿里云计算有限公司阿里云基础软件事业部高级研究员蒋江伟(小邪)阿里云计算平台事业部高级研究员贾扬清(扬青)阿里云云原生应用平台研究员丁宇(叔同)蚂蚁金服研究员何征宇(梁纥)陈启涛、莫哈韦、郑富林、王炜、杨树宇、李皓伟阿里云云原生应用平台李小平阿里云云原生应用平台易立阿里云云原生应用平台司徒放阿里云云原生应用平台杨浩然阿里云云原生应用平台李响阿里云云原生应用平台罗毅阿里云云原生应用平台张磊阿里云云原生应用平台李艳林阿里云云原生应用平台张瓅玶阿里云云原生应用平台赵燕标阿里云云原生应用平台赵林阿里云云原生应用平台谢纯良特步全渠道IT总监王海能阿里云云原生应用平台邱戈川阿里云云原生应用平台员海滨阿里云云原生应用平台崔飞飞阿里云云原生应用平台张勇阿里云云原生应用平台付宇轩阿里云云原生应用平台许晓斌阿里云云原生应用平台雷卷31256734357913454546474748484950535557606367681518232731333840414142424344CONTENTTheCloud-nativeArchitectureWhitePaperbyAlibabaCloud云原生架构为什么需要云原生架构云原生架构的定义主要云原生技术阿里巴巴云原生架构设计阿里云云原生产品介绍云原生架构实践案例云原生架构未来发展趋势序云原生架构定义云原生架构原则主要架构模式典型的云原生架构反模式容器技术云原生微服务Serverless开放应用模型(OAM)ServiceMesh技术DevOps云原生中间件ACNA(AlibabaCloudNativeArchitecting)架构设计方法企业战略视角业务发展视角组织能力视角云原生技术架构视角架构持续演进闭环云原生架构成熟度模型云原生产品家族容器产品家族微服务产品家族Serverless产品家族ServiceMesh产品家族消息产品家族云原生数据库产品家族云原生数仓产品家族案例一:申通快递核心业务系统云原生化上云案例案例二:完美日记电商业务案例案例三:特步业务中台案例(零售、公共云)案例四:中国联通号卡业务云化案例(传统业务,专有云)案例五:TimingApp的Serverless实践案例容器技术发展趋势基于云原生的新一代应用编程界面Serverless发展趋势回顾过去十年,数字化转型将科技创新与商业元素不断融合、重构,重新定义了新业态下的增长极.
商业正在从大工业时代的固化范式进化成面向创新型商业组织与新商业物种的崭新模式.
随着数字化转型在中国各行业广泛深入,不管是行业巨头,还是中小微企业都不得不面对数字化变革带来的未知机遇与挑战.
数字化转型的十年,也是云计算高速发展的十年,这期间新技术不断演进、优秀开源项目大量涌现,云原生领域进入"火箭式"发展阶段.
通过树立技术标准与构建开发者生态,开源将云计算实施逐渐标准化,大幅降低了开发者对于云平台的学习成本与接入成本.
这都让开发者更加聚焦于业务本身并借助云原生技术与产品实现更多业务创新,有效提升企业增长效率,爆发出前所未有的生产力与创造力.
可以说,当云计算重构整个IT产业的同时,也赋予了企业崭新的增长机遇.
正如集装箱的出现加速了贸易全球化进程,以容器为代表的云原生技术作为云计算的服务新界面加速云计算普及的同时,也在推动着整个商业世界飞速演进.
上云成为企业持续发展的必然选择,全面使用开源技术、云服务构建软件服务的时代已经到来.
作为云时代释放技术红利的新方式,云原生技术在通过方法论、工具集和最佳实践重塑整个软件技术栈和生命周期,云原生架构序TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud对云计算服务方式与互联网架构进行整体性升级,深刻改变着整个商业世界的IT根基.
虽然云原生概念的产生由来已久,但对于云原生的定义、云原生架构的理解却众说纷纭.
到底什么是云原生容器就代表云原生吗云原生时代互联网分布式架构如何发展云原生与开源、云计算有什么关系开发者和企业为什么一定要选择云原生架构面对这些问题,每个人都有着不同回答.
鉴于此,阿里云结合自身云原生开源、云原生技术、云原生产品、云原生架构以及企业客户上云实践经验,给出了自己的答案,并通过这本白皮书与社会分享自己的思考与总结,旨在帮助越来越多的企业顺利找到数字化转型最短路径.
未来十年,云计算将无处不在,像水电煤一样成为数字经济时代的基础设施,云原生让云计算变得标准、开放、简单高效、触手可及.
如何更好地拥抱云计算、拥抱云原生架构、用技术加速创新,将成为企业数字化转型升级成功的关键.
云计算的下一站,就是云原生;IT架构的下一站,就是云原生架构;希望所有的开发者、架构师和技术决策者们,共同定义、共同迎接云原生时代.
5为什么需要云原生架构发展背景计算机软件技术架构进化有两大主要驱动因素,一个是底层硬件升级,另一个是顶层业务发展诉求.

正如伴随着x86硬件体系的成熟,很多应用不再使用昂贵、臃肿的大中型机,转而选择价格更为低廉的以x86为主的硬件体系,也由此诞生了包括CORBA、EJB、RPC在内的各类分布式架构;后由于互联网业务飞速发展,人们发现传统IOE架构已经不能满足海量业务规模的并发要求,于是又诞生了阿里巴巴Dubbo&RocketMQ、SpringCloud这样的互联网架构体系.
云计算从工业化应用到如今,已走过十五个年头,然而大量应用使用云的方式仍停滞在传统IDC时代:虚拟机代替了原来的物理机:使用文件保存应用数据,大量自带的三方技术组件,没有经过架构改造(如微服务改造)的应用上云,传统的应用打包与发布方式等等.
对于如何使用这些技术,没有绝对的对与错,只是在云的时代不能充分利用云的强大能力,不能从云技术中获得更高的可用性与可扩展能力,也不能利用云提升发布和运维的效率,是一件非常遗憾的事情.
回顾近年来商业世界的发展趋势,数字化转型的出现使得企业中越来越多的业务演变成数字化业务,数字化对于业务渠道、竞争格局、用户体验等诸多方面都带来更加严苛的要求,这就要求技术具备更快的迭代速度,业务推出速度从按周提升到按小时,每月上线业务量从"几十/月"提升到"几百/天".
大量数字化业务重构了企业的业务流水线,企业要求这些业务不能有不可接受的业务中断,否则会对客户体验以及营收可能造成巨大影响.
对于企业的CIO或者IT主管而言,原来企业内部IT建设以"烟筒"模式比较多,每个部门甚至每个应用都相对独立,如何管理与分配资源成了难题.
大家都基于最底层IDC设施独自向上构建,都需要单独分配硬件资源,这就造成资源被大量占用且难以被共享.
但是上云之后,由于云厂商提供了统一的IaaS能力和云服务,大幅提升了企业IaaS层的复用程度,CIO或者IT主管自然而然想到IaaS以上层的系统也需要被统一,使资源、产品可被不断复用,从而能够进一步降低企业运营成本.

所有这些问题都指向一个共同点,那就是云的时代需要新的技术架构,来帮助企业应用能够更好地利用云计算优势,充分释放云计算的技术红利,让业务更敏捷、成本更低的同时又可伸缩性更灵活,而这些正好就是云原生架构专注解决的技术点.
16今天云原生的定义有众多版本,云原生架构的理解也不尽相同,阿里将根据自身的云原生技术、产品和上云实践,给出自己的理解.
从技术的角度,云原生架构是基于云原生技术的一组架构原则和设计模式的集合,旨在将云应用中的非业务代码部分进行最大化的剥离,从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、可观测性、灰度等),使业务不再有非功能性业务中断困扰的同时,具备轻量、敏捷、高度自动化的特点.

上图展示了在代码中通常包括三部分:业务代码、三方软件、处理非功能特性的代码.
其中"业务代码"指实现业务逻辑的代码;"三方软件"是业务代码中依赖的所有三方库,包括业务库和基础库;"处理非功能性的代码"指实现高可用、安全、可观测性等非功能性能力的代码.

三部分中只有业务代码是核心,是对业务真正带来价值的,另外两个部分都只算附属物,但随着软件规模的增大、业务模块规模变大、部署环境增多、分布式复杂性增强,使得今天的软件构建变得越来越复杂,云原生架构的定义2云原生架构定义1开发人员运维人员代码传统架构云原生架构非功能性能力基础设施运维业务运维业务代码编写三方软件使用代码非功能性能力IaaS业务运维PaaS业务代码编写三方软件调用云原生架构与传统架构的对比7TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud对开发人员的技能要求也越来越高.
云原生架构相比较传统架构进了一大步,从业务代码中剥离了大量非功能性特性(不会是所有,比如易用性还不能剥离)到IaaS和PaaS中,从而减少业务代码开发人员的技术关注范围,通过云厂商的专业性提升应用的非功能性能力.
此外,具备云原生架构的应用可以最大程度利用云服务和提升软件交付能力,进一步加快软件开发:云原生架构产生的最大影响就是让开发人员的编程模型发生了巨大变化.
今天大部分的编程语言中,都有文件、网络、线程等元素,这些元素为充分利用单机资源带来好处的同时,也提升了分布式编程的复杂性;因此大量框架、产品涌现,来解决分布式环境中的网络调用问题、高可用问题、CPU争用问题、分布式存储问题……在云的环境中,比如"如何获取存储"变成了若干服务,包括对象存储服务、块存储服务和没有随机访问的文件存储服务.
云不仅改变了开发人员获得这些存储能力的界面,还在于云产品在这些OpenAPI或者开源SDK背后把分布式场景中的高可用挑战、自动扩缩容挑战、安全挑战、运维升级挑战等都处理了,应用的开发人员就不用在其代码中处理节点宕机前如何把本地保存的内容同步到远端的问题,也不用处理当业务峰值到来时如何对存储节点进行扩容的问题,而应用的运维人员不用在发现zeroday安全问题时紧急对三方存储软件进行升级……云把三方软硬件的能力升级成了服务,开发人员的开发复杂度和运维人员的运维工作量都得到极大降低.
显然,如果这样的云服务用得越多,那么开发和运维人员的负担就越少,企业在非核心业务实现上从必须的负担变成了可控支出.
在一些开发能力强的公司中,对这些三方软硬件能力的处理往往是交给应用框架(或者说公司内自己的中间件)来做的;在云的时代云厂商提供了更具SLA的服务,使得所有软件公司都可以由此获益.
这些使得业务代码的开发人员技能栈中,不再需要掌握文件及其分布式处理技术,不再需要掌握各种复杂的网络技术……简化让业务开发变得更敏捷、更快速!
任何应用都提供两类特性,功能性特性和非功能性特性.
功能性特性是真正为业务带来价值的代码,比如如何建立客户资料、如何处理订单、如何支付等等;即使是一些通用的业务功能特性,比如组织管理、业务字典管理、搜索等等也是紧贴业务需求的.
非功能性特性是没有给业务带来直接业务价值,但通常又是必不可少的特性,比如高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发布能力等等.
12代码结构发生巨大变化非功能性特性的大量委托8TheCloud-nativeArchitectureWhitePaper不能说云计算解决了所有非功能性问题,但确实大量非功能性特性,特别是分布式环境下复杂非功能性问题,被云产品处理掉了.
以大家最头疼的高可用为例,云产品在多个层面为应用提供了解决方案:虚机:当虚机检测到底层硬件异常时,自动帮助应用做热迁移,迁移后的应用不需重新启动而仍然具备对外服务的能力,应用对整个迁移过程都不会有任何感知;容器:有时应用所在的物理机是正常的,只是应用自身的问题(比如bug、资源耗尽等)而无法正常对外提供服务.
容器通过监控检查探测到进程状态异常,从而实施异常节点的下线、新节点上线和生产流量的切换等操作,整个过程自动完成而无需运维人员干预;云服务:如果应用把"有状态"部分都交给了云服务(如缓存、数据库、对象存储等),加上全局对象的持有小型化或具备从磁盘快速重建能力,由于云服务本身是具备极强的高可用能力,那么应用本身会变成更薄的"无状态"应用,因为高可用故障带来的业务中断会降至分钟级;如果应用是N-M的对等架构架构模式,那么结合LoadBalancer产品可获得几乎无损的高可用能力!
软件一旦开发完成,需要在公司内外部各类环境中部署和交付,以将软件价值交给最终客户.
软件交付的困难在于开发环境到生产环境的差异(公司环境到客户环境之间的差异)以及软件交付和运维人员的技能差异,填补这些差异的是一大堆安装手册、运维手册和培训文档.
容器以一种标准的方式对软件打包,容器及相关技术则帮助屏蔽不同环境之间的差异,进而基于容器做标准化的软件交付.

对自动化交付而言,还需要一种能够描述不同环境的工具,让软件能够"理解"目标环境、交付内容、配置清单并通过代码去识别目标环境的差异,根据交付内容以"面向终态"的方式完成软件的安装、配置、运行和变更.
基于云原生的自动化软件交付相比较当前的人工软件交付是一个巨大的进步.
以微服务为例,应用微服务化以后,往往被部署到成千上万个节点上,如果系统不具备高度的自动化能力,任何一次新业务的上线,都会带来极大的工作量挑战,严重时还会导致业务变更超过上线窗口而不可用.

云原生架构本身作为一种架构,也有若干架构原则作为应用架构的核心架构控制面,通过遵从这些架构原则可以让技术主管和架构师在做技术选择时不会出现大的偏差.
3高度自动化的软件交付云原生架构原则29TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud当代码规模超出小团队的合作范围时,就有必要进行服务化拆分了,包括拆分为微服务架构、小服务(MiniService)架构,通过服务化架构把不同生命周期的模块分离出来,分别进行业务迭代,避免迭代频繁模块被慢速模块拖慢,从而加快整体的进度和稳定性.
同时服务化架构以面向接口编程,服务内部的功能高度内聚,模块间通过公共功能模块的提取增加软件的复用程度.

分布式环境下的限流降级、熔断隔仓、灰度、反压、零信任安全等,本质上都是基于服务流量(而非网络流量)的控制策略,所以云原生架构强调使用服务化的目的还在于从架构层面抽象化业务模块之间的关系,标准化服务流量的传输,从而帮助业务模块进行基于服务流量的策略控制和治理,不管这些服务是基于什么语言开发的.
大部分系统部署上线需要根据业务量的估算,准备一定规模的机器,从提出采购申请,到供应商洽谈、机器部署上电、软件部署、性能压测,往往需要好几个月甚至一年的周期;而这期间如果业务发生变化了,重新调整也非常困难.
弹性则是指系统的部署规模可以随着业务量的变化自动伸缩,无须根据事先的容量规划准备固定的硬件和软件资源.
好的弹性能力不仅缩短了从采购到上线的时间,让企业不用操心额外软硬件资源的成本支出(闲置成本),降低了企业的IT成本,更关键的是当业务规模面临海量突发性扩张的时候,不再因为平时软硬件资源储备不足而"说不",保障了企业收益.

今天大部分企业的软件规模都在不断增长,原来单机可以对应用做完所有调试,但在分布式环境下需要对多个主机上的信息做关联,才可能回答清楚服务为什么宕机、哪些服务违反了其定义的SLO、目前的故障影响哪些用户、最近这次变更对哪些服务指标带来了影响等等,这些都要求系统具备更强的可观测能力.
可观测性与监控、业务探活、APM等系统提供的能力不同,前者是在云这样的分布式系统中,主动通过日志、链路跟踪和度量等手段,让一次APP点击背后的多次服务调用的耗时、返回值和参数都清晰可见,甚至可以下钻到每次三方软件调用、SQL请求、节点拓扑、网络响应等,这样的能力可以使运维、开发和业务人员实时掌握软件运行情况,并结合多个维度的数据指标,获得前所未有的关联分析能力,不断对业务健康度和用户体验进行数字化衡量和持续优化.
123服务化原则弹性原则可观测原则当业务上线后,最不能接受的就是业务不可用,让用户无法正常使用软件,影响体验和收入.
韧性代表了当软件所依赖的软硬件组件出现各种异常时,软件表现出来的抵御能力,这些异常通常包括硬件故障、4韧性原则10TheCloud-nativeArchitectureWhitePaper技术往往是把"双刃剑",容器、微服务、DevOps、大量第三方组件的使用,在降低分布式复杂性和提升迭代速度的同时,因为整体增大了软件技术栈的复杂度和组件规模,所以不可避免地带来了软件交付的复杂性,如果这里控制不当,应用就无法体会到云原生技术的优势.
通过IaC(InfrastructureasCode)、GitOps、OAM(OpenApplicationModel)、Kubernetesoperator和大量自动化交付工具在CI/CD流水线中的实践,一方面标准化企业内部的软件交付过程,另一方面在标准化的基础上进行自动化,通过配置数据自描述和面向终态的交付过程,让自动化工具理解交付目标和环境差异,实现整个软件交付和运维的自动化.
零信任安全针对传统边界安全架构思想进行了重新评估和审视,并对安全架构思路给出了新建议.
其核心思想是,默认情况下不应该信任网络内部和外部的任何人/设备/系统,需要基于认证和授权重构访问控制的信任基础,诸如IP地址、主机、地理位置、所处网络等均不能作为可信的凭证.
零信任对访问控制进行了范式上的颠覆,引导安全体系架构从"网络中心化"走向"身份中心化",其本质诉求是以身份为中心进行访问控制.
零信任第一个核心问题就是Identity,赋予不同的Entity不同的Identity,解决是谁在什么环境下访问某个具体的资源的问题.
在研发、测试和运维微服务场景下,Identity及其相关策略不仅是安全的基础,更是众多(资源,服务,环境)隔离机制的基础;在员工访问企业内部应用的场景下,Identity及其相关策略提供了灵活的机制来提供随时随地的接入服务.
今天技术和业务的演进速度非常快,很少有一开始就清晰定义了架构并在整个软件生命周期里面都适用,相反往往还需要对架构进行一定范围内的重构,因此云原生架构本身也应该和必须是一个具备持续演进能力的架构,而不是一个封闭式架构.
除了增量迭代、目标选取等因素外,还需要考虑组织(例如架构控制委员会)层面的架构治理和风险控制,特别是在业务高速迭代情况下的架构、业务、实现平衡67零信任原则架构持续演进原则硬件资源瓶颈(如CPU/网卡带宽耗尽)、业务流量超出软件设计能力、影响机房工作的故障和灾难、软件bug、黑客攻击等对业务不可用带来致命影响的因素.
韧性从多个维度诠释了软件持续提供业务服务的能力,核心目标是降低软件的MTBF(MeanTimeBetweenFailure,平均无故障时间).
从架构设计上,韧性包括服务异步化能力、重试/限流/降级/熔断/反压、主从模式、集群模式、AZ内的高可用、单元化、跨region容灾、异地多活容灾等.
5所有过程自动化原则11TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud服务化架构是云时代构建云原生应用的标准架构模式,要求以应用模块为颗粒度划分一个软件,以接口契约(例如IDL)定义彼此业务关系,以标准协议(HTTP、gRPC等)确保彼此的互联互通,结合DDD(领域模型驱动)、TDD(测试驱动开发)、容器化部署提升每个接口的代码质量和迭代速度.
服务化架构的典型模式是微服务和小服务(MiniService)模式,其中小服务可以看做是一组关系非常密切的服务的组合,这组服务会共享数据,小服务模式通常适用于非常大型的软件系统,避免接口的颗粒度太细而导致过多的调用损耗(特别是服务间调用和数据一致性处理)和治理复杂度.

通过服务化架构,把代码模块关系和部署关系进行分离,每个接口可以部署不同数量的实例,单独扩缩容,从而使得整体的部署更经济.
此外,由于在进程级实现了模块的分离,每个接口都可以单独升级,从而提升了整体的迭代效率.
但也需要注意,服务拆分导致要维护的模块数量增多,如果缺乏服务的自动化能力和治理能力,会让模块管理和组织技能不匹配,反而导致开发和运维效率的降低.

关系.
云原生架构对于新建应用而言的架构控制策略相对容易选择(通常是选择弹性、敏捷、成本的维度),但对于存量应用向云原生架构迁移,则需要从架构上考虑遗留应用的迁出成本/风险和到云上的迁入成本/风险,以及技术上通过微服务/应用网关、应用集成、适配器、服务网格、数据迁移、在线灰度等应用和流量进行细颗粒度控制.
Mesh化架构是把中间件框架(比如RPC、缓存、异步消息等)从业务进程中分离,让中间件SDK与业务代码进一步解耦,从而使得中间件升级对业务进程没有影响,甚至迁移到另外一个平台的中间件也对业务透明.
分离后在业务进程中只保留很"薄"的Client部分,Client通常很少变化,只负责与Mesh进程通讯,原来需要在SDK中处理的流量控制、安全等逻辑由Mesh进程完成.
整个架构如下图所示.
12服务化架构模式Mesh化架构模式云原生架构有非常多的架构模式,这里选取一些对应用收益更大的主要架构模式进行讨论.

主要架构模式312TheCloud-nativeArchitectureWhitePaper实施Mesh化架构后,大量分布式架构模式(熔断、限流、降级、重试、反压、隔仓……)都由Mesh进程完成,即使在业务代码的制品中并没有使用这些三方软件包;同时获得更好的安全性(比如零信任架构能力)、按流量进行动态环境隔离、基于流量做冒烟/回归测试等.
和大部分计算模式不同,Serverless将"部署"这个动作从运维中"收走",使开发者不用关心应用在哪里运行,更不用关心装什么OS、怎么配置网络、需要多少CPU……从架构抽象上看,当业务流量到来/业务事件发生时,云会启动或调度一个已启动的业务进程进行处理,处理完成后云自动会关闭/调度业务进程,等待下一次触发,也就是把应用的整个运行时都委托给云.

今天Serverless还没有达到任何类型的应用都适用的地步,因此架构决策者需要关心应用类型是否适合于Serverless运算.
如果应用是有状态的,云在进行调度时可能导致上下文丢失,毕竟Serverless的调度不会帮助应用做状态同步;如果应用是长时间后台运行的密集型计算任务,会得不到太多Serverless的优势;如果应用涉及到频繁的外部I/O(网络或者存储,以及服务间调用),也因为繁重的I/O负担、时延大而不适合.
Serverless非常适合于事件驱动的数据计算任务、计算时间短的请求/响应应用、没有复杂相互调用的长周期任务.
分布式环境中的CAP困难主要是针对有状态应用,因为无状态应用不存在C(一致性)这个维度,因此可以获得很好的A(可用性)和P(分区容错性),因而获得更好的弹性.
在云环境中,推荐把各34Serverless模式存储计算分离模式传统架构业务代码业务进程容器/主机SDK协议RPCSDKRedisSDKMQSDKDBSDK网络Mesh化架构业务代码Mesh进程(流量控制、安全策略、微隔离……)业务进程容器/主机新协议、加密、染色……SDK协议/标准协议RPCSDKRedisSDKMQSDKDBSDK网络13TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud可观测架构包括Logging、Tracing、Metrics三个方面,其中Logging提供多个级别(verbose/debug/warning/error/fatal)的详细信息跟踪,由应用开发者主动提供;Tracing提供一个请求从前端到后端的完整调用链路跟踪,对于分布式场景尤其有用;Metrics则提供对系统量化的多维度度量.
架构决策者需要选择合适的、支持可观测的开源框架(比如OpenTracing、OpenTelemetry),并规范上下文的可观测数据规范(例如方法名、用户信息、地理位置、请求参数等),规划这些可观测数据在哪些服务和技术组件中传播,利用日志和tracing信息中的spanid/traceid,确保进行分布式链路分析时有足够的信息进行快速关联分析.
由于建立可观测性的主要目标是对服务SLO(ServiceLevelObjective)进行度量,从而优化SLA,因此架构设计上需要为各个组件定义清晰的SLO,包括并发度、耗时、可用时长、容量等.
6可观测架构微服务模式提倡每个服务使用私有的数据源,而不是像单体这样共享数据源,但往往大颗粒度的业务需要访问多个微服务,必然带来分布式事务问题,否则数据就会出现不一致.
架构师需要根据不同的场景选择合适的分布式事务模式.
5分布式事务模式传统采用XA模式,虽然具备很强的一致性,但是性能差;基于消息的最终一致性(BASE)通常有很高的性能,但是通用性有限,且消息端只能成功而不能触发消息生产端的事务回滚;TCC模式完全由应用层来控制事务,事务隔离性可控,也可以做到比较高效;但是对业务的侵入性非常强,设计开发维护等成本很高;SAGA模式与TCC模式的优缺点类似但没有try这个阶段,而是每个正向事务都对应一个补偿事务,也是开发维护成本高;开源项目SEATA的AT模式非常高性能且无代码开发工作量,且可以自动执行回滚操作,同时也存在一些使用场景限制.
类暂态数据(如session)、结构化和非结构化持久数据都采用云服务来保存,从而实现存储计算分离.

但仍然有一些状态如果保存到远端缓存,会造成交易性能的明显下降,比如交易会话数据太大、需要不断根据上下文重新获取等,则可以考虑通过采用EventLog+快照(或CheckPoint)的方式,实现重启后快速增量恢复服务,减少不可用对业务的影响时长.
7事件驱动架构14TheCloud-nativeArchitectureWhitePaper增强服务韧性:由于服务间是异步集成的,也就是下游的任何处理失败甚至宕机都不会被上游感知,自然也就不会对上游带来影响;CQRS(CommandQueryResponsibilitySegregation):把对服务状态有影响的命令用事件来发起,而对服务状态没有影响的查询才使用同步调用的API接口;结合EDA中的EventSourcing可以用于维护数据变更的一致性,当需要重新构建服务状态时,把EDA中的事件重新"播放"一遍即可;数据变化通知:在服务架构下,往往一个服务中的数据发生变化,另外的服务会感兴趣,比如用户订单完成后,积分服务、信用服务等都需要得到事件通知并更新用户积分和信用等级;构建开放式接口:在EDA下,事件的提供者并不用关心有哪些订阅者,不像服务调用的场景——数据的产生者需要知道数据的消费者在哪里并调用它,因此保持了接口的开放性;事件流处理:应用于大量事件流(而非离散事件)的数据分析场景,典型应用是基于Kafka的日志处理;基于事件触发的响应:在IoT时代大量传感器产生的数据,不会像人机交互一样需要等待处理结果的返回,天然适合用EDA来构建数据处理应用.
典型的云原生架构反模式4技术往往像一把双刃剑,阿里在自己和帮助客户做云原生架构演进的时候,会充分考虑根据不同的场景选择不同的技术,下面是我们总结的一些典型云原生架构反模式.
庞大单体应用的最大问题在于缺乏依赖隔离,包括代码耦合带来的责任不清、模块间接口缺乏治理而带来变更影响扩散、不同模块间的开发进度和发布时间要求难以协调、一个子模块不稳定导致整个应用都变慢、扩容时只能整体扩容而不能对达到瓶颈的模块单独扩容……因此当业务模块可能存在多人开发1庞大的单体应用事件和传统的消息不同,事件具有schema,所以可以校验event的有效性,同时EDA具备QoS保障机制,也能够对事件处理失败进行响应.
事件驱动架构不仅用于(微)服务解耦,还可应用于下面的场景中:EEEEEEEventProducerTopicEventConsumerSubscribe事件驱动架构(EDA,EventDrivenArchitecture)本质上是一种应用/组件间的集成架构模式,典型的事件驱动架构如下图:15TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud服务的拆分需要适度,过分服务化拆分反而会导致新架构与组织能力的不匹配,让架构升级得不到技术红利,典型的例子包括:软件架构中非常重要的一个维度就是处理软件复杂度问题,一旦问题规模提升了很多,那就必须重新考虑与之适应的新方案.
在很多软件组织中,开发、测试和运维的工作单位都是以进程为单位,比如把整个用户管理作为一个单独的模块进行打包、发布和运行;而进行了微服务拆分后,这个用户管理模块可能被分为用户信息管理、基本信息管理、积分管理、订单管理等多个模块,由于仍然是每个模块分别打包、发布和运行,开发、测试和运维人员的人均负责模块数就直线上升,造成了人均工作量增大,也就增加了软件的开发成本.
实际上,当软件规模进一步变大后,自动化能力的缺失还会带来更大的危害.
由于接口增多会带来测试用例的增加,更多的软件模块排队等待测试和发布,如果缺乏自动化会造成软件发布时间变长,在多环境发布或异地发布时更是需要专家来处理环境差异带来的影响.
同时更多的进程运行于一个环境中,缺乏自动化的人工运维容易给环境带来不可重现的影响,而一旦发生人为运维错误又不容易"快速止血",造成了故障处理时间变长,以及使得日常运维操作都需要专家才能完成.
所有这些问题导致软件交付时间变长、风险提升以及运维成本的增加.
23单体应用"硬拆"为微服务缺乏自动化能力的微服务小规模软件的服务拆分:软件规模不大,团队人数也少,但是为了微服务而微服务,强行把耦合度高、代码量少的模块进行服务化拆分,一次性的发布需要拆分为多个模块分开发布和维护;数据依赖:服务虽然拆分为多个,但是这些服务的数据是紧密耦合的,于是让这些服务共享数据库,导致数据的变化往往被扇出到多个服务中,造成服务间数据依赖;性能降低:当耦合性很强的模块被拆分为多个微服务后,原来的本地调用变成了分布式调用,从而让响应时间变大了上千倍,导致整个服务链路性能急剧下降.
的时候,就需要考虑通过服务化进行一定的拆分,梳理聚合根,通过业务关系确定主要的服务模块以及这些模块的边界、清晰定义模块之间的接口,并让组织关系和架构关系匹配.

阿里巴巴在淘宝业务快速发展阶段,就遇到过上百人维护一个核心单体应用,造成了源码冲突、多团队间协同代价高的严重问题.
为了支撑不断增长的流量,该应用需要不断增加机器,很快后端数据库连接很快就到达了上限.
在还没有"微服务"概念的2008年,阿里巴巴决定进行服务化架构拆分,当时思路就是微服务架构,第一个服务从用户中心开始建设,后续交易、类目、店铺、商品、评价中心等服务陆续从单体中独立出来,服务之间通过远程调用通信,每个中心由独立团队专门维护,从而解决了研发协同问题,以及按规模持续水平扩展的问题.
16容器作为标准化软件单元,它将应用及其所有依赖项打包,使应用不再受环境限制,在不同计算环境间快速、可靠地运行.
虽然2008年Linux就提供了Cgroups资源管理机制、LinuxNamespace视图隔离方案,让应用得以运行在独立沙箱环境中,避免相互间冲突与影响;但直到Docker容器引擎的开源,才很大程度上降低了容器技术的使用复杂性,加速了容器技术普及.
Docker容器基于操作系统虚拟化技术,共享操作系统内核、轻量、没有资源损耗、秒级启动,极大提升了系统的应用部署密度和弹性.
更重要的是,Docker提出了创新的应用打包规范——Docker镜像,解耦了应用与运行环境,使应用可以在不同计算环境间一致、可靠地运行.
借助容器技术呈现了一个优雅的抽象场景:让开发所需要的灵活性、开放性和运维所关注的标准化、自动化达成相对平衡.
容器镜像迅速成为了应用分发的工业标准.

传统、虚拟化及容器部署模式比较容器技术1APPBin/LibraryOperatingSystemHypervisorOperatingSystemHardwareAPPAPPAPPOperatingSystemHardwareVirtualMachineVirtualMachineOperatingSystemBin/LibraryAPPAPPAPPAPPAPPAPPBin/LibraryBin/LibraryBin/LibraryContainerRuntimeOperatingSystemHardwareContainerContainerContainer1容器技术背景与价值TraditionalDeploymentVirtualizedDeploymentContainerDeployment主要云原生技术317随后开源的Kubernetes,凭借优秀的开放性、可扩展性以及活跃开发者社区,在容器编排之战中脱颖而出,成为分布式资源调度和自动化运维的事实标准.
Kubernetes屏蔽了IaaS层基础架构的差异并凭借优良的可移植性,帮助应用一致地运行在包括数据中心、云、边缘计算在内的不同环境.
企业可以通过Kubernetes,结合自身业务特征来设计自身云架构,从而更好支持多云/混合云,免去被厂商锁定的顾虑.
伴随着容器技术逐步标准化,进一步促进了容器生态的分工和协同.
基于Kubernetes,生态社区开始构建上层的业务抽象,比如服务网格Istio、机器学习平台Kubeflow、无服务器应用框架Knative等.
在过去几年,容器技术获得了越发广泛的应用的同时,三个核心价值最受用户关注:敏捷弹性可移植性容器技术提升企业IT架构敏捷性的同时,让业务迭代更加迅捷,为创新探索提供了坚实的技术保障.
比如疫情期间,教育、视频、公共健康等行业的在线化需求突现爆发性高速增长,很多企业通过容器技术适时把握了突如其来的业务快速增长机遇.
据统计,使用容器技术可以获得3~10倍交付效率提升,这意味着企业可以更快速的迭代产品,更低成本进行业务试错.
在互联网时代,企业IT系统经常需要面对促销活动、突发事件等各种预期内外的爆发性流量增长.
通过容器技术,企业可以充分发挥云计算弹性优势,降低运维成本.
一般而言,借助容器技术,企业可以通过部署密度提升和弹性降低50%的计算成本.
以在线教育行业为例,面对疫情之下指数级增长的流量,教育信息化应用工具提供商希沃Seewo利用阿里云容器服务ACK和弹性容器实例ECI大大满足了快速扩容的迫切需求,为数十万名老师提供了良好的在线授课环境,帮助百万学生进行在线学习.
容器已经成为应用分发和交付的标准技术,将应用与底层运行环境进行解耦;Kubernetes成为资源调度和编排的标准,屏蔽了底层架构差异性,帮助应用平滑运行在不同基础设施上.
CNCF云原生计算基金会推出了Kubernetes一致性认证,进一步保障了不同K8s实现的兼容性,这也让企业愿意采用容器技术来构建云时代应用基础设施.
Kubernetes已经成为容器编排的事实标准,被广泛用于自动部署,扩展和管理容器化应用.
Kubernetes提供了分布式应用管理的核心能力:2容器编排资源调度:根据应用请求的资源量CPU、Memory,或者GPU等设备资源,在集群中选择合适的节点来运行应用;应用部署与管理:支持应用的自动发布与应用的回滚,以及与应用相关的配置的管理;也可以自动化存储卷的编排,让存储卷与容器应用的生命周期相关联;TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud18Kubernetes的控制平面包含四个主要的组件:APIServer、Controller、Scheduler以及etcd.
如下图所示:ContainerRuntimeCloudProviderNetwordEdgeEndUsersPodsSystemServicesNode1CtrlPlane-1,2.
.
.
nkubeletetcdcontrollermanagerkubeAPIserverschedulerContainerRuntimePodsSystemServicesNode2kubeletLoadBalancerkubectl自动修复:Kubernetes可以会监测这个集群中所有的宿主机,当宿主机或者OS出现故障,节点健康检查会自动进行应用迁移;K8s也支持应用的自愈,极大简化了运维管理的复杂性;服务发现与负载均衡:通过Service资源出现各种应用服务,结合DNS和多种负载均衡机制,支持容器化应用之间的相互通信;弹性伸缩:K8s可以监测业务上所承担的负载,如果这个业务本身的CPU利用率过高,或者响应时间过长,它可以对这个业务进行自动扩容.
声明式API:开发者可以关注于应用自身,而非系统执行细节.
比如Deployment(无状态应用)、StatefulSet(有状态应用)、Job(任务类应用)等不同资源类型,提供了对不同类型工作负载的抽象;对Kubernetes实现而言,基于声明式API的"level-triggered"实现比"edge-triggered"方式可以提供更加健壮的分布式系统实现.
可扩展性架构:所有K8s组件都是基于一致的、开放的API实现和交互;三方开发者也可通过CRD(CustomResourceDefinition)/Operator等方法提供领域相关的扩展实现,极大提升了K8s的能力.
Kubernetes在容器编排中有几个关键设计理念:TheCloud-nativeArchitectureWhitePaper19可移植性:K8s通过一系列抽象如LoadbalanceService(负载均衡服务)、CNI(容器网络接口)、CSI(容器存储接口),帮助业务应用可以屏蔽底层基础设施的实现差异,实现容器灵活迁移的设计目标.

云原生微服务212微服务发展背景微服务设计约束过去开发一个后端应用最为直接的方式就是通过单一后端应用提供并集成所有的服务,即单体模式.
随着业务发展与需求不断增加,单体应用功能愈发复杂,参与开发的工程师规模可能由最初几个人发展到十几人,应用迭代效率由于集中式研发、测试、发布、沟通模式而显著下滑.
为了解决由单体应用模型衍生的过度集中式项目迭代流程,微服务模式应运而生.
微服务模式将后端单体应用拆分为松耦合的多个子应用,每个子应用负责一组子功能.
这些子应用称为"微服务",多个"微服务"共同形成了一个物理独立但逻辑完整的分布式微服务体系.
这些微服务相对独立,通过解耦研发、测试与部署流程,提高整体迭代效率.
此外,微服务模式通过分布式架构将应用水平扩展和冗余部署,从根本上解决了单体应用在拓展性和稳定性上存在的先天架构缺陷.
但也要注意到微服务模型也面临着分布式系统的典型挑战:如何高效调用远程方法、如何实现可靠的系统容量预估、如何建立负载均衡体系、如何面向松耦合系统进行集成测试、如何面向大规模复杂关联应用的部署与运维……在云原生时代,云原生微服务体系将充分利用云资源的高可用和安全体系,让应用获得更有保障的弹性、可用性与安全性.
应用构建在云所提供的基础设施与基础服务之上,充分利用云服务所带来的便捷性、稳定性,降低应用架构的复杂度.
云原生的微服务体系也将帮助应用架构全面升级,让应用天然具有更好的可观测性、可控制性、可容错性等特性.
相较于单体应用,微服务架构的架构转变,在提升开发、部署等环节灵活性的同时,也提升了在运维、监控环节的复杂性.
在结合实践总结后,我们认为设计一个优秀的微服务系统应遵循以下设计约束:TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud微服务个体约束一个设计良好的微服务应用,所完成的功能在业务域划分上应是相互独立的.
与单体应用强行绑定语言和技术栈相比,这样做的好处是不同业务域有不同的技术选择权,比如推荐系统采用Python实现效率可能比Java要高效得多.
从组织上来说,微服务对应的团队更小,开发效率也更高.
"一个微服务团队一顿能吃掉两张披萨饼"、"一个微服务应用应当能至少两周完成一次迭代",都是对如何正确划分微服务在业务域边界的隐喻和标准.
总结来说,微服务的"微"并不是为了微而微,而是按照问题域对单体应用做合理拆分.

20微服务与微服务之间的横向关系微服务与数据层之间的纵向约束进一步,微服务也应具备正交分解特性,在职责划分上专注于特定业务并将之做好,即SOLID原则中单一职责原则(SRP,SingleResponsibilityPrinciple).
如果当一个微服务修改或者发布时,不应该影响到同一系统里另一个微服务的业务交互.
在合理划分好微服务间的边界后,主要从微服务的可发现性和可交互性处理服务间的横向关系.

微服务的可发现性是指当服务A发布和扩缩容的时候,依赖服务A的服务B如何在不重新发布的前提下,如何能够自动感知到服务A的变化这里需要引入第三方服务注册中心来满足服务的可发现性;特别是对于大规模微服务集群,服务注册中心的推送和扩展能力尤为关键.
微服务的可交互性是指服务A采用什么样的方式可以调用服务B.
由于服务自治的约束,服务之间的调用需要采用与语言无关的远程调用协议,比如REST协议很好的满足了"与语言无关"和"标准化"两个重要因素,但在高性能场景下,基于IDL的二进制协议可能是更好的选择.
另外,目前业界大部分微服务实践往往没有达到HATEOAS启发式的REST调用,服务与服务之间需要通过事先约定接口来完成调用.
为了进一步实现服务与服务之间的解耦,微服务体系中需要有一个独立的元数据中心来存储服务的元数据信息,服务通过查询该中心来理解发起调用的细节.
伴随着服务链路的不断变长,整个微服务系统也就变得越来越脆弱,因此面向失败设计的原则在微服务体系中就显得尤为重要.
对于微服务应用个体,限流、熔断、隔仓、负载均衡等增强服务韧性的机制成为了标配.
为进一步提升系统吞吐能力、充分利用好机器资源,可以通协程、Rx模型、异步调用、反压等手段来实现.
在微服务领域,提倡数据存储隔离(DSS,DataStorageSegregation)原则,即数据是微服务的私有资产,对于该数据的访问都必须通过当前微服务提供的API来访问.
如若不然,则造成数据层产生耦合,违背了高内聚低耦合的原则.
同时,出于性能考虑,通常采取读写分离(CQRS)手段.
同样的,由于容器调度对底层设施稳定性的不可预知影响,微服务的设计应当尽量遵循无状态设计原则,这意味着上层应用与底层基础设施的解耦,微服务可以自由在不同容器间被调度.
对于有数据存取(即有状态)的微服务而言,通常使用计算与存储分离方式,将数据下沉到分布式存储,通过这个方式做到一定程度的无状态化.

TheCloud-nativeArchitectureWhitePaper全局视角下的微服务分布式约束从微服务系统设计一开始,就需要考虑以下因素:高效运维整个系统,从技术上要准备全自动化的CI/CD流水线满足对开发效率的诉求,并在这个基础上支持蓝绿、金丝雀等不同发布策略,以满足对业务发布稳定性的诉求.
面对复杂系统,全链路、实时和多维度的可观测能力成为标配.
为了及时、有效地防范各类运维风险,需要从微服务体系多种事件源汇聚并分析相关数据,然后在中心化的监控系统中进行多维度展现.
伴随着微服务拆分的持续,故障发现时效性和根因精确性始终是开发运维人员的核心诉求.

21自从微服务架构理念在2011年提出以来,典型的架构模式按出现的先后顺序大致分为四代.
第一代微服务架构中,应用除了需要实现业务逻辑之外,还需要自行解决上下游寻址、通讯,以及容错等问题.

随着微服务规模扩大,服务寻址逻辑的处理变得越来越复杂,哪怕是同一编程语言的另一个应用,上述微服务的基础能力都需要重新实现一遍.
3云原生微服务典型架构ServiceABusinesslogicContainerAContainerBServiceBBusinesslogicServiceADiscoveryserviceDiscoveryandfaulttoleranceBusinesslogicContainerAContainerBServiceBBusinesslogicDiscoveryandfaulttoleranceTheCloud-nativeArchitectureWhitePaperbyAlibabaCloud22在第二代微服务架构中,引入了旁路服务注册中心作为协调者来完成服务的自动注册和发现.
服务之间的通讯以及容错机制开始模块化,形成独立服务框架.
但是随着服务框架内功能日益增多,用不同语言的基础功能复用显得十分困难,这也就意味着微服务的开发者被迫被绑定在某种特定语言上,从而违背了微服务的敏捷迭代原则.

2016年出现了第三代微服务架构-服务网格,原来被模块化到服务框架里的微服务基础能力,被进一步的从一个SDK演进成为一个独立进程-Sidecar.
这个变化使得第二代架构中多语言支持问题得以彻底解决,微服务基础能力演进和业务逻辑迭代彻底解耦.
这个架构就是在云原生时代的微服务架构-CloudNativeMicroservices,边车(Sidecar)进程开始接管微服务应用之间的流量,承载第二代中服务框架的功能,包括服务发现、调用容错,到丰富的服务治理功能,例如:权重路由、灰度路由、流量重放、服务伪装等.

近两年开始,随着AWSLambda的出现,部分应用开始尝试利用Serverless来架构微服务,这种方式被称之为第四代微服务架构.
在这个架构中,微服务进一步由一个应用简化为微逻辑(Micrologic),从而对边车模式提出了更高诉求,更多可复用的分布式能力从应用中剥离,被下沉到边车中,例如:状态管理、资源绑定、链路追踪、事务管理、安全等等.
同时,在开发侧开始提倡面向localhost编程的理念,提供标准API屏蔽掉底层资源、服务、基础设施的差异,进一步降低微服务开发难度.
这个也就是目前业界提出的多运行时微服务架构(Muti-RuntimeMicroservices).
SidecarDiscoveryserviceTrafficmanagementDiscoveryandfaulttoleranceServiceABusinesslogicContainerAContainerBSidecarDiscoveryandfaulttoleranceTrafficmanagementServiceBBusinesslogicSidecarDiscoveryserviceTrafficmanagementDiscoveryandfaulttoleranceServiceABusinesslogicFunctionasaserviceSidecarDiscoveryandfaulttoleranceTrafficmanagementServiceBBusinesslogicTheCloud-nativeArchitectureWhitePaper23ApacheDubbo作为源自阿里巴巴的一款开源高性能RPC框架,特性包括基于透明接口的RPC、智能负载均衡、自动服务注册和发现、可扩展性高、运行时流量路由与可视化的服务治理.
经过数年发展已是国内使用最广泛的微服务框架并构建了强大的生态体系.
为了巩固Dubbo生态的整体竞争力,2018年阿里巴巴陆续开源了Spring-CloudAlibaba(分布式应用框架)、Nacos(注册中心&配置中心)、Sentinel(流控防护)、Seata(分布式事务)、Chaosblade(故障注入),以便让用户享受阿里巴巴十年沉淀的微服务体系,获得简单易用、高性能、高可用等核心能力.
Dubbo在v3中发展ServiceMesh,目前Dubbo协议已经被Envoy支持,数据层选址、负载均衡和服务治理方面的工作还在继续,控制层目前在继续丰富Istio/Pilot-discovery中.
SpringCloud作为开发者的主要微服务选择之一,为开发者提供了分布式系统需要的配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性Token、全局锁、决策竞选、分布式会话与集群状态管理等能力和开发工具.
EclipseMicroProfile作为Java微服务开发的基础编程模型,它致力于定义企业Java微服务规范,MicroProfile提供指标、API文档、运行状况检查、容错与分布式跟踪等能力,使用它创建的云原生微服务可以自由地部署在任何地方,包括ServiceMesh架构.
Tars是腾讯将其内部使用的微服务框架TAF(TotalApplicationFramework)多年的实践成果总结而成的开源项目,在腾讯内部有上百个产品使用,服务内部数千名C++、Java、Golang、Node.
Js与PHP开发者.
Tars包含一整套开发框架与管理平台,兼顾多语言、易用性、高性能与服务治理,理念是让开发更聚焦业务逻辑,让运维更高效.
SOFAStack(ScalableOpenFinancialArchitectureStack)是由蚂蚁金服开源的一套用于快速构建金融级分布式架构的中间件,也是在金融场景里锤炼出来的最佳实践.
MOSN是SOFAStack的组件,它一款采用Go语言开发的ServiceMesh数据平面代理,功能和定位类似Envoy,旨在提供分布式、模块化、可观测、智能化的代理能力.
MOSN支持Envoy和Istio的API,可以和Istio集成.
Dapr(DistributedApplicationRuntime,分布式应用运行时)是微软新推出的,一种可移植的、Serverless的、事件驱动的运行时,它使开发人员可以轻松构建弹性,无状态和有状态微服务,这些服务运行在云和边缘上,并包含多种语言和开发框架.
4主要微服务技术TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud24Serverless31技术特点随着以Kubernetes为代表的云原生技术成为云计算的容器界面,Kubernetes成为云计算的新一代操作系统.
面向特定领域的后端云服务(BaaS)则是这个操作系统上的服务API,存储、数据库、中间件、大数据、AI等领域的大量产品与技术都开始提供全托管的云形态服务,如今越来越多用户已习惯使用云服务,而不是自己搭建存储系统、部署数据库软件.
当这些BaaS云服务日趋完善时,Serverless因为屏蔽了服务器的各种运维复杂度,让开发人员可以将更多精力用于业务逻辑设计与实现,而逐渐成为云原生主流技术之一.
Serverless计算包含以下特征:函数计算(FunctionasaService)是Serverless中最具代表性的产品形态.
通过把应用逻辑拆分多个函数,每个函数都通过事件驱动的方式触发执行,例如当对象存储(OSS)中产生的上传/删除对象等事件,能够自动、可靠地触发FaaS函数处理且每个环节都是弹性和高可用的,客户能够快速实现大规模数据的实时并行处理.
同样的,通过消息中间件和函数计算的集成,客户可以快速实现大规模消息的实时处理.

目前函数计算这种Serverless形态在普及方面仍存在一定困难,例如:针对这些情况,在Serverless计算中又诞生出更多其他形式的服务形态,典型的就是和容器技术进行融合创新,通过良好的可移植性,容器化的应用能够无差别地运行在开发机、自建机房以及公有云环境中;基于容器工具链能够加快解决Serverless的交付.
云厂商如阿里云提供了弹性容器实例(ECI)以及更上层的Serverless应用引擎(SAE),Google提供了CloudRun服务,这都帮助用户专注于容器化应用构建,而无需关心基础设施的管理成本.
此外Google也开源了基于Kubernetes的Serverless应用框架Knative.
相对函数计算的编程模式,这类Serverless应用服务支持容器镜像作为载体,无需修改即可部署在Serverless环境中,可以享受到Serverless带来的全托管免运维、自动弹性伸缩、按量计费等优势.
下面是传统的弹性计算服务、基于容器的Serverless应用服务和函数计算的对比:全托管的计算服务,客户只需要编写代码构建应用,无需关注同质化的、负担繁重的基于服务器等基础设施的开发、运维、安全、高可用等工作;通用性,结合云BaaSAPI的能力,能够支撑云上所有重要类型的应用;自动的弹性伸缩,让用户无需为资源使用提前进行容量规划;按量计费,让企业使用成本得有效降低,无需为闲置资源付费.
函数编程以事件驱动方式执行,这在应用架构、开发习惯方面,以及研发交付流程上都会有比较大的改变;函数编程的生态仍不够成熟,应用开发者和企业内部的研发流程需要重新适配;细颗粒度的函数运行也引发了新技术挑战,比如冷启动会导致应用响应延迟,按需建立数据库连接成本高等.

TheCloud-nativeArchitectureWhitePaper25服务分类弹性计算硬件虚拟化虚拟机镜像高虚拟机分钟级实例运行时长弹性计算ECSServerless应用安全容器容器镜像中容器实例秒级实例运行时长或请求处理时长阿里云SAEGoogleKnativeFaaS安全容器或应用运行时函数低函数实例毫秒级请求处理时长函数计算代表产品虚拟化交付模式应用兼容性扩容单位弹性效率计费模式2常见场景近两年来Serverless近年来呈加速发展趋势,用户使用Serverless架构在可靠性、成本和研发运维效率等方面获得显著收益.
小程序/Web/Mobile/API后端服务在小程序、Web/Moible应用、API服务等场景中,业务逻辑复杂多变,迭代上线速度要求高,而且这类在线应用,资源利用率通常小于30%,尤其是小程序等长尾应用,资源利用率更是低于10%.
Serverless免运维,按需付费的特点非常适合构建小程序/Web/Mobile/API后端系统,通过预留计算资源+实时自动伸缩,开发者能够快速构建延时稳定、能承载高频访问的在线应用.
在阿里内部,使用Serverless构建后端服务是落地最多的场景,包括前端全栈领域的ServerlessForFrontends,机器学习算法服务,小程序平台实现等等.
客户端CDN对象存储函数计算Serverless应用引擎云数据库NoSQL存储静态内容HTML/CSS/JS动态内容TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud26大规模批处理任务基于事件驱动架构的在线应用和离线数据处理在构建典型任务批处理系统时,例如大规模音视频文件转码服务,需要包含计算资源管理、任务优先级调度、任务编排、任务可靠执行、任务数据可视化等一系列功能.
如果从机器或者容器层开始构建,用户通常使用消息队列进行任务信息的持久化和计算资源分配,使用Kubernetes等容器编排系统实现资源的伸缩和容错,自行搭建或集成监控报警系统.
而通过Serverless计算平台,用户只需要专注于任务处理逻辑的处理,而且Serverless计算的极致弹性可以很好地满足突发任务下对算力的需求.
通过将对象存储和Serverless计算平台集成的方式,能实时响应对象创建、删除等操作,实现以对象存储为中心的大规模数据处理.
用户既可以通过增量处理对象存储上的新增数据,也可以创建大量函数实例来并行处理存量数据.
典型Serverless计算服务通过事件驱动的方式,可以广泛地与云端各种类型服务集成,用户无需管理服务器等基础设施和编写集成多个服务的"胶水"代码,就能够轻松构建松耦合、基于分布式事件驱动架构的应用.

通过和事件总线的集成,无论是一方BaaS云服务,还是三方的SaaS服务,或者是用户自建的系统,所有事件都可以快速便捷地被函数计算处理.
例如通过和API网关集成,外部请求可以转化为事件,从而触发后端函数处理.
通过和消息中间件的事件集成,用户能快速实现对海量消息的处理.

客户端CDN显示上传图片转换、水印、人脸识别函数计算音视频转码、截帧元数据提取、索引文件压缩、解压、校验、分析对象存储显示客户端函数计算Serverless工作流预留库存API网关退款通知发货释放预留支付TheCloud-nativeArchitectureWhitePaper27开发运维自动化计算资源弹性调度负载均衡和流控安全性通过定时触发器,用户用函数的方式就能够快速实现定时任务,而无须管理执行任务的底层服务器.
通过将定时触发器和监控系统的时间触发器集成,用户可以及时接收机器重启、宕机、扩容等IaaS层服务的运维事件,并自动触发函数执行处理.
为了实现精准、实时的实例伸缩和放置,必须把应用负载的特征作为资源调度依据,使用"白盒"调度策略,由Serverless平台负责管理应用所需的计算资源.
平台要能够识别应用特征,在负载快速上升时,及时扩容计算资源,保证应用性能稳定;在负载下降时,及时回收计算资源,加快资源在不同租户函数间的流转,提高数据中心利用率.

因此更实时、更主动、更智能的弹性伸缩能力是函数计算服务获得良好用户体验的关键.
通过计算资源的弹性调度,帮助用户完成指标收集、在线决策、离线分析、决策优化的闭环.
在创建新实例时,系统需要判断如何将应用实例放置在下层计算节点上.
放置算法应当满足多方面的目标:资源调度服务是Serverless系统的关键链路.
为了支撑每秒近百万次的资源调度请求,系统需要对资源调度服务的负载进行分片,横向扩展到多台机器上,避免单点瓶颈.
分片管理器通过监控整个集群的分片和服务器负载情况,执行分片的迁移、分裂、合并操作,从而实现集群处理能力的横向扩展和负载均衡.

在多租户环境下,流量隔离控制是保证服务质量的关键.
由于用户是按实际使用的资源付费,因此计算资源要通过被不同用户的不同应用共享来降低系统成本.
这就需要系统具备出色的隔离能力,避免应用相互干扰.

Serverless计算平台的定位是通用计算服务,要能执行任意用户代码,因此安全是不可逾越的底线.
系统应从权限管理、网络安全、数据安全、运行时安全等各个维度全面保障应用的安全性.
轻量安全容器等新的虚拟化技术实现了更小的资源隔离粒度、更快的启动速度、更小的系统开销,使数据中心的资源使用变得更加细粒度和动态化,从而更充分地利用碎片化资源.
3技术关注点容错:当有多个实例时,将其分布在不同的计算节点和可用区上,提高应用的可用性.

资源利用率:在不损失性能的前提下,将计算密集型、I/O密集型等应用调度到相同计算节点上,尽可能充分利用节点的计算、存储和网络资源.
动态迁移不同节点上的碎片化实例,进行"碎片整理",提高资源利用率.

性能:例如复用启动过相同应用实例或函数的节点、利用缓存数据加速应用的启动时间.

数据驱动:除了在线调度,系统还将天、周或者更大时间范围的数据用于离线分析.
离线分析的目的是利用全量数据验证在线调度算法的效果,为参数调优提供依据,通过数据驱动的方式加快资源流转速度,提高集群整体资源利用率.
TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud28开放应用模型(OAM)412开放应用模型的背景开放应用模型的定义随着Kubernetes技术体系逐渐成熟,整个云原生生态正在积极思考与探索如何达成云原生技术理念---"以应用为中心"的终极愿景.
2019年末,阿里云联合微软共同发布了OpenApplicationModel(OAM)开源项目,其主要目标是解决从Kubernetes项目到"以应用为中心"的平台之间最关键环节——标准化应用定义.
容器技术以"彻底改变了软件打包与分发方式"迅速得到大量企业的广泛使用.
不过软件打包与分发方式的革新,并没有能够让软件本身的定义与描述发生本质变化;基于Kubernetes的应用管理体验,还没有让业务研发与运维的工作变得足够简单.
最典型的例子,Kubernetes至今都没有"应用"这个概念,它提供的是更细粒度的"工作负载"原语,比如Deployment或者DaemonSet.
在实际环境中,一个应用往往由一系列独立组件组成,比如一个"PHP应用容器"和一个"数据库实例"组成电商网站;一个"参数服务节点"和一个"工作节点"组成机器学习训练任务;一个由"Deployment+StatefulSet+HPA+Service+Ingress"组成微服务应用.
OAM的第一个设计目标就是补充"应用"这一概念,建立对应用和它所需的运维能力定义与描述的标准规范.
换而言之,OAM既是标准"应用定义"同时也是帮助封装、组织和管理Kubernetes中各种"运维能力".
在具体设计上,OAM的描述模型是基于KubernetesAPI的资源模型(KubernetesResourceModel)来构建的,它强调一个现代应用是多个资源的集合,而非一个简单工作负载.
例如在PHP电商网站的OAM语境中,一个PHP容器和它所依赖的数据库以及它所需要使用的各种云服务,都是一个"电商网站"应用的组成部分.
同时,OAM把这个应用所需的"运维策略"也认为是应用的一部分,比如这个PHP容器所需的HPA(水平自动扩展策略):ApplicationComponent1scalingauto/indexpublicroutesecuritygroupComponent2scalingauto/indexpublicroutesecuritygroupRedisTheCloud-nativeArchitectureWhitePaper29OAM项目的第二个设计目标就是提供更高层级的应用层抽象和以应关注点分离的定义模型.
Kubernetes作为一个面向基础设施工程师的系统级项目,主要负责提供松耦合的基础设施语义,这就使得用户编写KubernetesYAML文件时,往往会感觉这些文件里的关注点非常底层.
实际上,对于业务研发人员和运维人员而言,他们并不想配置这些如此底层的资源信息,而希望有更高维度的抽象.
这就要求一个真正面向最终用户侧的应用定义,一个能够为业务研发和应用运维人员提供各自所需的应用定义原语.
而在上述模块化的应用定义基础上,OAM模型还强调整个模型的关注点分离特性.
即业务研发人员负责定义与维护组件(Component)来描述服务单元,而运维人员定义运维特征(Trait)并将其附加到组件上,构成OAM可交付物–ApplicationConfiguration.
这种设计使OAM在能够无限接入Kubernetes各种能力同时,为业务研发与运维人员提供最佳使用体验和最低心智负担.
开放应用模型的核心概念OAM主要定义了三个具体的概念和对应的标准,它们包括应用组件依赖、应用运维特征和应用配置:例如,一个由PHP容器和Redis实例组成的应用,在OAM的框架和规范下,就可以用如下的示意图来表达出来:组件依赖:OAM定义和规范了组成应用的组件(Component).
例如,一个前端WebServer容器、数据库服务、后端服务容器等;应用运维特征:OAM定义和规范了应用所需的运维特征(Trait)的集合.
例如,弹性伸缩和Ingress等运维能力;应用配置:OAM定义和规范了应用实例化所需的配置机制,从而能够将上述这些描述转化为具体应用实例.

具体来说,运维人员可以定义和使用应用配置(ApplicationConfiguration)来组合上述的组件和相应的特征,以构建可部署的应用交付实例.
ApplicationComponentComponentApplicationConfigurationscaling:autoroute:/indexsecuritygroup:publictraitscopescaling:manualrolloutstrategy:canarysecuritygroup:privateRedisWhattorunHowtooperateTheCloud-nativeArchitectureWhitePaperbyAlibabaCloud30在Kubernetes上使用开放应用模型在上述应用定义模型规范基础上,OAM提供了标准的OAMKubernetes插件(即:OAMKubernetes核心依赖库项目),从而能够"一键式"的为任何Kubernetes集群加上基于OAM模型的应用定义与应用管理能力.
具体来说,这个插件的功能包括:OAMKubernetes核心依赖库支持将任何现有CRD被声明为Workload或者Trait,而无需做任何改动.
这也意味着任何Kubernetes原生API资源也可以被声明为Workload或者Trait.
通过这种设计,现有Kubernetes集群里所有能力进行OAM化变得非常容易.
OAMKubernetes插件保证了OAM可以模块式接入、部署和管理任何Kubernetes工作负载和运维能力.
而这些工作负载和运维能力之间的交互需要标准化、统一化,Workload与Trait标准化交互机制应运而生.
比如Deployment和HPA(自动水平扩展控制器)的协作关系中,Deployment在OAM模型中就属于Workload,而HPA则属于Trait.
在OAM当中,ApplicationConfiguration里引用的Workload和Trait也必须通过协作方式来操作具体Kubernetes资源.
在OAMKubernetes核心依赖库中,过DuckTyping(鸭子类型)机制,在Trait对象上自动记录与之绑定的Workload关系,从而实现了工作负载(Workload)和运维能力(Trait)之间的双向记录关系:功能一:无缝对接现有K8sAPI资源功能二:Workload与Trait标准化交互机制Component组件:完全从研发视角定义的应用模块工作负载:应用模块的具体描述举例:通过OAM定义和部署OpenFaaSFunctionComponentAapiVersion:core.
oam.
dev/vlalpha2kind:Componentmetadata:name:web-functionannotations:description:OpenFaaSworkloadspec:workload:apiVersion:openfaas.
com/v1kind:Functionspec:name:nodeinfohandler:nodemain.
jsimage:function/nodeinfoenvironment:http_proxy:http://proxy1.
corp.
com:3128no_proxy:http://gateway/工作负载给定任何一工作负载(Workload),系统可以直接获取到同它绑定的所有运维能力(Trait);TheCloud-nativeArchitectureWhitePaper31给定任何一个运维能力(Trait),系统可以直接获取到它所要作用于的所有工作负载(Workload).
这种双向记录关系对于在一个大规模的生产环境中保证运维能力的可管理性、可发现性和应用稳定性是至关重要的.
Component版本管理:对于任何一次Component变更,OAM平台都将记录下来其变更历史,从而允许运维通过Trait来进行回滚、蓝绿发布等运维操作.
Component间依赖关系与参数传递:该功能将解决部署亟需的组件间依赖问题,包括Component之间的依赖和传输传递,以及Trait与Component之间的依赖和参数传递.
Component运维策略:该功能将允许研发在Component中声明对运维能力的诉求,指导运维人员或者系统给这个Component绑定和配置合理的运维能力.
除此之外,OAMKubernetes插件还提供几个非常重要的基础功能,包括:开放应用模型的未来相比于传统PaaS封闭、不能同"以Operator为基础的云原生生态"衔接的现状,基于OAM和Kubernetes构建的现代云原生应用管理平台的本质是一个"以应用为中心"的Kubernetes,保证应用平台能够无缝接入整个云原生生态.
同时,OAM进一步屏蔽掉容器基础设施的复杂性和差异性,为平台使用者带来低心智负担的、标准化的、一致化的应用管理与交付体验,让一个应用描述可以完全不加修改的在云、边、端等任何环境下直接交付运行起来.
此外,OAM还定义了一组核心工作负载/运维特征/应用范畴,作为应用程序交付平台的基石.
当模块化的Workload和Trait越来越多,就会形成组件市场.
而OAM就像是这个组件市场的管理者,通过处理组件之间的关系,把许多组件集成为一个产品交付给用户.
OAM加持下的Kubernetes应用拼图,可以像乐高积木一样灵活组装底层能力、运维特征以及开发组件.
一个基于OAM构建的Kubernetes应用管理平台CannaryBlue-GreenA/BtestingTraits/ScopeTrafficManagementScalingFunctionComponentsDevApplicationConfigurationKubernetes(+OAM核心依赖库)KubernetesPluginsContainerCloudResourcesUI/DashboardTraitsSystem+RegistryOpsTheCloud-nativeArchitectureWhitePaperbyAlibabaCloud32OAM社区还同混合云管理项目Crossplane建立了深度合作,从而保证符合OAM规范的待运行程序、运维能力和它所依赖的云服务,可以组成一个整体,在混合云环境中无缝漂移.
这种无关平台的应用定义范式,使得应用研发人员只需通过OAM规范来描述应用程序,应用程序就可以在任何Kubernetes群集或者Serverless应用平台甚至边缘环境上运行而无需对应用描述做任何修改.
OAM社区与整个云原生生态一起,正在将标准应用定义和标准化的云服务管理能力统一起来,使"云端应用交付"的故事真正成为现实.

ServiceMesh技术51技术特点ServiceMesh是分布式应用在微服务软件架构之上发展起来的新技术,旨在将那些微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施,实现应用与平台基础设施的解耦.
这个解耦意味着开发者无需关注微服务相关治理问题而聚焦于业务逻辑本身,提升应用开发效率并加速业务探索和创新.
换句话说,因为大量非功能性从业务进程剥离到另外进程中,ServiceMesh以无侵入的方式实现了应用轻量化,下图展示了ServiceMesh的典型架构:在这张架构图中,ServiceA调用ServiceB的所有请求,都被其下的Proxy(在Envoy中是Sidecar)截获,代理ServiceA完成到ServiceB的服务发现、熔断、限流等策略,而这些策略的总控是在ControlPlane上配置.
IstioMeshDataplaneControlplaneIngresstrafficEgresstrafficMeshtrafficDiscoveryConfigurationCertificatesPilotCitadelGalleyistiodProxyProxyServiceAServiceBIstioArchitectureTheCloud-nativeArchitectureWhitePaper33从架构上,Istio可以运行在虚拟机或容器中,Istio的主要组件包括Pilot(服务发现、流量管理)、Mixer(访问控制、可观测性)、Citadel(终端用户认证、流量加密);整个服务网格关注连接和流量控制、可观测性、安全和可运维性.

虽然相比较没有服务网格的场景多了4个IPC通讯的成本,但整体调用的延迟随着软硬件能力的提升而并不会带来显著的影响,特别是对于百毫秒级别的业务调用而言可以控制在2%以内.
从另一方面,服务化的应用并没有做任何改造,就获得了强大的流量控制能力、服务治理能力、可观测能力、4个9以上高可用、容灾和安全等能力,加上业务的横向扩展能力,整体收益仍然是远大于额外IPC通讯支出.
服务网格的技术发展上数据平面与控制平面间的协议标准化是必然趋势.
大体上,ServiceMesh的技术发展围绕着"事实标准"去展开——共建各云厂商共同采纳的开源软件.
从接口规范的角度:Istio采纳了Envoy所实现的xDS协议,将该协议当作是数据平面和控制平面间的标准协议;Microsoft提出了ServiceMeshInterface(SMI),致力于让数据平面和控制平面的标准化做更高层次的抽象,以期为Istio、Linkerd等ServiceMesh解决方案在服务观测、流量控制等方面实现最大程度的开源能力复用.
UDPA(UniversalDataPlaneAPI)是基于xDS协议而发展起来,以便根据不同云厂商的特定需求便捷地进行扩展并由xDS去承载.
此外数据平面插件的扩展性和安全性也得到了社区的广泛重视.
从数据平面角度,Envoy得到了包括Google、IBM、Cisco、Microsoft、阿里云等大厂的参与共建以及主流云厂商的采纳而成为了事实标准.
在Envoy的软件设计为插件机制提供了良好扩展性的基础之上,目前正在探索将Wasm技术运用于对各种插件进行隔离,避免因为某一插件的软件缺陷而导致整个数据平面不可用.
Wasm技术的优势除了提供沙箱功能外,还能很好地支持多语言,最大程度地让掌握不同编程语言的开发者可以使用自己所熟悉的技能去扩展Envoy的能力.
在安全方面,ServiceMesh和零信任架构天然有很好的结合,包括PODIdentity、基于mTLS的链路层加密、在RPC上实施RBAC的ACL、基于Identity的微隔离环境(动态选取一组节点组成安全域).
23行业应用情况主要技术根据Gartner研究报告,Istio有望成为ServiceMesh的事实标准,而ServiceMesh本身也将成为容器服务技术的标配技术组件.
即便如此,ServiceMesh目前在市场仍处于早期采用(Earlyadoption)阶段.
除Istio以外,Google与AWS分别推出了各自的云服务TrafficDirector、AppMesh.
这两个ServiceMesh产品与Istio虽有所不同,但与Istio同样地采纳了Envoy作为数据平面.
此外,阿里云、腾讯云、华为云也都推出了ServiceMesh产品,同样采用Envoy技术作为数据面并在此基础上提供了应用发布、流量管控、APM等能力.
2017年发起的服务网格Istio开源项目,清晰定义了数据平面(由开源软件Envoy承载)和管理平面(Istio自身的核心能力).
Istio为微服务架构提供了流量管理机制,同时亦为其它增值功能(包括安全性、监控、路由、连接管理与策略等)创造了基础.
Istio利用久经考验的LyftEnvoy代理进行构建,可在无需对应用程序代码作出任何TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud34发动的前提下实现可视性与控制能力.
2019年Istio所发布的1.
12版已达到小规模集群上线生产环境水平,但其性能仍受业界诟病.
开源社区正试图通过架构层面演进改善这一问题.
由于Istio是建构于Kubernetes技术之上,所以它天然地可运行于提供Kubernetes容器服务的云厂商环境中,同时Istio成为了大部分云厂商默认使用的服务网格方案.
除了Istio外,也有Linkerd、Consul这样相对小众的ServiceMesh解决方案.
Linkerd在数据平面采用了Rust编程语言实现了linkerd-proxy,控制平面与Istio一样采用Go语言编写.
最新的性能测试数据显示,Linkerd在时延、资源消耗方面比Istio更具优势.
Consul在控制面上直接使用ConsulServer,在数据面上可以选择性地使用Envoy.
与Istio不同的是,Linkerd和Consul在功能上不如Istio完整.
Conduit作为Kubernetes的超轻量级ServiceMesh,其目标是成为最快、最轻、最简单且最安全的ServiceMesh.
它使用Rust构建了快速、安全的数据平面,用Go开发了简单强大的控制平面,总体设计围绕着性能、安全性和可用性进行.
它能透明地管理服务之间的通信,提供可测性、可靠性、安全性和弹性的支持.
虽然与Linkerd相仿,数据平面是在应用代码之外运行的轻量级代理,控制平面是一个高可用的控制器,然而与Linkerd不同的是,Conduit的设计更加倾向于Kubernetes中的低资源部署.
DevOps612概述DevOps原则DevOps就是为了提高软件研发效率,快速应对变化,持续交付价值的的一系列理念和实践,其基本思想就是持续部署(CD),让软件的构建、测试、发布能够更加快捷可靠,以尽量缩短系统变更从提交到最后安全部署到生产系统的时间.
要实现持续部署(CD),就必须对业务进行端到端分析,把所有相关部门的操作统一考虑进行优化,利用所可用的技术和方法,用一种理念来整合资源.
DevOps理念从提出到现在,已经深刻影响了软件开发过程.
DevOps提倡打破开发、测试和运维之间的壁垒,利用技术手段实现各个软件开发环节的自动化甚至智能化,被证实对提高软件生产质量、安全,缩短软件发布周期等都有非常明显的促进作用,也推动了IT技术的发展.
要实施DevOps,需要遵循一些基本原则,这些原则被简写为CAMS,是如下四个英文单词的缩写:文化(Culture)自动化(Automation)度量(Measurement)共享(Sharing)TheCloud-nativeArchitectureWhitePaper35下面我们分别来谈一谈这几个方面.
文化自动化度量共享谈到DevOps,一般大家关注的都是技术和工具,但实际上要解决的核心问题是和业务、和人相关的问题.
提高效率,加强协作,就需要不同的团队之间更好的沟通.
如果每个人能够更好的相互理解对方的目标和关切的对象,那么协作的质量就可以明显的提高.
DevOps实施中面对的首要矛盾在于不同团队的关注点完全不一样.
运维人员希望系统运行可靠,所以系统稳定性和安全性是第一位.
而开发人员则想着如何尽快让新功能上线,实现创新和突破,为客户提供更大价值.
不同的业务视角,必然导致误会和摩擦,导致双方都觉得对方在阻挠自己完成工作.
要实施DevOps,就首先要让开发和运维人员认识到他们的目标是一致的,只是工作岗位不同,需要共担责任.
这就是DevOps需要首先在文化层面解决的问题.
只有解决了认知问题,才能打破不同团队之间的鸿沟,实现流程自动化,把大家的工作融合成一体.

DevOps的持续集成的目标就是小步快跑,快速迭代,频繁发布.
小系统跑起来很容易,但一个大型系统往往牵涉几十人到几百人的合作,要让这个协作过程流畅运行不是一件容易的事情.
要把这个理念落实,就需要规范化和流程化,让可以自动化的环节实现自动化.
实施DevOps,首先就要分析已有的软件开发流程,尽量利用各种工具和平台,实现开发和发布过程的自动化.

经过多年发展,业界已经有一套比较成熟的工具链可以参考和使用,不过具体落地还需因地制宜.

在自动化过程中,需要各种技术改造才能达到预期效果.
例如如果容器镜像是为特定环境构建的,那么就无法实现镜像的复用,不同环境的部署需要重新构建,浪费时间.
这时就需要把环境特定的配置从镜像中剥离出来,用一个配置管理系统来管理配置.
通过数据可以对每个活动和流程进行度量和分析,找到工作中存在的瓶颈和漏洞以及对于危急情况的及时报警等.
通过分析,可以对团队工作和系统进行调整,让效率改进形成闭环.
度量首先要解决数据准确性、完整性和及时性问题,其次要建立正确的分析指标.
DevOps过程考核的标准应该鼓励团队更加注重工具的建设,自动化的加速和各个环节优化,这样才能最大可能发挥度量的作用.

要实现真正的协作,还需要团队在知识层面达成一致.
通过共享知识,让团队共同进步:可见度visibility:让每个人可以了解团队其它人的工作.
这样可以知道是否某一项工作会影响另一部分.

通过相互反馈,让问题尽早暴露.
TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud36透明性transparency:让每个人都明白工作的共同目标,知道为什么要干什么.
缺乏透明性就会导致工作安排失调.
知识的传递transferofknowledge:知识的传递是为了解决两个问题,一个是为了避免某个人成为单点,从而导致一个人的休假或离职,就导致工作不能完成.
另一个是提高团队的集体能力,团队的集体能力要高于个人的能力.
要实现知识共享有很多方法.
在敏捷开发中,通过日站会来共享进度.
在开发中,通过代码、文档和注释来共享知识.
ChatOps则是让在一个群里的人都看到正在进行的操作和操作的结果.
其它的所有会议、讨论和非正式的交流等当然也是为了知识共享.
从广意上讲,团队协作就是知识不断积累和分享的过程.
落实DevOps要努力建设一个良好的文化氛围并通过工具支持让所有的共享更加方便高效.
文化、自动化、度量和共享四个方面相辅相成,独立而又相互联系,所以要落实DevOps时,要统一考虑.
通过CAMS也认识到,CI/CD仅仅是实现DevOps中很小的一部分.
DevOps不仅仅是一组工具,更重要是代表了一种文化,一种心智.
3理性的期待对于DevOps要有合乎理性的期待.
DevOps提供了一套工具,工具能够起多大的作用,其最重要的影响有两个,一是使用工具的人,另外就是对于需要解决的问题本身复杂性的掌握.
虽然DevOps已经被广泛接受和认可,但其在实际应用中的成熟度还待进一步提高.
在一份关于DevOps的调查报告中,把DevOps进化分为三个级别,80%被调查团队处于中等评级,而处于高级阶段和低级阶段的都在10%左右.
报告分析,这是因为通过实现自动化以达到中等评级是相对比较容易,而达到高等评级则需要在文化和共享方面的努力,这相对来说更加难以掌握和实施.
这也符合组织文化变革中的J型曲线.
在经过了初期的效率增长之后,自动化的深化进入了瓶颈期.
更进一步的效率提升需要对组织、架构进行更加深入的调整.
这段期间可能还会有效率下降、故障率攀升的问题,从这一方面讲,实际DevOps落地和深化还有很长路要走.
转型的J型曲线团队开始转型,并识别出速赢方案自动化帮助低效能组织提升至中等效能组织自动化导致需要手工处理的测试需求增加.
大量的技术债阻碍了工作进展技术债和增长的复杂性导致变更流程中会额外增加人工控制环节和层级,减缓工作速度持续改进带来卓越与高效!
高效能和精英效能组织利用专业知识,并从他们身处的环境中学习,以使生产力发生飞跃TheCloud-nativeArchitectureWhitePaper37前面比较抽象的讲了一下DevOps的理念和原则,下面我们从更加技术的层面来分析DevOps.
4IaC和GitOpsIaC和声明式运维前面说过,DevOps所面对的矛盾就是开发和运维团队之间的矛盾.
因为两个团队的关注点完全不同,或者说是冲突的.
在这种背景下,IaC提出系统建设的核心理念,兼顾高效和安全,让运维系统的建设更加有序.

运维平台一般都经历过如下几个发展阶段:手工、脚本、工具、平台、智能化运维等.
现有运维平台虽然很多实现方式,但总体来说分为两类:两者的特点如下:采用声明式接口的方式相比较与指令式多一个执行引擎,把用户的目标转化为可以执行的计划.

最开始的运维系统一般都是指令式的,通过编写脚本来完成于运维动作,包括部署、升级、改配置、缩扩容等.

脚本的优点就是简单、高效、直接等,相对于更早之前的手工运维,这是一种极大的效率提高.
在分布式系统和云计算起步阶段,采用这种模式进行运维是完全合理的.
基于这个方法,各个部门都会相应建立一些系统和工具来加速工具的开发和使用.
不过随着系统复杂性逐步提高,指令式的运维方式的弊端也逐渐显现出来.
简单高效的优点同时也变成了最大缺点.
因为方式简单,所以无法实现复杂的控制逻辑;因为高效,如果有bug,那么在进行破坏时也同样高效.
往往一个小失误就会导致大面积服务瘫痪:一个变更脚本中的bug,可能会导致严重事故.
在复杂的运维场景下,指令式的运维方式具有变更操作副作用:不透明、指令性接口一般不具有幂等性、难以实现复杂的变更控制、知识难以积累和分享、变更缺乏并发性等缺点.
针对这种情况,人们提出了声明式的编程理念.

这是一个很简单的概念,用户仅仅通过一种方式描述其要到达的目的,而并不具体说明如何达到目标.
声明式接口实际上代表了一种思维模式:把系统的核心功能进行抽象和封装,让用户在一个更高的层次上进行操作.

指令式声明式指令式系统边界声明式系统边界用户操作用户目标执行引擎基础操作层基础操作层TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud38声明式接口是一种和云计算时代相契合的思维范式.
前面列出的指令式的缺点都可以由声明式接口来弥补.

幂等性:运维终态被反复提交也不会具有任何副作用.
声明式最明显的优点是变更审核简单明了.
配置中心会保存历史上的所有版本的配置文件.
通过对比新的配置和上一个版本,可以非常明确看到配置的具体变更.
一般来说,每次变更的范围不是很大,所以审核比较方便.
通过审核可以拦截很多人为失误.
通过把所有的变更形式都统一为对配置文件的变更,无论是机器的变更、网络的变更还是软件版本和应用配置的变更等.
在人工审核之外,还可以通过程序来检测用户配置是否合乎要求,从而捕捉用户忽略掉的一些系统性的限制,防患于未然.

复杂性抽象:系统复杂性越来越高,系统间相互依赖和交互越来越广泛,以及由于操作者无法掌握所有可能的假设条件、依赖关系等而带来的运维复杂性.
解决这个问题的唯一思路,就是要把更多逻辑和知识沉淀到运维平台中,从而有效降低用户使用难度和操作风险.
GitOpsGitOps作为IaC运维理念的一种具体落地方式,就是使用Git来存储关于应用系统的最终状态的声明式描述.
GitOps的核心是一个GitOps引擎,它负责监控Git中的状态,每当它发现状态有改变,它就负责把目标应用系统中的状态以安全可靠的方式迁移到目标状态,实现部署、升级、配置修改、回滚等操作.

Git中存储有对于应用系统的完整描述以及所有修改历史.
方便重建的同时,也便于对系统的更新历史进行查看,符合DevOps所提倡的透明化原则.
同时,GitOps也具有声明式运维的所有优点.
和GitOps配套的一个基本假设是不可变基础设施,所以GitOps和Kubernetes运维可以非常好的配合.
GitOps引擎需要比较当前态和Git中的终态间的差别,然后以一种可靠的方式把系统从任何当前状态转移到终态,所以GitOps系统的设计还是比较复杂的.
对于用户的易用,实则是因为围绕GitOps有一套完整的工具和平台的支持.
相对于传统IT基础设施,云具有更加灵活的调度策略,接近无限的资源、丰富的服务供用户选择、使用,这些都极大方便了软件的建设.
而云原生开源生态的建设,基本统一了软件部署和运维的基本模式.
更重要的是,云原生技术的快速演进,技术复杂性不断下沉到云,赋能开发者个体能力,不断提升了应用开发效率.

ConfigchangeGitSynchronizeKubernetes5云原生时代的DevOpsTheCloud-nativeArchitectureWhitePaper39首先是容器技术和Kubernetes服务编排技术的结合,解决了应用部署自动化、标准化、配置化问题.
CNCF打破了云上平台的壁垒,使建设跨平台的应用成为可能,成为事实上的云上应用开发平台的标准,极大简化了多云部署.
一个完整开发流程涉及到很多步骤,而环节越多,一次循环花费的时间越长,效率就越低.
微服务通过把巨石应用拆解为若干单功能的服务,减少了服务间的耦合性,让开发和部署更加便捷,可以有效降低开发周期,提高部署灵活性.
ServiceMesh让中间件的升级和应用系统的升级完全解耦,在运维和管控方面的灵活性获得提升.

Serverless让运维对开发透明,对于应用所需资源进行自动伸缩.
FaaS是Serverless的一种实现,则更加简化了开发运维的过程,从开发到最后测试上线都可以在一个集成开发环境中完成.
无论哪一种场景,后台的运维平台的工作都是不可以缺少的,只是通过技术让扩容、容错等技术对开发人员透明,让效率更高.

在云原生时代,传统中间件技术也演化升级为云原生中间件,云原生中间件主要包括网格化的服务架构、事件驱动技术、Serverless等技术的广泛应用,其中网格化(ServiceMesh)、微服务和Serverless前面都讲过了,这里主要讲云原生技术带来的不同点.
云原生中间件最大的技术特点就是中间件技术从业务进程中分离,变成与开发语言无关的普惠技术,只与应用自身架构和采用的技术标准有关,比如一个PHP开发的REST应用也会自动具备流量灰度发布能力、可观测能力,即使这个应用并没有采用任何服务化编程框架.
微服务架构一般包含下列组件:服务注册发现中心、配置中心、服务治理、服务网格、API管理、运行时监控、链路跟踪等.
随着Kubernetes的流行,Kubernetes提供的基础部署运维和弹性伸缩能力已经可以满足多数中小企业的微服务运维要求.
微服务与Kubernetes集成会是一个大趋势.
服务注册发现和配置中心的功能主要致力于解决微服务在分布式场景下的服务发现和分布式配置管理两个核心问题.
随着云原生技术的发展,服务发现领域出现了两个趋势,一个是服务发现标准化(Istio),一个是服务下沉(CoreDNS);配置管理领域也有两个趋势,一个是标准化(ConfigMap),一个是安全(Secret).
提到事件驱动就必须先讲消息服务,消息服务是云计算PaaS领域的基础设施之一,主要用于解决分布式应用的异步通信、解耦、削峰填谷等场景.
消息服务提供一种BaaS化的消息使用模式,用户无需预先购买服务器和自行搭建消息队列,也无需预先评估消息使用容量,只需要在云平台开通即用,按消息使用量收费.
例如阿里云MaaS(MessagingasaService)提供的是一站式消息平台,提供业界最主流的开源消息队列托管服务,包括Kafka、RabbitMQ、RocketMQ等;也支持多种主流标准协议规范,包括AMQP、MQTT、JMS、STOMP等,以满足微服务、IoT、EDA、Streaming等各种细分领域的需求.
事件驱动架构:由于IoT、云计算技术的快速发展,事件驱动架构在未来将会被越来越多的企业采纳,通过事云原生中间件7TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud40件的抽象、异步化,来提供业务解耦、加快业务迭代.
在过去事件驱动架构往往是通过消息中间件来实现,事件用消息来传递.
进入云计算时代,云厂商提供更加贴近业务的封装,比如Azure提供了事件网格,把所有云资源的一些运维操作内置事件,用户可以自行编写事件处理程序实现运维自动化;AWS则把所有云资源的操作事件都用SNS的Topic来承载,通过消息做事件分发,用户类似实现WebHook来处理事件.
由于事件是异步触发的,天然适合Serverless,所以现在很多云厂商都采用自身的Serverless服务来运行事件负载,包括阿里云FunctionCompute、AzureFunction、AWSLambda都和事件处理集成.
今年阿里云也发布了最新产品EventBridge,作为事件驱动和无服务器架构的核心承载产品.
TheCloud-nativeArchitectureWhitePaper41阿里巴巴云原生架构设计阿里巴巴为大量各行各业的企业客户提供基于阿里云服务的解决方案和最佳实践,帮助企业基于阿里云特别是云原生技术完成数字化转型,并积累了大量的方案和经验教训.
阿里巴巴将企业的核心关注点、企业组织与IT文化、工程实施能力等方面与架构技术等进行结合,形成了阿里巴巴独有的云原生架构设计方法——ACNA(AlibabaCloudNativeArchitecting).
ACNA是一个「4+1」的架构设计流程,「4」代表架构设计的关键视角,包括企业战略视角、业务发展视角、组织能力视角和云原生技术架构视角;「1」表示云原生架构的架构持续演进闭环.
4个架构视角和一个闭环的关系如下图所示:ACNA架构设计方法4ACNA(AlibabaCloudNativeArchitecting)架构设计方法1企业战略视角业务发展视角云原生技术架构视角服务化能力弹性能力无服务器化程度可观测性韧性能力自动化水平组织能力视角架构持续演进闭环架构持续演进闭环42TheCloud-nativeArchitectureWhitePaperACNA除了是一个架构设计方法,也包含了对云原生架构的评估体系、成熟度衡量体系、行业应用最佳实践、技术和产品体系、架构原则、实施指导等.
任何架构都必须服务于企业战略,云原生架构也不例外.
云原生架构和以往的架构升级不同,云原生架构不仅是一个技术升级,更是一个对企业核心业务生产流程(即通过软件开发和运营构建数字化业务)的重构,如果打一个比方的话,就像工业时代用更自动化的流水线替换手工作坊一样深刻.

企业必须规划清楚战略中业务战略与IT战略之间的关系,即IT战略只是服务好业务战略进行必要的技术支撑呢,还是IT战略本身也是业务战略的一部分.
通常高科技公司本身会对云计算有更高的需求,比如通过大量使用云厂商提供的AI技术为用户提供智能化的用户体验,也会使用IoT和音视频技术为用户建立更广泛和生动的连接.
实际上我们发现,在数字化转型的今天,越来越多的企业认为IT战略应该在企业战略中扮演技术赋能业务创新的重要角色,CTO(ChiefTechnologyOfficer)、CIO(ChiefInformationOfficer)、CDO(ChiefDataOfficer)、CISO(ChiefInformationSecurityOfficer)等岗位的设计也从一个层面表明了这些技术在企业战略中的位置.
阿里巴巴总结为企业提供云服务和咨询的过程,发现数字化业务对技术架构的主要诉求是业务连续性、业务快速上线、成本以及科技赋能业务创新.
业务连续性诉求主要包括了数字化业务必须能够持续为用户提供服务,不能因为软硬件故障或者bug导致业务不可用,也能够抵御黑客攻击、数据中心不可用、自然灾害等意外事故.
此外,当业务规模快速增长时,不能因为软硬件资源来不及购买或者部署而导致不能拓展新用户.
市场瞬息万变,数字化业务由于比传统实体业务更灵活可变而被要求更快的推向市场能力,包括新业务快速构建的能力、现有业务快速更新的能力.
这些能力诉求被云原生架构深刻理解并在产品、工具、流程等层面得到不同程度的处理,需要注意的是这个诉求同时对组织结构带来了新的要求,也可能要求应用进行彻底的重构(比如微服务化).
云计算作为新的技术必须为企业释放成本红利,帮助企业从原来的CAPEX模式转变为OPEX模式,不用事先购买大批软硬件资源,而是用多少付多少;同时大量采用云原生架构也会降低企业开发和运维成本,有数据展示通过采用容器平台技术就降低了30%以上的运维支出.
企业战略视角业务发展视角2343TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud传统模式下如果要使用高科技技术赋能业务,有一个冗长的选型、POC、试点和推广的过程,而大量使用云厂商和三方的云服务,由于这些云服务具备更快的连接和试错成本,且在不同技术的集成上具备统一平台和统一技术依赖的优势,从而可以让业务更快速的应用新技术进行创新.

云原生架构涉及到的架构升级对企业中的开发、测试、运维等人员都带来了巨大的影响,技术架构的升级和实现需要企业中相关的组织匹配,特别是架构持续演进需要有类似"架构治理委员会"这样的组织,不断评估、检查架构设计与执行之间的偏差.
此外前面提到云原生服务中重要的架构原则就是服务化(包括微服务、小服务等),这个领域典型的一个原则就是"康威定律",要求企业中让技术架构与企业沟通架构保持一致,否则会出现畸形的服务化架构实现.
组织能力视角云原生技术架构视角45用微服务或者小服务构建业务,分离大块业务中具备不同业务迭代周期的模块,并让业务以标准化API等方式进行集成和编排;服务间采用事件驱动的方式集成,减小相互依赖;通过可度量建设不断提升服务的SLA能力;自动根据业务峰值、资源负载扩充或者收缩系统的规模;在业务中尽量使用云服务而不是自己持有三方服务,特别是自己运维开源软件的情况;并让应用的设计尽量变成无状态的模式,把有状态部分保存到云服务中;尽量采用FaaS、容器/应用无服务器的云服务;IT设施需要被持续治理,任何IT设施中的软硬件发生错误后能够被快速修复,从而不会让这样的错误对业务带来影响,这就需要系统有全面的可观测性,从传统的日志方式、监控、APM到链路跟踪、服务QoS度量;1234服务化能力弹性能力无服务器化程度可观测性44TheCloud-nativeArchitectureWhitePaper除了包括服务化中常用的熔断、限流、降级、自动重试、反压等特性外,还包括高可用、容灾、异步化的特性;关注整个开发、测试和运维三个过程的敏捷,推荐使用容器技术自动化软件构建过程、使用OAM标准化软件交付过程、使用IaC(InfrastructureasCode)/GitOps等自动化CI/CD流水线和运维过程;关注业务的数字化安全,在利用云服务加固业务运行环境的同时,采用安全软件生命周期开发,使应用符合ISO27001、PCIDSS、等级保护等安全要求.
这个维度作为基础维度,要求在架构评测中关注但是并不参与评分.

云原生架构演进是一个不断迭代的过程,每一次迭代都是从企业战略、业务诉求到架构设计与实施的一个完整闭环,整体关系如下图:567韧性能力自动化水平安全能力架构持续演进闭环6架构持续演进闭环企业战略视角业务发展视角01.
识别业务痛点和架构债务02.
确定架构迭代目标03.
评估架构风险04.
选取云原生技术05.
制定迭代计划06.
架构评审和设计评审07.
架构风险控制08.
迭代验收和复盘架构持续演进闭环45TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud其中,关键输入:企业战略视角、业务发展视角;关键过程:识别业务痛点和架构债务、确定架构迭代目标、评估架构风险、选取云原生技术、制定迭代计划、架构评审和设计评审、架构风险控制、迭代验收和复盘.
由于云原生架构包含了6个关键架构维度(简写为SESORA,Service+Elasticity+Serverless+Observability+Resilience+Automation),因此我们先定义关键维度的成熟度级别:由于云原生架构包含了6个关键架构维度(简写为SESORA,Service+Elasticity+Serverless+Observability+Resilience+Automation),因此我们先定义关键维度的成熟度级别:云原生架构成熟度模型7云原生架构成熟度模型:关键指标维度云原生架构成熟度模型指标维度云原生架构成熟度第一步根据SESORA对6个未读分别评分并汇总第二步根据分值分段获得评级结果ACNA-1(0分)零级服务化能力(Service)级别和定义部分服务化&缺乏治理(自持技术,初步服务化)小于等于10分全部服务化&有治理体系(自持技术,初步服务化)大于10且小于16分且无ACNA-1级Mesh化的服务体系(云技术,治理最佳实践)大于等于16分且无ACNA-2级无(单体应用)完全传统架构(未使用云计算或者云的技术能力)弹性能力(Elasticity)半闭环(监控+人工扩缩容)非全云方式闭环(监控+代码伸缩,百节点规模)基于云全闭环(基于流量等多策略,万节点规模)全人工扩缩容(固定容量)无服务器化程度(Serverless)无状态计算委托给云(计算、网络、大数据等)有状态存储委托给云(数据库、文件、对象存储等)全无服务器方式运行(Serverless/FaaS运行全部代码)未采用BaaS可观测性(Observability)性能优化&错误处理(日志分析、应用级监控、APM)360度SLA度量(链路级Tracing、Metrics度量)用户体验持续优化(用观测大数据提升业务体验)无韧性能力(Resilience)十分钟级切流(主备HA、集群HA、冷备容灾)分钟级切流(熔断、限流、降级、多活容灾等)秒级切流、业务无感(Serverless、ServiceMesh等)无自动化能力(Automation)基于容器的自动化(基于容器做CI/CD)具备自描述能力的自动化(提升软件交付自动化)基于AI的自动化(自动化软件交付和运维)无ACNA-2(1分)基础级ACNA-3(2分)发展级ACNA-4(3分)成熟级46阿里巴巴云原生产品家族包括容器产品家族、微服务产品家族、Serverless产品家族、ServiceMesh产品家族、消息产品、云原生数据库家族、云原生大数据产品家族等.

阿里云容器服务自从2016年5月正式推出,历经4年时间,服务了全球上万家企业客户.
阿里云容器服务产品家族可以在公共云、边缘计算和专有云环境提供企业容器平台.
阿里云容器产品以容器服务Kubernetes版(ACK)和ServerlessKubernetes(ASK)为核心,它们构建在阿里云基础设施阿里巴巴云原生产品家族云原生产品家族容器产品家族12业务流量阿里巴巴云原生产品家族公有云IaaS私有云IaaS混合云IaaS源代码容器镜像二进制包微服务网关(CSB)微服务平台(EDAS)容器平台(ACK/ASK/ACR)Serverless引擎(FC、SAE)ServiceMesh基础设施安全、限流、降级、熔断、灰度、流量控制、协议转换、SLA度量、故障注入、模拟流量……(EDAS、ACM、ARMS、AHAS)微服务引擎(MSE)MQ(MQ系列)数据库(PolarDB)大数据(AnalyticDB)其他BaaS……分布式配置(ACM)分布式事务(GTS)EventCenter(EventBridge)统一控制台安全生产IT服务治理SLA管理AIOPS应用元数据阿里巴巴云原生产品介绍547之上,计算、存储、网络、安全等,并为企业客户提供标准化接口、优化的能力和简化的用户体验.
通过的CNCFKubernetes一致性兼容认证的ACK为企业提供了一系列业务所需的必备能力,如安全治理、端到端可观测性、多云混合云等.
镜像服务(ACR)作为企业云原生应用资产管理的核心,企业可以借之高效管理Docker镜像、HelmChart等应用资产,并与CI/CD工具结合,组成完整DevSecOps流程.
微服务安全治理弹性/成本优化多云/混合云异构算力调度自动化、智能化运维体系服务网络ASM镜像服务ACR可观测性(日志、监控、追踪、告警)计算ECS、EBM、FPGA、ECI网络VPC、ENI、SLB、DNS、RDMA存储EBS、NAS、CPFS、OSS安全RAM、云安全中心ApacheDubboSpringCloud有状态应用MySQLRocketMQ大数据、智能应用ApacheFlinkTensorflow创新应用区块链IoTKubernetesService(ACK)公共云边缘计算ACK@Edge专有云企业版、敏捷PaaS版ServerlessKubernetes(ASK)阿里云容器产品大图EDAS(企业分布式应用服务)是一个面向微服务应用的应用全生命周期PaaS平台,产品全面支持HSF、Dubbo、SpringCloud技术体系,提供ECS集群和K8s集群的应用开发、部署、监控、运维等全栈式解决方案.
MSE(微服务引擎)是一个面向业界主流开源微服务框架SpringCloud、Dubbo的微服务平台,包含治理中心、托管注册/配置中心,一站式的解决方案帮助用户提升微服务的开发效率和线上稳定性.

ACM(应用配置管理),是一款应用配置中心产品,实现在微服务、DevOps、大数据等场景下的分布式配置服务,保证配置的安全合规.
CSBMicroGateway(微服务网关服务)针对微服务架构下API开放的特点,提供能与微服务环境的治理策略无缝衔接的网关服务,实现高效的微服务API开放.
微服务产品家族3TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud48GTS(全局事务服务)用于实现分布式环境下特别是微服务架构下的高性能事务一致性,可以与多种数据源、微服务框架配合使用,实现分布式数据库事务、多库事务、消息事务、服务链路级事务及各种组合.
ARMS(应用实时监控服务)是一款应用性能管理产品,包含前端监控、应用监控和Prometheus监控三大子产品,涵盖了浏览器、小程序、APP、分布式应用和容器环境等性能管理,实现全栈式性能监控和端到端全链路追踪诊断.
链路追踪(TracingAnalysis)为分布式应用的开发者提供了完整的调用链路还原、调用请求量统计、链路拓扑、应用依赖分析等工具,能够帮助开发者快速分析和诊断分布式应用架构下的性能瓶颈,提高微服务时代下的开发诊断效率.
PTS(PerformanceTestingService)是一款云化测试工具,提供性能测试、API调试和监测等多种能力,紧密结合监控、流控等产品提供一站式高可用能力,高效检验和管理业务性能.

FC(函数计算)是一个事件驱动的全托管Serverless计算服务,用户无需管理服务器等基础设施,只需编写代码并上传,函数计算会准备好计算资源,并以弹性、可靠的方式运行业务代码.

SAE(Serverless应用引擎)实现了Serverless架构+微服务架构的完美融合,真正按需使用、按量计费,节省闲置计算资源,同时免去IaaS运维,有效提升开发运维效率;SAE支持SpringCloud、Dubbo和HSF等流行的微服务架构.
Serverless工作流是一个用来协调多个分布式任务执行的全托管Serverless云服务,致力于简化开发和运行业务流程所需要的任务协调、状态管理以及错误处理等繁琐工作,让用户聚焦业务逻辑开发.

用户可以用顺序、分支、并行等方式来编排分布式任务,服务会按照设定好的顺序可靠地协调任务执行,跟踪每个任务的状态转换,并在必要时执行用户定义的重试逻辑,以确保工作流顺利完成.

托管服务网格(ASM)提供全托管的微服务应用流量管理平台,兼容Istio的同时,支持多个Kubernetes集群中应用的统一流量管理,为容器和虚拟机中应用服务提供一致的通信、安全和可观测能力.
Serverless产品家族ServiceMesh产品家族45TheCloud-nativeArchitectureWhitePaper49AHAS(应用高可用服务)是专注于提高应用及业务高可用的工具平台,目前主要提供应用架构探测感知,故障注入式高可用能力评测和流控降级高可用防护三大核心能力,通过各自的工具模块可以快速低成本的在营销活动场景、业务核心场景全面提升业务稳定性和韧性.

消息队列RocketMQ版是阿里云基于ApacheRocketMQ构建的低延迟、高并发、高可用、高可靠的分布式消息中间件.
该产品最初由阿里巴巴自研并捐赠给Apache基金会,服务于阿里集团13年,覆盖全集团所有业务,支撑千万级并发、万亿级数据洪峰,历年刷新全球最大的交易消息流转记录.

消息队列Kafka版是阿里云基于ApacheKafka构建的高吞吐量、高可扩展性的分布式消息队列服务,广泛用于日志收集、监控数据聚合、流式数据处理、在线和离线分析等,是大数据生态中不可或缺的产品之一,阿里云提供全托管服务,用户无需部署运维,更专业、更可靠、更安全.

消息队列AMQP版由阿里云基于AMQP标准协议自研,完全兼容RabbitMQ开源生态以及多语言客户端,打造分布式、高吞吐、低延迟、高可扩展的云消息服务.
微消息队列MQTT版是专为移动互联网(MI)、物联网(IoT)领域设计的消息产品,覆盖互动直播、金融支付、智能餐饮、即时聊天、移动Apps、智能设备、车联网等多种应用场景;通过对MQTT、WebSocket等协议的全面支持,连接端和云之间的双向通信,实现C2C、C2B、B2C等业务场景之间的消息通信,可支撑千万级设备与消息并发,真正做到万物互联.
阿里云消息服务MNS是一种高效、可靠、安全、便捷、可弹性扩展的分布式消息服务,能够帮助应用开发者在他们应用的分布式组件上自由的传递数据、通知消息,构建松耦合系统.

事件总线EventBridge是阿里云提供的一款无服务器事件总线服务,支持阿里云服务、自定义应用、SaaS应用以标准化、中心化的方式接入,并能够以标准化的CloudEvents1.
0协议在这些应用之间路由事件,帮助用户轻松构建松耦合、分布式的事件驱动架构.
PolarDB是阿里巴巴自主研发的下一代关系型分布式云原生数据库,目前兼容三种数据库引擎:MySQL、PostgreSQL、高度兼容Oracle语法;计算能力最高可扩展至1000核以上,存储容量最高消息产品家族云原生数据库产品家族67TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud50可达100T.
PolarDB经过阿里巴巴双十一活动的最佳实践,让用户既享受到开源的灵活性与价格,又享受到商业数据库的高性能和安全性.
PolarDB-X(原DRDS升级版)是由阿里巴巴自主研发的云原生分布式数据库,融合分布式SQL引擎DRDS与分布式自研存储X-DB,专注解决海量数据存储、超高并发吞吐、大表瓶颈以及复杂计算效率等数据库瓶颈难题,历经各届天猫双11及阿里云各行业客户业务的考验,助力企业加速完成业务数字化转型.
云原生数据仓库AnalyticDBMySQL版(简称ADB,原分析型数据库MySQL版)是一种支持高并发低延时查询的新一代云原生数据仓库,全面兼容MySQL协议以及SQL:2003语法标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库.
产品规格按需可选,基础版成本最低,适合BI查询应用;集群版提供高并发数据实时写入和查询能力,适用于高性能应用;弹性模式版本存储廉价按量计费,适用于10TB以上数据上云场景.
云原生数据仓库AnalyticDBPostgreSQL版,支持标准SQL2003,兼容PostgreSQL/Greenplum,高度兼容Oracle语法生态;具有存储计算分离,在线弹性平滑扩容的特点;既支持任意维度在线分析探索,也支持高性能离线数据处理;是面向互联网,金融,证券,保险,银行,数字政务,新零售等行业有竞争力的数据仓库方案.
云原生大数据产品家族8TheCloud-nativeArchitectureWhitePaper51案例一:申通快递核心业务系统云原生化上云案例随着云计算的普及与云原生的广泛应用,越来越多的从业者、决策者清晰地认识到「云原生化将成为企业技术创新的关键要素,也是完成企业数字化转型的最短路径」.
因此,具有前瞻思维的互联网企业从应用诞生之初就扎根于云端,谨慎稳重的新零售、政府、金融、医疗等领域的企业与机构也逐渐将业务应用迁移上云,深度使用云原生技术与云原生架构.
面对架构设计、开发方式到部署运维等不同业务场景,基于云原生架构的应用通常针对云的技术特性进行技术生命周期设计,最大限度利用云平台的弹性、分布式、自助、按需等产品优势.
借助以下几个典型实践案例,我们来看看企业如何使用云原生架构解决交付周期长、资源利用率低等实际业务问题.
各个行业面临的挑战及解决方案云原生解决方案6112背景和挑战云原生解决方案作为发展最为迅猛的物流企业之一,申通快递一直积极探索技术创新赋能商业增长之路,以期达到降本提效目的.
目前,申通快递日订单处理量已达千万量级,亿级别物流轨迹处理量,每天产生数据已达到TB级别,使用1300+个计算节点来实时处理业务.
过往申通快递的核心业务应用运行在IDC机房,原有IDC系统帮助申通安稳度过早期业务快速发展期.
但伴随着业务体量指数级增长,业务形式愈发多元化.
原有系统暴露出不少问题,传统IOE架构、各系统架构的不规范、稳定性、研发效率都限制了业务高速发展的可能.
软件交付周期过长,大促保障对资源的特殊要求难实现、系统稳定性难以保障等业务问题逐渐暴露.
在与阿里云进行多次需求沟通与技术验证后,申通最终确定阿里云为唯一合作伙伴,采用云原生技术和架构实现核心业务搬迁上阿里云.
2019年开始将业务逐步从IDC迁移至阿里云.
目前,核心业务系统已经在阿里云上完成流量承接,为申通提供稳定而高效的计算能力.
52TheCloud-nativeArchitectureWhitePaper申通核心业务系统原架构基于Vmware+Oracle数据库进行搭建.
随着搬迁上阿里云,架构全面转型为基于Kubernetes的云原生架构体系.
其中,引入云原生数据库并完成应用基于容器的微服务改造是整个应用服务架构重构的关键点.
综合考虑申通实际业务需求与技术特征,最终选择了「阿里云ACK+神龙+云数据库」的云原生解决方案,从而实现核心应用迁移上阿里云.
引入云原生数据库应用容器化微服务改造通过引入OLTP跟OLAP型数据库,将在线数据与离线分析逻辑拆分到两种数据库中,改变此前完全依赖Oracle数据库的现状.
满足在处理历史数据查询场景下Oracle数据库所无法支持的实际业务需求.
伴随着容器化技术的引进,通过应用容器化有效解决了环境不一致的问题,确保应用在开发、测试、生产环境的一致性.
与虚拟机相比,容器化提供了效率与速度的双重提升,让应用更适合微服务场景,有效提升产研效率.
由于过往很多业务是基于Oracle的存储过程及触发器完成的,系统间的服务依赖也需要Oracle数据库OGG同步完成.
这样带来的问题就是系统维护难度高且稳定性差.
通过引入Kubernetes的服务发现,组建微服务解决方案,将业务按业务域进行拆分,让整个系统更易于维护.
流量入口阿里云DNSLinux-BindF5-外部VIP外部:sto-express.
cn内部:stosystem.
comF5-内部VIP阿里云DNSPrivateZoneSLB-外部VIP外部:sto.
cn内部:stosystem.
comSLB-内部VIP接入层Nginx外网Nginx内网生产-2套Nginx接入内/外生产-3套Ingress内/外/办公网应用JavaVMVMECSPod.
NET.
NETJava中台中间件RedisOracle基础设施VMWare虚拟化平台物理机ACK神龙服务器云上中间件云RedisOLAP/OLTP上云混合态架构申通核心业务上云架构示意图53TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud2.
1架构阐述2.
2平台层2.
3应用服务层2.
4运维管理基础设施,全部计算资源取自阿里云的神龙裸金属服务器.
相较于一般云服务器(ECS),Kubernetes搭配神龙服务器能够获得更优性能及更合理的资源利用率.
且云上资源按需取量,对于拥有大促活动等短期大流量业务场景的申通而言极为重要.
相较于线下自建机房、常备机器,云上资源随取随用.
在大促活动结束后,云上资源使用完毕后即可释放,管理与采购成本更低,相应效率.
流量接入,阿里云提供两套流量接入,一套是面向公网请求,另外一套是服务内部调用.
域名解析采用云DNS及PrivateZone.
借助Kubernetes的Ingress能力实现统一的域名转发,以节省公网SLB的数量,提高运维管理效率.
成本方面:使用公有云作为计算平台,可以让企业不必因为业务突发增长需求,而一次性投入大量资金成本用于采购服务器及扩充机柜.
在公共云上可以做到随用随付,对于一些创新业务想做技术调研十分便捷.
用完即释放,按量付费.
另外云产品都免运维自行托管在云端,有效节省人工运维成本,让企业更专注于核心业务.

打通DevOps闭环,统一测试,集成,预发、生产环境;天生资源隔离,机器资源利用率高;流量接入可实现精细化管理;集成了日志、链路诊断、Metrics平台;统一ApiServer接口和扩展,天生支持多云跟混合云部署.
基于Kubernetes打造的云原生PaaS平台优势明显突出.
每个应用都在Kubernetes上面创建单独的一个Namespace,应用跟应用之间实现资源隔离.
通过定义各个应用的配置Yaml模板,当应用在部署时直接编辑其中的镜像版本即可快速完成版本升级,当需要回滚时直接在本地启动历史版本的镜像快速回滚.
线上Kubernetes集群采用阿里云托管版容器服务,免去了运维Master节点的工作,只需要制定Worker节点上线及下线流程即可.
同时业务系统均通过阿里云的PaaS平台完成业务日志搜索,按照业务需求投交扩容任务,系统自动完成扩容操作,降低了直接操作Kubernetes集群带来的业务风险.
3应用效益54TheCloud-nativeArchitectureWhitePaper稳定性方面:首先,云上产品提供至少5个9以上的SLA服务确保系统稳定,而自建系统稳定性相去甚远.
其次,部分开源软件可能存在功能bug,造成故障隐患.
最后,在数据安全方面云上数据可以轻松实现异地备份,阿里云数据存储体系下的归档存储产品具备高可靠、低成本、安全性、存储无限等特点,让企业数据更安全.

效率方面:借助与云产品深度集成,研发人员可以完成一站式研发、运维工作.
从业务需求立项到拉取分支开发,再到测试环境功能回归验证,最终部署到预发验证及上线,整个持续集成流程耗时可缩短至分钟级.
排查问题方面,研发人员直接选择所负责的应用,并通过集成的SLS日志控制台快速检索程序的异常日志进行问题定位,免去了登录机器查日志的麻烦.
赋能业务:阿里云提供超过300余种的云上组件,组件涵盖计算、AI、大数据、IOT等等诸多领域.
研发人员开箱即用,有效节省业务创新带来的技术成本.
案例二:完美日记电商业务案例212背景和挑战云原生解决方案作为美妆届的璀璨新星,完美日记(PerfectDiary)上线不到两年即成为天猫彩妆销冠,截至2020年4月,品牌SKU超过700个,全网用户粉丝数量超过2500万,月曝光量10亿+.
伴随着公司业务高速发展,技术运维对于面临着非常严峻的挑战.
伴随着"双11"电商大促、"双12"购物节、小程序、网红直播带货呈现爆发式增长趋势,如何确保微商城系统稳定顺畅地运行成为完美日记面对的首要难题.
其中,比较突出几个挑战包含以下几点:完美日记与阿里云一起针对所面临问题以及未来业务规划进行了深度沟通与研讨.
通过阿里云原生应用稳定性解决方案以解决业务问题.
引入阿里云容器服务ACK、SpringCloudAlibaba、PTS、AHAS、链路追踪等配套产品,对应用进行容器化改造部署,优化配套的测试、容量评估、扩所容等研发环节,提升产研效率.

系统开发迭代快,线上问题较多,定位问题耗时较长;频繁大促,系统稳定性保障压力很大,第三方接口和一些慢SQL存在导致严重线上故障的风险;压测与系统容量评估工作相对频繁,缺乏常态化机制支撑;系统大促所需资源与日常资源相差较大,需要频繁扩缩容.
55TheCloud-nativeArchitectureWhitePaperbyAlibabaCloudRedis云数据库弹性伸缩容器容器容器容器MQ消息队列云盘NASOSSDB弹性扩容容器容器kubernetesPTS性能测试服务ARMSAPM类全链路监控AHAS限流,熔断,降级,系统保护云监控监控,报警云日志日志类数据采集、消费、投递及查询分析功能PTS模拟真实业务峰值流量进行压测检验容器的弹性伸缩能力,验证DB的读写性能选用MQ做削峰填谷选用ARMS服务队业务全链路进行监控选用AHAS对业务进行限流,熔断,降级等治理工作选用云监控,对整体资源可用性,业务存活性等进行监控选用云日志服务,对各种日志进行集中采集分析方案的关键点是:高可用:利用应用高可用服务产品(AHAS)的限流降级和系统防护功能,对系统关键资源进行防护,并对整体系统水位进行兜底,确保大促平稳进行,确保顺畅的用户体验.
容量评估:利用性能测试服务(PTS)和业务实时监控(ARMS)对系统单机能力及整体容量进行评估,对单机及整体所能承载的业务极限量进行提前研判,以确保未来对业务大促需求可以做出合理的资源规划和成本预测.

大促保障机制:通过与阿里云服务团队的进行多次配合演练,建立大促保障标准流程及应急机制,达到大促保障常态化.
"使用ACK容器服务可以帮助我们快速拉起测试环境,利用PTS即时高并发流量压测确认系统水位,结合ARMS监控,诊断压测过程中的性能瓶颈,最后通过AHAS对突发流量和意外场景进行实时限流降级,加上阿里云团队保驾护航,保证了我们每一次大促活动的系统稳定性和可用性,同时利用ACK容器快速弹性扩缩容,节约服务器成本50%以上.
"——完美日记技术中台负责人完美日记核心应用架构示意图通过容器化部署,利用阿里云容器服务的快速弹性应对大促时的资源快速扩容.

提前接入链路追踪产品,用于对分布式环境下复杂的服务调用进行跟踪,对异常服务进行定位,帮助客户在测试和生产中快速定位问题并修复,降低对业务的影响.
使用阿里云性能测试服务(PTS)进行压测,利用秒级流量拉起、真实地理位置流量等功能,以最真实的互联网流量进行压测,确保业务上线后的稳定运营.
采集压测数据,解析系统强弱依赖关系、关键瓶颈点,对关键业务接口、关键第三方调用、数据库慢调用、系统整体负载等进行限流保护.
配合阿里云服务团队,在大促前进行ECS/RDS/安全等产品扩容、链路梳理、缓存/连接池预热、监控大屏制作、后端资源保障演练等,帮助大促平稳进行.
34应用收益客户声音56TheCloud-nativeArchitectureWhitePaper案例三:特步业务中台案例(零售、公共云)312背景和挑战云原生解决方案成立于2001年的特步,作为中国领先的体育用品企业之一,门店数6230家.
2016年,特步启动集团第三次战略升级,打造以消费者体验为核心的"3+"(互联网+、体育+和产品+)的战略目标,积极拥抱云计算、大数据等新技术,实现业务引领和技术创新,支撑企业战略变革的稳步推进.
在集团战略的促使下,阿里云中间件团队受邀对特步IT信息化进行了深度调研,挖掘阻碍特步战略落地的些许挑战:阿里云根据特步业务转型战略需求,为之量身打造了基于云原生架构的全渠道业务中台解决方案,将不同渠道通用功能在云端合并、标准化、共享,衍生出全局共享的商品中心、渠道中心、库存中心、订单中心、营销中心、用户中心、结算中心.
无论哪个业务线、哪个渠道、哪个新产品诞生或调整,IT组织都能根据业务需求,基于共享服务中心现有模块快速响应,打破低效的"烟囱式"应用建设方式.
全渠道业务中台遵循互联网架构原则,规划线上线下松耦合云平台架构,不仅彻底摆脱传统IT拖业务后腿的顽疾并实现灵活支撑业务快速创新,将全渠道数据融通整合在共享服务中心平台上,为数据化决策、精准营销、统一用户体验奠定了良好的产品与数据基础,让特步真正走上了"互联网+"的快车道.
2017年1月特步与阿里云启动全渠道中台建设,耗时6个月完成包括需求调研、中台设计、研发实施、测试验证等在内的交付部署,历经4个月实现全国42家分公司、6000+门店全部上线成功.
以下是特步全渠道业务中台总体规划示意图,商业套件导致无法满足特步业务多元化发展要求,例如多品牌拆分重组所涉及的相关业务流程以及组织调整.
对特步而言,传统应用系统都是紧耦合,业务的拆分重组意味着必须重新实施部署相关系统.

IT历史包袱严重,内部烟囱系统林立.
通过调研,阿里云发现特步烟囱系统多达六十三套,仅IT供应商就有三十余家.
面对线上线下业务整合涉及到的销售、物流、生产、采购、订货会、设计等不同环节及场景,想要实现全渠道整合,需要将几十套系统全部打通.
高库存、高缺货问题一直是服装行业的死结,特步同样被这些问题困扰着.
系统割裂导致数据无法实时在线,并受限于传统单体SQLServer数据库并发限制,6000多家门店数据只能采用T+1方式回传给总部,直接影响库存高效协同周转.
IT建设成本浪费比较严重,传统商业套件带来了"烟囱式"系统的弊端,导致很多功能重复建设、重复数据模型以及不必要的重复维护工作.
57TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud业务前台全渠道运营销售结算管理货权转移库存管理渠道管理采购管理销售管理渠道分销管理发货管理调拨管理库存管理业绩管理要货管理促销管理门店零售运营O2O结算订单接入订单管理订单适配库存可视商品管理商品订单管理全渠道运营支撑平台会员标签管理会员日管理积分体系升降级管理会员资料会员等级会员营销管理门店售罄率销售预警补货计算补货人工调整门店优先级参数配置智能配补调发货管理库位管理库存管理WMS绩效考核导购管理门店管理门店运营业务中台后台业务共享服务中心一期二期标签服务统计服务报表服务数据中心银联服务支付宝服务微信服务支付中心团购服务红包服务代金券服务营销中心推送服务积分服务注册服务会员中心结算对账服务O2O结算服务销售结算服务结算中心寻源服务跟踪服务订单服务交易中心库存可视盘点服务出入库服务库存中心促销服务类目服务商品服务商品中心门店服务组织服务基础服务渠道中心SAPPLMMESHR/OA门店零售POS分销订货B2B天猫淘宝官方商城特跑族APP特购商城CRM分销商城B2B2C会员商城WMS智慧导购私人定制下面是基于云原生中间件的技术架构示意图架构的关键点:应用POSOMSDRPCRM库存平衡全渠道运营平台基础设施后台系统阿里云IaaS服务CRM库存平衡全渠道运营平台K8SEDASMQARMSPTSCSB中心订单中心库存中心结算中心主数据商品中心会员中心营销中心……阿里云原生中间件产品应用侧:新技术架构全面承载面向不同业务部门的相关应用,包括门店POS、电商OMS、分销商管理供销存DRP、会员客户管理CRM.
此外,在全渠道管理方面也会有一些智能分析应用,比如库存平衡,同时可以通过全渠道运营平台来简化全渠道的一些配置管理.
所有涉及企业通用业务能力比如商品、订单等,可以直接调用共享中心的能力,让应用"更轻薄".
58TheCloud-nativeArchitectureWhitePaper共享中心:全渠道管理涉及到参与商品品类、订单寻源、共享库存、结算规则等业务场景,也涉及与全渠道相关的会员信息与营销活动等.
这些通用业务能力全部沉淀到共享中心,向不同业务部门输出实时/在线/统一/复用的能力.
直接将特步所有订单/商品/会员等信息融合、沉淀到一起,从根本上消除数据孤岛.
技术层:为了满足弹性、高可用、高性能等需求,通过Kubernetes/EDAS/MQ/ARMS/PTS等云原生中间件产品,目前特步核心交易链路并发可支撑10w/tps且支持无线扩容提升并发能力.
采用阿里历经多年双11考验的技术平台,稳定性/效率都得到了高规格保障,让开发人员能够更加专注在业务逻辑实现,再无后顾之忧.
基础设施:底层的计算、存储、网络等IaaS层资源.
后台系统:客户内部的后台系统,比如SAP、生产系统、HR/OA等.
3应用收益全渠道业务中台为特步核心战略升级带来了明显的变化,逐步实现了IT驱动业务创新.
经过中台改造后,POS系统从离线升级为在线化.
包括收银、库存、会员、营销在内的POS系统核心业务全部由业务中台统一提供服务,从弱管控转变为集团强管控,集团与消费者之间真正建立起连接,为消费者精细化管理奠定了坚实的基础.
中台的出现,实现了前端渠道的全局库存共享,库存业务由库存中心实时处理.
借助全局库存可视化,交易订单状态信息在全渠道实时流转,总部可直接根据实时经营数据对线下店铺进行销售指导,实现快速跨店商品挑拨.
中台上线后,售罄率提升8%,缺货率降低12%,周转率提升20%,做到赋能一线业务.
IT信息化驱动业务创新,通过共享服务中心将不同渠道类似功能在云端合并共享,打破低效的"烟囱式"应用建设方式,吸收互联网DDD领域驱动设计原则,设计线上线下松耦合云平台架构,不仅彻底摆脱了传统IT拖业务后腿的顽疾并灵活支撑业务快速创新.
全渠道数据融通整合在共享服务中心平台上,沉淀和打造出特步的核心数据资产,培养出企业中最稀缺的"精通业务,懂技术"创新人才,使之在企业业务创新、市场竞争中发挥核心作用.
截止2019年初,业务部门对IT部门认可度持续上升,目前全渠道业务支撑系统几乎全部自主搭建,80%前台应用已经全部运行在中台之上,真正实现技术驱动动企业业务创新.
一直以来,作为国内三大运营商之一的中国联通始终以新理念新模式促进信息基础设施升级.
推动网络资源优化演进升级,持续提升网络竞争力.
中国联通BSS核心系统随着用户规模增长,个性化业务复杂性日趋提升、竞争压力不断加大,以cBSS1.
0为核心的集中业务系统,在系统架构、支撑能力、业务运营等方面无法满足一体化运营发展要求的问题日益突出,主要体现在:中国联通号卡业务云化案例(传统业务,专有云)41背景和挑战59TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud难以满足个性化业务模式和新业务场景需求,客户与一线营业人员体感较差.

日常运营面临的新问题数量、种类多,待优化提升的需求压力大.
传统系统架构制肘了开放性、扩展性、体验性、稳定性均的提升,支撑能力与支撑模式无法满足集团IT集中一体化运营的业务需要.
外围对接系统众多.
作为全国唯一的号卡资源管理方和服务提供方,号卡资源集中共享系统需要与包括cBSS、商城网厅、省分BSS、北六ESS、总部CRM、沃易购等在内的四十余种外围系统对接.
因为要向全国所有销售系统提供号卡资源服务,对号卡资源集中共享系统提出了非常严苛的性能要求,进而也提出了更高规格的扩展性要求.
面向全渠道,号卡资源集中共享系统除了要向目前已存自有渠道(营业厅、电子渠道)、社会渠道提供高效稳定的服务外,也要考虑未来面向互联网渠道等新兴渠道开放服务能力.
这都对号卡资源集中共享系统的服务化、能力开放能力提出了很高的要求.
高性能挑战,满足全国要求的性能要求估算:面向未来的互联网营销模式以及物联网等新业务领域可能带来的更高要求.
传统架构存在无法横向扩展、同步调用流程长的问题.
引入分布式架构成为迫在眉睫的需求.

高可用挑战,号卡资源作为中国联通的核心资源的同时,号卡资源管理同样是销售流程的关键环节,号卡资源管理系统直接关系到销售业务是否可正常开展全国集中的号卡资源管理系统、直接关系到全国销售业务是否能正常开展,引入分布式架构的同时必须确保高可用.
2云原生解决方案中国联通与阿里云结合阿里云原生PaaS、阿里飞天操作系统、阿里云原生数据库以及中国联通天宫平台,共同研发运营商级专有云平台"天宫云",支撑中国联通核心业务应用.
合作过程中,阿里云从互联网架构,业务中台架构,云原生技术等方面出发,基于阿里云业务中台,互联网技术上的最佳实践,云原生完整技术产品的整体架构方案.
阿里云原生PaaS平台为业务能力层和核心能力层及能力开放管理平台提供包括:分布式服务框架、分布式消息服务、分布式数据服务、分布式监控等云原生技术服务、管理业务能力、技术组件、云原生运维管理服务在内的基本技术支持.
全面云化的系统:基于"平台+应用"的三层分布式架构模式,采取高内聚、低耦合、易扩展、服务化的设计原则,由去中心化的服务框架为应用提供服务,由能力开放平台提供能力集成和能力开放.

服务化设计:充分发挥平台线性扩展能力和服务化设计优势,纵向分多个中心、中心分多个模块,横向分层设计,从而实现业务需求的灵活响应和快速支撑.
下面是中国联通号卡应用的技术架构示意图.
60TheCloud-nativeArchitectureWhitePaper监控运维SLB软负载均衡WEB访问web.
xx.
comAPP访问app.
xx.
com能力开放csb.
xx.
comEDAS分布式服务框架WEB号码中心个性数据卡中心操作员中心报表中心日志中心业务服务标准服务号码查询号码入库卡入库……靓号费用查询成卡占用核心服务号码中心服务卡中心服务操作员中心服务报表中心服务日志中心服务业务参数号段成卡文件报表其他会话信息业务数据个性服务减免结果生效靓号减免审批协议转换基础监控分布式链路跟踪日志分析管控平台备份恢复应用发布安全防护协议转换异步事务流程解耦通知服务注册订购APPDRDS分布式关系型数据库服务+RDS数据库KVstore分布式缓存OSS分布式文件CSB能力开放平台MQ分布式消息服务个性数据个性数据个性数据个性数据下面是中国联通号卡应用的部署架构示意图.
部署架构的优势:负载均衡接入应用WEB访问web.
xx.
comAPP访问app.
xx.
com能力开放csb.
xx.
com负载均衡HSF服务调用WEB应用EDAS虚拟机APP应用EDAS虚拟机能力开放平台EDAS虚拟机业务服务平台服务号码中心EDAS虚拟机卡中心EDAS虚拟机操作员中心EDAS虚拟机报表中心EDAS虚拟机日志中心EDAS虚拟机分布式缓服务KVstore分布式数据库服务DRDS分布式文件服务OSS分布式消息服务MQ云数据库RDS共享平台服务:平台组件服务单独部署,自身分布式设计,全局应用、服务共享使用;分层分中心部署:应用、业务服务分层、分中心、分区部署,高度灵活、稳定、可扩展.

61TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud3应用收益彻底解决号码资源在多省、多渠道、多系统共同管理问题,过去号码状态同步问题多,一号多卖现象严重,有效降低业务冲突.
解决销售过程中由于传统架构瓶颈造成的各类业务问题,开卡业务效率提升了10倍,单日选号访问量提升了3倍,需求响应时间缩短了50%,上层业务效率显著提升.
支撑业务快速创新,比如:支撑微信红点业务推广,由推广前每天访问量1000万+,到推广一周后快速上升到1.
1亿+,完全满足业务部门销售策略支持需求.
实现集中管控,资源合理分配,彻底解决数据分散、号码利用率低问题.
作为广受好评的学习应用,TimingApp专注于帮助社区用户提升学习凝聚力,达成学习目标.
目前已有超过700万人通过Timing进行高效学习.
与传统在线学习应用不同,Timingapp提供了Timing自习室、图书馆学习、视频打卡、学习日记、契约群、学习服务等多类具有社交性质的在线教育服务,帮助用户找到自己的学习节奏,找到坚持学习的一万种理由.
Timing业务本身具有潮汐特性,用户访问主要集中在晚间和节假日.
受疫情影响,春节期间峰值流量暴增4倍,公司面临较大的运维成本压力.
在用户、流量爆发式增长背景下,TimingApp不得不直面以下四大痛点:TimingApp的Serverless实践案例51背景和挑战系统稳定性差.
原有PHP单应用架构系统无法做到线性快速扩容,在业务高峰时段,系统问题频繁发生,严重影响用户体验.
产品迭代缓慢.
随着业务的高速发展,原有单体架构对于产品的迭代力不从心,没法快速响应研发需求.

资源使用浪费.
由于业务具有非常强的流量潮夕特征,需要按照业务高峰阶段进行资源保有配置,造成资源的浪费.
技术成本昂贵.
以前的团队除了技术负责人及少数团队新成员外,基本缺乏微服务架构实战经验.
想要实现微服务改造,急需能够快速上手的平台支撑,需要最大限度降低底层IaaS,容器以及常用微服务套件的学习成本.
2云原生解决方案62阿里云应用引擎Serverless(SAE),基于Serverless架构,屏蔽了底层IaaS运维和K8s细节,区别于FaaS形态的Serverless产品,用户无需修改编程模型,零代码改造就能直接使用.
同时,完美结合SpringCloud/Duboo等微服务架构,提供应用发布、管理和服务治理等应用全生命周期的服务,完美贴合Timing的技术需求:极限弹性伸缩,应用生命周期灵活管理,完美支持主流微服务架构.

下图的方案架构示意图.
方案的关键优势是:TimingApp在较短时间内和阿里云共同梳理业务结构,将之前的PHP单体应用转型为了微服务架构,包括用户中心、群组中心、资源中心、调度中心、图书馆中心、认证中心、学习中心、支付中心、自习中心等九大业务模块.

方案实施后,TimingApp实现了降本增效,护航系统稳定性,为提升用户体验,增加用户粘性作出了重要贡献.

TheCloud-nativeArchitectureWhitePaper用户中心群组中心资源中心调度中心图书馆中心认证中心学习中心支付中心自习中心xxx中心SpringCloud应用平台Kubernetes集群平台资源池屏蔽的底层资源应用生命周期管理极致弹性伸缩管理实时应用监控配置中心注册中心多发布策略服务安全优雅上下线日志管理负载均衡流量可控制SAE微服务化单体PHP应用ECS利用弹性伸缩,应对不确定突发流量.
提供秒级自动弹性&定时弹性能力,帮助应用轻松应对大促峰值流量,保证SLA的同时也节省机器保有成本.
多适用于互联网、游戏、在线教育行业.
应用环境随需灵活启停,节约成本.
提供了一键启停开发测试环境的能力,即开即用,节省成本,方便运维.

适用于对成本敏感、云上有多套环境但部分环境闲置率较高的企业型客户(不限行业).

中小企业快速构建云上微服务应用.
帮助用户屏蔽底层IaaS购买和运维细节、底层K8s细节,低门槛部署微服务应用.
适用于初创型/上升期的公司(不限行业),业务增长很快,对增长有较高预期,但人员配置跟不上.
整体技术架构更为清晰,每个服务相互独立且职责明确.
加之阿里云应用引擎Serverless(SAE)加持,让客户只关注在业务层,做好产品.
3应用收益63TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud降成本:大幅节省自建微服务架构的云服务器成本.
基于秒级弹性能力,无需长期保有固定资源,按需自动弹、按分钟计费,极大提升了资源利用率.
提效率:屏蔽了底层IaaS购买、底层Kubernetes细节和运维的烦恼,低门槛部署Dubbo/SpringCloud等微服务应用,支撑新业务快速上线.
此外,还提供了QPS、RT、接口调用量、错误数等实时监控功能,帮助研发人员快速定位问题,提升诊断效率,让企业聚焦于业务本身.
业务稳定:基于阿里云应用引擎Serverless(SAE)的定时弹性能力和基于监控指标弹性(CPU/Memory等),无须容量规划,秒级弹性,便可轻松应对流量暴增,保障SLA.
64云原生架构未来发展趋势7容器技术发展趋势1ServerlessServerless容器函数计算分布式云从多云/混合云,到分布式云新一代的计算单元云原生操作系统动态、混合、分布式的云环境将成为新常态统一技术栈,统一应用界面,统一管理界面-公共云服务能力将延伸到边缘计算和IDC-云原生架构推进无边界云计算,促成云边端应用一体协调在云端,Serverless技术逐渐融入主流极致弹性,免运维,强安全,高效开发-与云深度融合,复杂性下沉,无限弹性-新的应用开发、交付范形开始形成云原生操作系统开始浮现定义开放标准,向下封装资源,向上支撑应用-计算、存储、网络、安全的云原生进化-多种工作负载、海量计算任务,多种异构算力的高效调度和编排-标准化、自动化、可移植、安全可控的应用交付、管理体系无处不在的计算催生新一代容器实现针对计算场景优化、安全、轻重、高效-基于MicroVM的安全容器-基于WebAssembly的可移植、轻量容器-OS虚拟化创新,如cgroupv2提升隔离性随着互联网的发展到万物智联,5G、AIoT等新技术的涌现,随处可见的计算需求已经成为现实.
针对不同计算场景,容器运行时会有不同需求.
KataContainer、Firecracker、gVisor、Unikernel等新的容器运行时技术层出不穷,分别解决安全隔离性、执行效率和通用性三个不同维度的要求.
OCI(OpenContainerInitiative)标准的出现,使不同技术采用一致的方式进行容器生命周期管理,进一步促进了容器引擎技术的持续创新.
其中,我们可以预见以下几个细分方向的未来趋势:1趋势一:无处不在的计算催生新一代容器实现65TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud基于MicroVM的安全容器占比将逐渐增加,提供更强的安全隔离能力.
虚拟化和容器技术的融合,已成为未来重要趋势.
在公共云上,阿里云容器服务已经提供了对基于KataContainer的阿里云的袋鼠容器引擎支持,可以运行不可信的工作负载,实现安全的多租隔离.
基于软硬一体设计的机密计算容器开始展露头角.
比如阿里云安全、系统软件、容器服务团队以及蚂蚁金服可信原生团队共同推出了面向机密计算场景的开源容器运行时技术栈inclavare-containers,支持基于IntelSGX机密计算技术的机密容器实现,如蚂蚁金服的Occlum、开源社区的Graphene等LibaryOS.
它极大降低了机密计算的技术门槛,简化了可信应用的开发、交付和管理.
WebAssembly作为新一代可移植、轻量化、应用虚拟机,在IoT,边缘计算,区块链等场景会有广泛的应用前景.
WASM/WASI将会成为一个跨平台容器实现技术.
近期Solo.
io推出的WebAssemblyHub就将WASM应用通过OCI镜像标准进行统一管理和分发,从而更好地应用在Istio服务网格生态中.
Kubernetes已经成为云时代的操作系统.
对比Linux与Kubernetes的概念模型,他们都是定义了开放的、标准化的访问接口;向下封装资源,向上支撑应用.
它们都提供了对底层计算、存储、网络、异构计算设备的资源抽象和安全访问模型,可以根据应用需求进行资源调度和编排.
Linux的计算调度单元是进程,调度范围限制在一台计算节点.
而Kubernetes的调度单位是Pod,可以在分布式集群中进行资源调度,甚至跨越不同的云环境.
2趋势二:云原生操作系统开始浮现应用硬件操作系统(OperatingSystem)工具与开发库(UtilitiesandLibraries)ShellGCC/Java标准类库配置管理内核(OSKernel)SystemCalls设备驱动资源调度进程管理安全模型I/O管理API与系统服务(APIandSystemServices)POSIX系统服务Window管理器软件包管理Yum等安全管理服务云原生应用公共云、专有云、边缘计算云原生操作系统(CloudNativeOS)拓展服务AI计算Kubeflow服务网格Istio无服务器Knative应用管理OAMKubernetesCoreKubernetesCore基础设施资源抽象存储CSI,网络CNI,DevicePlugin,云供应商CCM等资源调度Pod管理安全模型CRD/ControllerKubernetesResources工作负载存储卷服务发现/路由镜像仓库安全管理服务66TheCloud-nativeArchitectureWhitePaperWeb/mobileapplications-Stateless-Idempotent-HorizontalscalableZookeeperElasticSearchTensorFlowRedisMysqlKafkaTIDBSparkFlinkKubernetesComputePublicCloudEdgeComputingPrivateCloudNetworkStorageSecurity从无状态应用,到企业核心应用,到数据智能应用过往Kubernetes上主要运行着无状态的Web应用.
随着技术演进和社区发展,越来越多有状态应用和大数据/AI应用负载逐渐迁移到Kubernetes上.
Flink、Spark等开源社区以及Cloudera、Databricks等商业公司都开始加大对Kubernetes的支持力度.
统一技术栈提升资源利用率:多种计算负载在Kubernetes集群统一调度,可以有效提升资源利用率.
Gartner预测"未来3年,70%AI任务运行在容器和Serverless上.
"AI模型训练和大数据计算类工作负载需要Kubernetes提供更低调度延迟、更大并发调度吞吐和更高异构资源利用率.
阿里云在和Kubernetes上游社区共同合作,在SchedulerV2framework上,通过扩展机制增强Kubernetes调度器的规模、效率和能力,具备更好的兼容性,可以更好的支撑多种工作负载的统一调度.
统一技能栈降低人力成本:Kubernetes可以在IDC、云端、边缘等不同场景进行统一部署和交付.
云原生提倡的DevOps文化和工具集可以有效提升技术迭代速度并降低人力成本.
加速数据服务的云原生化:由于计算存储分离具备巨大的灵活性和成本优势,数据服务的云原生化也逐渐成为趋势.
容器和Serverless的弹性可以简化对计算任务的容量规划.
结合分布式缓存加速(比如Alluxio或阿里云Jindofs)和调度优化,大大提升数据计算类和AI任务的计算效率.
Serverless和容器技术也开始融合得到了快速的发展.
通过Serverless容器,一方面根本性解决Kubernetes自身复杂性问题,让用户无需受困于Kubernetes集群容量规划、安全维护、故障诊断等运维工作;一方面进一步释放云计算能力,将安全、可用性、可伸缩性等需求下沉到基础设施实现.

上云已是大势所趋,但对于企业客户而言,有些业务出于对数据主权、安全隐私的考量,会采用混合云架构.
一34趋势三:Serverless容器技术逐渐成为市场主流趋势四:动态、混合、分布式的云环境将成为新常态67TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud些企业为了满足安全合规、成本优化、提升地域覆盖性和避免云厂商锁定等需求,会选择多个云厂商.
混合云/多云架构已成为企业上云新常态.
Gartner指出,"到2021,超过75%的大中型组织将采用多云或者混合IT战略.
"此外边缘计算将成为企业云战略的重要组成部分,为应用提供更低网络延迟,更高网络带宽和更低网络成本.
我们需要有能力将智能决策、实时处理能力从云延展到边缘和IoT设备端.
随着云平台已经成为企业数字化转型的创新平台,一个变化随之产生——云正在靠近它们.
在分布式云中,公有云的服务能力可以位于不同的物理位置,而公共云平台提供者会负责服务的运维、治理、更新和演变.

然而不同环境的基础设施能力、安全架构的差异会造成企业IT架构和运维体系的割裂,加大云战略实施复杂性,增加运维成本.
在云原生时代,以Kubernetes为代表的云原生技术屏蔽了基础设施差异性,推动了以应用为中心的混合云/分布式云架构的到来.
从而更好地支持不同环境下应用统一生命周期管理和统一资源调度.
Kubernetes已经成为企业多云管理的事实基础,阿里云容器服务ACK去年9月份发布了混合云2.
0架构,提供了完备的混合云Kubernetes管理能力.
ACK提供了统一集群管理能力,除了可以管理阿里云Kubernetes集群之外,还可以纳管用户在IDC的自有Kubernetes集群和其他云的Kubernetes集群.
利用统一的控制平面实现多个集群的统一的安全治理、可观测性、应用管理、备份恢复等能力.
比如利用日志服务、托管Prometheus服务,可以无侵入的方式帮助用户对线上、线下集群有一个统一的可观测性大盘.
利用云安全中心,AHAS可以帮助客户在混合云的整体架构中发现并解决安全和稳定性风险.
ASM-统一流量治理ASM-统一流量治理APMPrometheusASMSidecar(可选)接入AgentACK敏捷版K8s集群ASMSidecar(可选)ACK接入Agent其他云K8s集群ASMSidecar(可选)跨集群路由发布策略流量管理弹性策略地域亲和性全链路监控故障转移全局服务发现安全治理可观测性弹性调度应用发布ACK公有云K8s集群无侵入低成本日志服务AHAS安全中心混合云2.
0架构68TheCloud-nativeArchitectureWhitePaper托管服务网格ASM提供统一的服务治理能力,结合阿里云云企业网CEN、智能接入网关SAG提供的多地域、混合云网络能力,可以实现服务就近访问,故障转移,灰度发布等功能.
ACK也提供了统一的应用交付能力,通过GitOps方式可以将应用安全、一致、稳定地发布在多个不同的云环境中.
配合网格ASM提供的流量管理能力,可以支持云容灾、异地多活等应用场景,提升业务连续性.

Kubenetes已经成为了云原生的操作系统,而容器成为了操作系统调度的基本单元,同时定义了应用交付的标准.
但是对于应用开发者来说,这些还远没有深入到应用的架构,改变应用的编程界面.
但是这种变革已经在悄然发生了,而且有不断加速之势.
综上,包括生命周期管理、运维管理、配置范围和扩展和管理、以及语言无关的编程框架,一起构成了崭新的应用与云之间的编程界面.
这一变革的核心逻辑还是把应用中和业务无关的逻辑和职责,剥离到云服务,并在这个过程中形成标准,让应用开发者能够在专有云、公有云、或者混合云的场景中,都能有一致的研发运维体验.

基于云原生的新一代应用编程界面2Sidecar架构彻底改变了应用的运维架构.
由于Sidecar架构支持在运行时隔离应用容器与其他容器,因此原本在虚拟机时代和业务进程部署在一起的大量运维及管控工具,都被剥离到独立的容器里进行统一管理.

对于应用来说,仅仅是按需声明使用运维能力,能力的实现成为云平台的职责.

应用生命周期全面托管.
在容器技术基础上,应用进一步描述清晰自身状态(例如通过LivenessProbe),描述自身的弹性指标以及通过ServiceMesh和Serverless技术将流量托管给云平台.
云平台将能够全面管理应用的生命周期,包括服务的上下线、版本升级、完善的流量调配、容量管理等,并保障业务稳定性.

用声明式配置方式使用云服务.
云原生应用的核心特点之一就是大量依赖云服务(包括数据库、缓存、消息等)构建,以实现快速交付.
而这些服务的配置实际上是应用自身的资产,为了能够让应用无缝地运行在混合云的场景,应用逐渐开始以基础设施即代码的方式使用云服务.
正因如此,相关的产品如Terraform、Pulumi越来越受到应用开发者的拥抱.
语言无关的分布式编程框架成为一种服务.
为了解决分布式带来的技术挑战,传统中间件需要在客户端SDK编写大量的逻辑管理分布式的状态.
今天,还是基于Sidecar架构,我们看到很多项目在把这些内容下沉到Sidecar中,并通过语言无关的API(基于gPPC/HTTP)提供给应用.
这一变化进一步简化应用代码的逻辑和应用研发的职责,例如配置的绑定,身份的认证和鉴权都可以在Sidecar被统一处理.
在这个方面dapr.
io和cloudstate.
io是先行者.
69近年来,Serverless一直在高速发展,呈现出越来越大的影响力.
在这样的趋势下,主流云服务商也在不断丰富云产品体系,提供更便捷的开发工具,更高效的应用交付流水线,更完善的可观测性,更丰富的产品间集成.

Serverless发展趋势3TheCloud-nativeArchitectureWhitePaperbyAlibabaCloud任何足够复杂的技术方案都可能被实现为全托管、Serverless化的后端服务.
不只是云产品,也包括来自合作伙伴和三方的服务,云及其生态的能力将通过API+Serverless来体现.
事实上,对于任何以API作为功能透出方式的平台型产品或组织,例如钉钉、微信、滴滴等等,Serverless都将是其平台战略中最重要的部分.
通过事件驱动和云服务连接,Serverless能力也会扩展到整个云的生态.
无论是用户自己的应用还是合作伙伴的服务,无论是on-premise环境还是公有云,所有的事件都能以Serverless的方式处理.
云服务及其生态将更紧密地连接在一些,成为用户构建弹性、高可用应用的基石.
虚拟机和容器是两种取向不同的虚拟化技术,前者安全性强、开销大,后者则相反.
Serverless计算平台一方面要求兼得最高的安全性和最小的资源开销,另一方面要保持对原有程序执行方式的兼容,比如支持任意二进制文件,这使得适用于特定语言VM的方案不可行.
以AWSFireCracker为例,其通过对设备模型的裁剪和kernel加载流程的优化,实现百毫秒的启动速度和极小的内存开销,一台裸金属实例可以支持数以千计的实例运行.
结合应用负载感知的资源调度算法,虚拟化技术有望在保持稳定性能的前提下,将超卖率提升一个数量级.