>> 艾瑞咨询-数字时代应用可持续性架构与验证白皮书-221223
| 上传日期: |
2022/12/23 |
大小: |
6124KB |
| 格式: |
pdf 共81页 |
来源: |
艾瑞咨询 |
| 评级: |
-- |
作者: |
-- |
| 下载权限: |
无限制-登录即可下载 |
|
|
应用可持续性概述 应用可持续是指企业利用IT资源,保障应用稳定运行,可持续地满足客户的需求与期望。应用可持续与高可用的联系与区别在于:高可用是应用可持续的必要非充分条件,而应用可持续不仅包括了基础设施侧的稳定性,还包括了用户侧的体验,是更为严苛的要求。 应用可持续性仍然可以使用高可用的SLI、SLO和SLA等进行衡量,但SLI的具体指标可更宽泛。SLI(Service Level Indicator,服务水平指标),对于业务来说是最重要的指标,对于一般应用来说,是正常响应的百分比。SLO(Service Level Object,服务水平目标),是围绕SLI构建的目标。通常用n个9的百分比表示,并与一个时间范围挂钩,比如月度、季度、年度等。SLA(Service Level Agreement,服务水平协议)是企业围绕SLO发布的协议,它是要求在不满足SLO时向客户补偿的协议。 需要强调的是,随着敏捷开发、CI/CD、DevOps等理念的兴起与逐渐落地,应用可持续实际上需要在敏态中完成。比如,A/B测试、灰度发布时,业务应是平滑的,客户是无感知的。 应用可持续性架构,是指为了满足应用可持续,而采用的系统的、整体的IT架构,主要通过全生命周期健康检查与可观测、双活双轨、动态负载、主动韧性等手段,来摆脱对个别产品稳定性以及对个别运维人员的强依赖。应用可持续性架构,可以看作是软件工程思想在IT运维领域的具体实践。 应用可持续性架构验证,是指客户在选择应用可持续性架构及产品时,进行验证的方法论和具体指标。
研究报告全文:数字时代应用可持续性架构与验证白皮书202212iResearchInc2022年数字时代应用可持续性架构与验证白皮书白皮书目录第一章数字化时代的应用可持续性4一应用可持续性概述4二应用可持续性背景51中国数字经济迅速发展52产业数字化进入了深水区6三应用可持续性价值71应用故障为企业带来直接经济损失72政务金融领域的应用可持续性关系国计民生8第二章应用可持续性挑战10一敏捷挑战10二信创挑战11三疫情挑战12第三章应用可持续性架构设计思想与特征14一应用可持续性架构设计思想141抽象与分层142不同层解耦143同层节点冗余替换水平扩展与异构154中间层和核心节点的稳定性保障175持久化存储且共享18二应用可持续性架构特征181跨域协同与平滑迁移182多协议支持233与现代高可用架构无缝对接264可观测性和分析275负载可编排306主动韧性327开放与集成33第四章应用可持续性架构验证指标体系34一性能测试341四层吞吐性能测试342四层新建速率性能测试353四层并发性能测试354七层吞吐性能测试365七层新建事务速率性能测试386七层并发性能测试40二基础功能测试4112022年数字时代应用可持续性架构与验证白皮书白皮书1网络端口聚合功能412基本负载均衡算法IPv4IPv6双栈423VirtualServer功能434健康检查基本功能IPv4IPv6双栈445SNAT池基本功能456Cookie会话保持功能467HTTPheader会话保持功能468源地址插入和提取功能479连接镜像功能4810服务器温暖上线4811SSL卸载功能4912动态路由功能IPv4IPv6双栈5013主备模式高可用功能5114NM集群功能52三超高可用架构场景测试531超高可用架构协同集成功能532Kubernetes环境集成实现四层虚拟服务器自动创建543Kubernetes环境集成实现七层虚拟服务器自动创建544Kubernetes环境集成实现真实服务器自动扩容和缩减555集中管理平台统一纳管功能556TML-ADCBIGIP设备批量升级功能567TML-ADCBIGIP配置备份功能测试578NGINXTML-ADCBIGIP日志管理功能579集中管理平台告警功能58四管理功能测试591配置文件备份和恢复592数据统计和报表功能593网络管理扩展功能604运维管理工具605Syslog功能616SNMP与NTP功能617API接口628WebCLIAPI管理功能62第五章展望64特别鸣谢66附录应用可持续性架构测试示例67公司介绍法律声明79版权声明7922022年数字时代应用可持续性架构与验证白皮书白皮书免责条款79合作说明79联系我们79微信公号7932022年数字时代应用可持续性架构与验证白皮书白皮书第一章数字化时代的应用可持续性一应用可持续性概述应用可持续是指企业利用IT资源保障应用稳定运行可持续地满足客户的需求与期望应用可持续与高可用的联系与区别在于高可用是应用可持续的必要非充分条件而应用可持续不仅包括了基础设施侧的稳定性还包括了用户侧的体验是更为严苛的要求应用可持续性仍然可以使用高可用的SLISLO和SLA等进行衡量但SLI的具体指标可更宽泛SLIServiceLevelIndicator服务水平指标对于业务来说是最重要的指标对于一般应用来说是正常响应的百分比SLOServiceLevelObject服务水平目标是围绕SLI构建的目标通常用n个9的百分比表示并与一个时间范围挂钩比如月度季度年度等SLAServiceLevelAgreement服务水平协议是企业围绕SLO发布的协议它是要求在不满足SLO时向客户补偿的协议需要强调的是随着敏捷开发CICDDevOps等理念的兴起与逐渐落地应用可持续实际上需要在敏态中完成比如AB测试灰度发布时业务应是平滑的客户是无感知的应用可持续性架构是指为了满足应用可持续而采用的系统的整体的IT架构主要通过全生命周期健康检查与可观测双活双轨动态负载主动韧性等手段来摆脱对个别产品稳定性以及对个别运维人员的强依赖应用可持续性架构可以看作是软件工程42022年数字时代应用可持续性架构与验证白皮书白皮书思想在IT运维领域的具体实践应用可持续性架构验证是指客户在选择应用可持续性架构及产品时进行验证的方法论和具体指标二应用可持续性背景1中国数字经济迅速发展2016-2021年中国数字经济发展取得新突破数字经济规模实现翻倍增长2021年中国数字经济规模由2016年的226万亿元增加至392万亿元数字经济增加值占GDP比重由303上升至398数字中国建设不断推进在推动经济高质量发展构建新发展格局中发挥了重要作用在数字经济迅速发展背景下技术进步数字适老化及信息无障碍服务持续完善等因素驱动我国网民规模稳步增长根据第50次中国互联网络发展状况统计报告截至2022年6月我国网民规模为1051亿互联网普及率达744较2021年12月提升14个百分点其中手机网民规模为1047亿同比增长约4随着数字化进程加快及互联网移动互联网等信息通信技术的更迭我国数据量呈爆发式增长态势2020年我国年数据量为12ZB占全球数据量24预计到2030年数据量将增长至175ZB年复合增长率约307占全球数据量比重将上升至29数字时代已然到来52022年数字时代应用可持续性架构与验证白皮书白皮书数字经济是当前经济发展的新动能而数字基础设施是数字未来的坚实底座截至2022年6月我国累计建成开通5G基站达1854万个网络基础设施全面向IPv6演进升级IPv6地址数量为63079块32IPv6活跃用户数达683亿互联网宽带接入端口数量达1035亿个光缆线路总长度达5791万公里数字基础设施建设实现跨越式发展数字经济和数据量的快速增长使得应用可持续性的重要性得到提升原来作为辅助的数字世界和物理世界变得同样重要而近几年的新冠疫情使得数字的重要性进一步得到提升另外数字经济和数据量的快速增长也使得应用可持续性面临前所未有的挑战一方面原有的软硬件产品和架构难以承担数据量的爆炸式增长而另一方面在老新迁移的过程中要求业务不能中断2产业数字化进入了深水区产业数字化是在满足原有产业组成结构的前提下传统产业通过数字技术进行升级改造或将数字技术应用至现有产业中从而为产业带来产值增加和效率提升近年来数字技术不断赋能传统行业产能增长我国数字经济与实体经济融合发展也渐入佳境作为推动数字经济发展的主动力产业数字化在数字经济结构的比重连年上涨根据中国数字经济发展白皮书2022数据产业数字化较数字产业化始终占据绝对优势2021年产业数字化占数字经济比重达到809同比增加07个百分点较2017年上涨39个百分点我国产业数字化的转型持续往纵深发展62022年数字时代应用可持续性架构与验证白皮书白皮书随着未来大数据人工智能等新一代信息技术的发展传统产业对数字化改造的需求日益增加叠加新兴技术在各传统产业的批量应用数字技术将与传统产业彼此融合相互促进进而持续推动实体经济转型升级产业数字化在数字经济结构的比重有望继续上涨产业数字化的主体是传统行业相比于互联网等原生数字行业IT人员占比更少技术水平更低IT也往往非其业务本身而往往是保障性环节因此不可能无限制地增加开支这些也都要求不能完全依赖于开发运维人员本身的IT素养而需要以更加健壮简洁的架构来保障应用的可持续性三应用可持续性价值1应用故障为企业带来直接经济损失在数字化时代的今天应用的稳定性和可持续性变得极为重要早在2018年保险公司劳合社与风险建模公司AIRWorldwide就联合发布了一份报告预测了主要云服务器出现故障后可能带来的损失报告表明如果三大云供应商AmazonGoogleMicrosoft发生一起36天的云故障将导致190亿美元的损失2021年10月4日Facebook长达6小时的宕机直接导致其股价暴跌672022年数字时代应用可持续性架构与验证白皮书白皮书除长时间宕机影响较大外短时间的访问延迟也会影响用户体验并进一步带来经济损失数据表明74的用户会离开5秒内未能打开的网站86的用户会卸载出现过3次以上性能问题的应用以上还仅是在一般的社交电商等领域而在证券等领域对延迟更为敏感对可持续性要求更为严格2政务金融领域的应用可持续性关系国计民生随着数字化对人们生活的日益渗透应用可持续性不仅在一般商业领域与经济效益直接相关而且在公共服务领域关系国计民生2021年12月20日和2022年1月4日西安一码通出现了两次崩溃使得民众不得不挨个手动登记身份重采核酸带来很大的不便与混乱与之类似2022年9月和11月四川天府健康通也因为流量过大出现部分用户暂时无法登录的现象根据凤凰网信息天津杭州哈尔滨澳门等地也先后出现崩坏问题这些都暴露出系统架构不健壮的问题82022年数字时代应用可持续性架构与验证白皮书白皮书公共服务不同于电商等领域不能单纯以ROI去衡量去提供有损服务未来随着5G物联网在自动驾驶远程医疗等领域的应用应用的可持续性会更加重要甚至关系到生命安全92022年数字时代应用可持续性架构与验证白皮书白皮书第二章应用可持续性挑战不管是从经济效益企业声誉还是从社会价值来说应用可持续性都极为重要但是应用可持续性的落地却并不容易它要求从数据中心到IT基础设施再到容器数据库等PaaS层最后到应用都可持续而这一切又是在用户数量网络流量不断增加应用复杂程度不断增加IT软硬件技术快速更新迭代的整体背景下一敏捷挑战业务开发和运维支撑本身需求就是天然相悖的极端来说研发部门想要随时随地发布新功能没有任何阻拦而运维部门则想要一旦一个东西在生产环境中正常工作了就不要再进行任何改动由于两个部门使用的语境不同对风险的定义也不一致在现实生活中公司内部这两股力量只能用最传统的政治斗争方式来保障各自的利益运维团队常常宣称任何变更上线前必须经过由运维团队制定的流程这有助于避免事故的发生例如运维团队会列出一个非常长的检查清单历数所有以前曾经出现过的生产事故要求研发团队在上线任何功能之前必须将所有这些事故模拟一遍确保不会重现这个清单通常没有任何标准每项事故的可重现程度问题价值并不一定是一致的而开发团队吃过苦头之后也很快找到了自己的应对办法开发团队宣称他们不再进行大规模的程序更新而是逐渐转为功能开关调整增量更新以及补丁化采用这些名词的唯一目的就是为了绕过运维部门设立的各种流程从而能更快地上线新功能1除以上人的因素外软硬件的利旧和业务需求以及技术本身的飞速发展也是一对稳与敏的矛盾以银行业为例国有银行和股份制银行普遍建设有动辄几十亿甚至上百亿的数据中心并在软硬件资源上具有大量投资它们不可能抛弃历史直接做架构的硬切换比如即使不考虑安全可控等要素它们也不可能直接切换到公有云与此同时在互联网时代成长起来的客户却迫使银行的业务侧增加了大量新的需求比如小额支付活动促销秒杀等在需求增加的同时新技术也层出不穷Docker在2013年开源Kubernetes在2014年开源而如今它们已经是互联网领域的主流技术另外NGINXIstioOpentelemetryPrometheusGrafanaMongoDBRedisTiDBOceanBase等开源技术也不断降低开发运维难度提升业务的敏捷性并降低企业的运营成本但是这些新技术没有经历足够长时间的检验并且个别点可能也不符合合规性要1美BERSYBEYERCHIRISJONES美JENNIFERPETOFFNIALLRICHARDMURPHY著孙宇聪译SREGoogle运维解密M北京电子工业出版社201610102022年数字时代应用可持续性架构与验证白皮书白皮书求此时银行便有了既要跟上新技术又要不直接放弃已有的数据中心和软硬件还要稳定合规不出现闪失的复杂性挑战二信创挑战在业务需求和新技术均快速变化的同时信创也为金融能源等企业的IT系统引入了新的复杂性信创即信息技术应用创新是我国企业为了应对国外技术限制如美国实体清单而自发组织的国产替代行为我国的信创大致可以分为四个阶段第一阶段大致为1999-2010年当时仅可做到单品可用以及面向特定场景解决了有无的问题第二阶段大致为2011-2013年该阶段做到了系统可用和成体系试用尤其是在办公自动化和经营管理类等系统中第三阶段大致为2014-2017年当时叠加互联网企业的去IOE浪潮开始向基础领域演进此阶段实现了基本可用到好用第四阶段在2018年之后在多场景中开始规模化应用不过在信创的高速发展中仍面临着业务连续性业务创新和安全防范的挑战目前在我国的诸多强IT依赖行业中英特尔英伟达甲骨文IBM戴尔威睿红帽SUSEF5等海外公司各自在不同领域为客户提供稳定的产品和优质的服务而国内对应产品良莠不齐平均水平跟这些公司还有一定差距因此我们应正视差距并设立科学严谨的验证标准首先在业务连续性方面112022年数字时代应用可持续性架构与验证白皮书白皮书应设立各环节产品服务的完整科学的验证标准在一个相对稳定的架构下先小规模试验改进扶持动态调整信创业务比例稳步扩大信创覆盖范围面对业务不确定性应可秒级恢复业务并排除故障找出故障原因其次在安全防护方面面对黑客无差别攻击需提高安全网关性能及可靠性并采用异构能力提高系统的对抗能力再次在业务创新方面应积极地拥抱分布式微服务等新兴架构以及开源生态但又要通过镜像扫描代码审计等降低因开源带来的风险三疫情挑战受疫情影响IT基础设施线下运维巡检人员减少疫情期间为了避免聚集运维领域出现了许多工作新常态例如不少数据中心都采用AB岗轮班制核心岗最小化办公或是工作方式转至远距离不接触的线上办公模式采取现场封闭办公居家协同形式到岗率从原先的100精简到50甚至不到10不少原来依赖于原厂运维或第三方运维的客户为了避免人员的流动降低人员感染风险也在一定程度上失去外援孤军奋战而与此同时互联网流量陡然增长由于疫情反复无常大众的办公金融医疗等生产生活的各个方面对线上对网络的依赖程度明显增加整个社会转入线上运行的趋势陡然加速互联网流量也由此以倍数级大幅提升根据国家发改委2022年1-6月我国移动互联网累计流量达1241亿GB较2021年1-6月的1033亿GB增长208亿GB同比增长约201线下运维巡检人员的减少和互联网流量的陡然增长对服务器计算存储和网络的水平扩展以及应用可持续性带来了新的需求与挑战IT基础设施管理人员对停电或极端天气事件等各种灾难有比较明确的应急预案但前所未有的新冠疫情为数据中心等基础设施的部署和运维工作提出了更高的要求诸多挑战跃然纸上亟待解决例如如何确保系122022年数字时代应用可持续性架构与验证白皮书白皮书统安全维护始终在线当遇到大并发的外网访问时如何对远程办公下的业务系统应用做好统一监控当出现高流量访问引发系统卡顿和事件告警时如何在海量数据中快速查找问题原因保障运维效率等等132022年数字时代应用可持续性架构与验证白皮书白皮书第三章应用可持续性架构设计思想与特征一应用可持续性架构设计思想应用可持续主要由三个方面构成控制和调度面的可持续一般对应Mater-Slave或Controller-Worker架构中的Master或者Controller执行面的可持续一般对应上述架构中的Slave或者Worker数据面的可持续一般利用共享且本身冗余的持久化存储如etcdRedis来实现1抽象与分层完整的业务应用需求传递链条为用户客户公司业务侧公司业务开发侧运维侧在单体架构以及瀑布流式开发中这种需求的变动缺乏在任何一层消化掉的能力而是一传到底因此业务之敏和基础设施之稳成为矛盾而从另一个视角来看当把业务看作稳态时假定业务需求一成不变基础设施侧也并不能保证一成不变数据中心需要扩容存储计算网络设备需要淘汰和更新换代在早期往往通过深夜停服等方式来进行但随着人们对IT依赖程度的逐渐加深这种方式可行性越来越低基础设施之敏和业务之稳也成为矛盾也就是链条的两侧其实均不关心对方具体发生了哪些变化只关心给自己带来了什么变化并希望自己可自由变化此时便需要一个中间层来将双方的变化相互翻译这种翻译的过程就是抽象的过程而中间层诞生就是分层在IT架构中负载均衡容器编排数据中台等都是这种抽象与分层而产生的中间层只是应用的场景不同2不同层解耦当中间层一旦产生中间层的上下便会变得简单而自由起来所有共性的东西每个节点一律不再关心因为中间平台层已经实现与上下其他N多节点之间的对接每个节点也不再关心因为中间平台层已完成翻译和对接原来复杂的乘积关系变成了只与中间层对接的加和关系142022年数字时代应用可持续性架构与验证白皮书白皮书这一相对统一的中间层由于作用如此重要因此往往成为业界事实上的标准也往往成为兵家必争之地KubernetesMarathonMesosSwarm之争便是如此一旦其中一种真正胜出标准便相对统一起来上下层短时间之内会出现大繁荣平台意义的中间层被取代相对缓慢即使在日新月异的IT界也是如此这也就让稳态和敏态的结合有了抓手当然在实际中往往存在多个类似意义的中间层比如在应用可持续中应用交付网络负载均衡可以看作第一个中间层其可一部分流量分给传统虚机另一部分流量分给容器云而在容器云中KubernetesOpenshift又可作为第二个中间层3同层节点冗余替换水平扩展与异构一旦实现了抽象与分层不同层解耦那么中间层也就成为了IT架构的核心只要它是相对稳定的上下层的变化便可在该层消化掉也即上层的变化不影响下层下层的变化也不影响上层这是稳态与敏态能够统一起来也是应用可持续性的关键所在上下层的节点作用被降低平行节点间可冗余可替换可水平扩展可异构冗余设置两个或更多相同功能的同类节点这里的节点可以是数据中心如同城双数据中心异地双数据中心也可以是分区例如最保守的做法是在早期让整个信创区完成与非信创区完全相同的功能也即不让其单独承担实际职责冗余是保证高可用与应用可持续较为稳妥的方式但如果在多层上冗余则实际上往往有4个8个甚至更多副本成本较高152022年数字时代应用可持续性架构与验证白皮书白皮书替换因为中间层是稳定层因此上下层的任何一个单一节点甚至一块区域都不再不可或缺而变成了可以热拔插的组件但需要节点将健康状态上报对应健康监测和可观测一旦出现故障立即切换到其他节点动态负载即是通过这种方式实现水平扩展当将故障节点的任务动态切换到健康节点有可能对健康节点造成负载冲击此时必须可以迅速补充新节点水平扩展属于自动化运维范畴在不同层级往往有不同手段例如物理机可使用Cobbler基于DHCP服务器和PXE环境迅速安装操作系统远程启动等虚拟机可以使用Ansible进行自动化管理而容器云则可以直接使用Kubernetes进行Node中Pod的扩展以及Pod中容器的扩展异构平行节点间也不再追求统一架构本身不仅兼容异构因为当某种攻击只针对其中一种软硬件产品时异构类型便可幸免于难成为有生力量并担起应用可持续的162022年数字时代应用可持续性架构与验证白皮书白皮书重任这种包容异构的特点其实为平滑迁移奠定了基础不管是从传统虚机向容器云和微服务还是从非信创向信创迁移的过程必然是异构状态其实蓝绿发布灰度发布AB测试等均是利用的节点间可自由替换的特性实现的只不过其往往是以相同的基础设施节点来运行不同的应用版本而上云信创替代则可用不同的基础设施来运行相同的应用4中间层和核心节点的稳定性保障在以上架构中有一个显而易见的问题是并没有考虑中间层和核心节点出现故障的情况如果DNS解析节点核心负载均衡器容器编排平台等出现故障核心节点或核心中间层的可用性一般通过以下手段进行保障1节点本身稳定生产系统中的核心节点一般采用成熟稳定久经考验的产品和技术并且版本升级策略一般也相对保守例如硬件方面成熟的SLBADC设备均具有非常强的稳定性与可靠性软件方面Kubernetes在2016年便有大量企业进行尝试但真正将其布到生产系统中则大多发生在2019年前后NGINX从其诞生到在各企业中广泛应用经历了十几年时间而为了保证稳定性其支持HTTP3协议的NGINX-QUIC很长时间单独存在直到现在仍未合并到NGINX主干中2轻负载只做核心任务由于核心节点具有全局性意义其稳定的性能往往比丰富的功能更加重要因此普遍的一种做法是只让其承担调度和控制层面的事项并不承担具体的工作任务例如四层负载只负责流量转发TCP的三次握手等直接分发到七层负载或应用节点再比如在不少银行中SSL卸载不再放入负载均衡设备中而是前后各一层负载均衡中间一层SSL卸载构成三明治结构还比如在早期的服务网格MOSN中让Sidecar承担更多负载而减少对中心节点的依赖172022年数字时代应用可持续性架构与验证白皮书白皮书3冗余冗余即主从架构对于核心节点比如负载均衡设备一般均采用冗余的方式来保障系统的高可用负载设备本身之间的冗余可用VIP地址漂移来实现也即只有一台物理设备来占用IP当该物理设备出现故障IP漂移到其他健康物理设备4产生新主节点产生新主节点即集群架构如果主节点并非采用专用设备那么在主节点出现故障时自动根据算法将某子节点提升为主节点这也是严格意义上的分布式目前这种方式在大数据领域以及区块链领域应用更为广泛相比于主从架构集群架构是严格意义上的分布式架构5持久化存储且共享节点的配置和服务发现数据通过高性能Key-Value内存数据库进行存储并持久化到硬盘中数据间通过Raft协议保持强一致性的共享在控制节点可使用etcd而在执行节点可使用Redis通过以上几步节点的网络可以通过VIP漂移或者上层负载编排平台的控制切换到其他节点节点的任务可以通过本来的冗余或快速启动实例切换到其他节点节点的数据因落到了共享的持久化存储中也可被其他节点无缝继承系统的健壮性和应用的可持续性不再依赖于任何单一节点自身的可靠性二应用可持续性架构特征1跨域协同与平滑迁移1跨域双活双轨数据中心双活架构双活是一种节约资源的计算机灾备方案其实现模式是让主备两个数据中心都同时承担用户的业务此时主备两个数据中心互为备份并且进行实时备份一般来说主数据中心的负载可能会多一些比如分担6070的业务备数据中心只分担4030的业务保证了当其中一边发生故障时不至于造成业务无法处理的情况与双活近似的是热备份和冷备份热备份备用数据中心对主数据中心实时备份但不承担业务当主数据中心业务中断时自动切换到备用数据中心是一种高可用但浪费资源的备份方式冷备份备用数据中心不对主数据中心实时备份只定期备份当主数据中心业务中断人工切换到备用数据中心是一种非高可用的备份方式182022年数字时代应用可持续性架构与验证白皮书白皮书双活数据中心要做到网络双活应用双活和数据双活金融等行业为了追求更高的可用性且考虑成本一般在双活之外再加灾备数据中心俗称两个半数据中心信创区和传统区双轨架构利用和数据中心双活类似的原理在同一数据中心中的信创区和传统区非信创区等不同模块之间实现热备或双活的方案即为双轨运行双轨架构相比于数据中心双活实现上更为复杂这是因为双活数据中心只是物理距离较远但网络计算存储设备一般较为统一所以组网相对容易而双轨相当于异生态组网需要更全面的软硬件生态屏蔽底层的异构和复杂19
|
|