第19章 架构紧张需求
软件开发最紧张的一个方面是明确你正在实验构建的东西是什么。
——比雅尼·斯特劳斯特鲁普（Bjarne Stroustrup），C++ 语言创造者
架构的存在是为了构建满意需求的体系。这里的 “需求” 并不愿定是挑拨用需求工程所能提供的最佳技能天生的一份有文档记载的目次。相反，我们指的是如许一组特性：如果你的体系不能满意这些特性，那么这个体系就会失败。需求以与软件开发项目一样多的情势存在 —— 从经心编写的规范到紧张长处相干者之间的口头共同明确（真实的或想象的）。你的项目需求实践的技能、经济和哲学依据超出了本书的范围。在本书范围内的是，无论需求以何种方式被捕捉，它们都创建了乐成或失败的标准，而架构师必要相识这些标准。
对架构师来说，并非全部需求都是划一紧张的。有些需求对架构的影响比其他需求大得多。一个 “架构紧张需求（ASR）” 是一个将对架构产生深远影响的需求 —— 也就是说，如果没有如许的需求，架构很大概会有很大的差异。
如果你不知道 ASR，就不大概计划出一个乐成的架构。ASR 通常（但不总是）以质量属性（QA）需求的情势出现 —— 即架构必须为体系提供的性能、安全性、可修改性、可用性、易用性等等。在 第 4 章 至 第 14 章 中，我们先容了实现质量属性的模式和计谋。每次你在架构中选择一个模式或计谋来利用时，都是由于必要满意质量属性需求。质量属性需求越困难、越紧张，就越有大概对架构产生巨大影响，因此也就越有大概是一个 ASR。
架构师必须确定 ASR，通常是在做了大量工作以发现候选 ASR 之后。有本事的架构师知道这一点。究竟上，当我们观察有履历的架构师推行他们的职责时，我们会留意到他们做的第一件事就是开始与紧张的长处相干者攀谈。他们正在网络他们必要的信息，以产生可以大概相应项目需求的架构 —— 无论这些信息之前是否已经被确定。
本章提供了一些体系的技能来确定 ASR 以及其他将塑造架构的因素。
19.1 从需求文档中网络架构紧张需求（ASRs）
探求候选架构紧张需求的一个显着位置是在需求文档或用户故事中。究竟，我们正在探求需求，而需求应该（嗯）在需求文档中。不幸的是，情况通常并非云云，只管需求文档中的信息肯定是有效的。
不要抱太大渴望
很多项目不会创建或维护软件工程课程教授或传统软件工程册本作者喜欢规定的那种需求文档。别的，没有架构师会只是坐着等候需求 “完成” 后才开始工作。架构师必须在需求仍在厘革时就开始工作。因此，当架构师开始工作时，质量属性需求很大概是不确定的。纵然它们存在且稳固，需求文档通常在两个方面让架构师扫兴：
- 需求规格分析中找到的大部门信息不会影响架构。正如我们反复看到的，架构紧张由质量属性需求驱动或 “塑造”，质量属性需求决定并束缚最紧张的架构决议。即便云云，大多数需求规格分析的绝大部门内容都会合在体系所需的特性和功能上，而这些对架构的影响最小。最佳的软件工程实践确实规定要捕捉质量属性需求。比方，软件工程知识体系（SWEBOK）指出，质量属性需求与其他任何需求一样：如果它们很紧张，就必须被捕捉，而且应该明确指定且可测试。
但在实践中，我们很少看到对质量属性需求的充实捕捉。你有多少次看到过 “体系应具有模块化” 或 “体系应具有高可用性” 或 “体系应满意用户的性能渴望” 如许的需求？这些都不是有效的需求，由于它们不可测试；它们不可证伪。但是，从好的方面看，它们可以被视为约请架构师开始讨论这些范畴的真正需求是什么。
- 纵然是最好的需求文档中也找不到对架构师有效的很多内容。很多驱动架构的关注点根本不会在正在被指定的体系中作为可观察的事物显现出来，因此也不是需求规格分析的主题。架构紧张需求通常源自开发构造自己的业务目标；我们将在 第 19.3 节 中探究这种接洽。开发质量也不在范围内；比方，你很少会看到形貌团队相助假设的需求文档。在采购情况中，需求文档代表采购方的长处，而不是开发方的长处。长处相干者、技能情况和构造自己都在影响架构方面发挥作用。当我们在 第 20 章 中讨论架构计划时，我们将更具体地探究这些需求。
从需求文档中找出架构紧张需求
固然需求文档不能向架构师陈诉完备的故事，但它们仍旧是架构紧张需求的一个紧张泉源。固然，架构紧张需求不会被方便地标志出来；架构师应该预期举行一些观察和发掘工作以找出它们。
一些具体要探求的信息种别如下：
- 利用情况：用户脚色与体系模式、国际化、语言差异。
- 时间方面：及时性和元素和谐。
- 外部元素：外部体系、协议、传感器或实验器（装备）、中央件。
- 网络方面：网络属性和设置（包罗其安全属性）。
- 编排方面：处理惩罚步调、信息流。
- 安全属性：用户脚色、权限、认证。
- 数据方面：恒久性和时效性。
- 资源方面：时间、并发性、内存占用、调理、多用户、多活动、装备、能源利用、软资源（比方缓冲区、队列）以及可扩展性需求。
- 项目管理方面：团队组建操持、技能组合、培训、团队和谐。
- 硬件选择方面：处理惩罚器、处理惩罚器系列、处理惩罚器的演进。
- 功能机动性、可移植性、校准、设置。
- 指定的技能、商业软件包。
任何关于它们操持或预期演进的已知信息也将是有效的信息。
这些种别不光自己在架构上具有紧张意义，而且每一个的大概厘革和演进也很大概在架构上具有紧张意义。纵然你正在发掘的需求文档没有提到演进，也要思量前面列表中的哪些项目大概随时间而厘革，并相应地计划体系。
19.2 通过访谈长处相干者网络架构紧张需求
假设你的项目没有天生一份全面的需求文档。大概大概有需求文档，但在你必要开始计划工作的时间，质量属性需求还没有确定下来。你该怎么办呢？
起首，长处相干者通常不知道他们的质量属性需求实际上是什么。在这种情况下，架构师被要求资助为体系设定质量属性需求。认识到这种相助需求并鼓励相助的项目比不如许做的项目更有大概乐成。爱惜这个时机！不绝地胶葛你的长处相干者也不会忽然让他们拥有须要的洞察力。如果你对峙要定量的质量属性需求，你大概会得到一些随意的数字，而且至少此中一些需求将很难满意，终极实际上会减损体系的乐成。
有履历的架构师通常对类似体系所体现出的质量属性相应有深刻的见解，而且知道在当前情况下哪些质量属性相应是公道预期和可以提供的。架构师通常也可以快速反馈哪些质量属性相应容易实现，哪些大概有题目以致难以实现。
比方，长处相干者大概要求 24/7 的可用性 —— 谁不想要呢？然而，架构师可以表明这个需求大概要淹灭多少资源，这将给长处相干者提供信息，以便在可用性和可负担性之间举行权衡。别的，架构师是对话中唯一可以说 “我实际上可以交付一个比你想象中更好的架构 —— 这对你有效吗？” 的人。
访谈相干长处相干者是相识他们所知道的和必要的最可靠方法。再次夸大，一个项目应该以体系、清楚和可重复的方式捕捉这些关键信息。可以通过很多方法从长处相干者那边网络这些信息。此中一种方法是质量属性研讨会（QAW），如侧边栏中所述。
质量属性研讨会
质量属性研讨会（QAW）是一种在软件架构完成之前，以促进者引导、以长处相干者为中央的方法，用于天生、确定优先级并细化质量属性场景。它夸大要系级别的关注点，特殊是软件在体系中将发挥的作用。QAW 非常依靠体系长处相干者的到场。
在先容和概述研讨会步调之后，QAW 包罗以下要素：
- 业务 / 任务先容：代表体系背后业务关注点的长处相干者（通常是司理或管理代表）淹灭约莫一小时先容体系的业务配景、广泛的功能需求、束缚和已知的质量属性需求。在后续步调中将要细化的质量属性将紧张从本步调中先容的业务 / 任务需求中得出。
- 架构操持先容：固然大概不存在具体的体系或软件架构，但有大概已经创建了广泛的体系形貌、上下文图或其他工件，这些形貌了体系的一些技能细节。在研讨会的这个时间，架构师将先容现有的体系架构操持。这让长处相干者相识现有的架构思绪。
- 确定架构驱动因素：促进者将分享他们在前两个步调中整理的关键架构驱动因素列表，并请长处相干者举行澄清、添加、删除和更正。目标是就一份精简的架构驱动因素列表告竣共识，此中包罗总体需求、业务驱动因素、束缚和质量属性。
- 场景头脑风暴：每个长处相干者表达一个场景，代表他们对体系的关注点。促进者通过指定明确的触发事故和相应来确保每个场景都办理了一个质量属性关注点。
- 场景整合：在场景头脑风暴之后，在公道的情况下整合相似的场景。促进者要求长处相干者辨认那些内容非常相似的场景。只要提出这些场景的人同意而且以为他们的场景在这个过程中不会被淡化，相似的场景就可以归并。
- 场景优先级确定：场景的优先级确定是通过给每个长处相干者分配肯定命量的选票来完成的，选票数量即是整合后天生的场景总数的 30%。长处相干者可以将他们的任何数量的选票分配给任何一个场景或场景组合。对选票举行计数，并相应地确定场景的优先级。
- 场景细化：在确定优先级之后，对最紧张的场景举行细化和具体叙述。促进者资助长处相干者将场景放入我们在 第 3 章 中形貌的六部门场景情势，即泉源 - 触发事故 - 成品 - 情况 - 相应 - 相应度量。随着场景的细化，围绕其满意的题目将会出现，应该被记载下来。这个步调一连的时间取决于时间和资源的允许。
长处相干者访谈的结果应包罗一份架构驱动因素列表和一组由长处相干者（作为一个群体）确定优先级的质量属性场景。此信息可用于以下目标：
- 细化体系和软件需求。
- 明确并澄清体系的架构驱动因素。
- 为架构师随后做出某些计划决议提供来由。
- 引导原型和模仿的开发。
- 影响架构开发的序次。
我不知道谁人需求应该是什么
在采访长处相干者并探寻架构紧张需求时，他们经常抱怨 “我不知道谁人需求应该是什么”，这种情况并不少见。固然他们确实有如许的感受，但他们通常也对这个需求有所相识，特殊是如果长处相干者在该范畴有履历的话。在这种情况下，引出他们的 “某些相识” 远比你自己凭空编造需求要好得多。比方，你可以问：“体系对这个生意业务哀求应该多快做出相应？” 如果答复是 “我不知道”，我的发起是装糊涂。你可以说：“那么……24 小时可以吗？” 通常得到的回应是愤怒和惊讶的 “不！”“那么，1 小时怎么样？”“不！”“5 分钟呢？”“不！”“10 秒钟怎么样？”“嗯，（嘟囔，咕哝）我想我可以担当类似如许的……”
通过装糊涂，你经常可以让人们至少给你一个可担当的值的范围，纵然他们不知道需求简直切值应该是多少。而这个范围通常足以让你选择架构机制。对架构师来说，24 小时、10 分钟、10 秒钟和 100 毫秒的相应时间意味着选择非常差异的架构方法。有了这些信息，你如今就可以做出明智的计划决议了。
—RK
19.3 通过明确业务目标网络架构紧张需求
业务目标是构建一个体系的存在来由。没有一个构造会毫无来由地构建一个体系；相反，到场此中的人渴望推进他们的构造以及他们自己的任务和理想。常见的业务目标固然包罗红利，但大多数构造所关心的远不止红利这一点。在其他一些构造中（比方非营利构造、慈善机构、当局部门），红利是最不被思量的变乱。
业务目标对架构师来说很故意义，由于它们经常直接导致架构紧张需求。业务目标和架构之间有三种大概的关系：
- 业务目标经常导致质量属性需求。每一个质量属性需求 —— 比如用户可见的相应时间、平台机动性、坚如磐石的安全性大概其他十几种需求中的任何一种 —— 都源于某种更高的目标，可以用附加值来形貌。想要使一个产物与竞争对手区分开来并让开发构造霸占市场份额的愿望大概会导致对看起来非常快速的相应时间的需求。别的，相识一个特殊严酷的需求背后的业务目标，能使架构师以故意义的方式质疑这个需求 —— 大概调集资源来满意它。
- 业务目标大概影响架构而根本不产生质量属性需求。一位软件架构师告诉我们，几年前他向他的司理提交了一份架构的早期草案。司理指出架构中缺少一个数据库。架构师很高兴司理留意到了这一点，并表明了他（架构师）是怎样计划出一种方法，从而制止了利用巨大而昂贵的数据库的需求。然而，司理对峙要求计划中包罗一个数据库，由于构造有一个数据库部门，雇用了一些高薪的技能职员，他们如今没有任务，必要工作。没有任何需求规格分析会捕捉如许的需求，也没有任何司分析允许如许的动机被捕捉。然而，从司理的角度来看，如果谁人架构在没有数据库的情况下被交付，就会像没有交付一个紧张功能或质量属性一样有缺陷。
- 业务目标对架构没有影响。并非全部的业务目标都会导致质量属性。比方，“低落资源” 的业务目标可以通过在冬天低落办法的恒温器温度大概低落员工的工资或养老金来实现。
图 19.1 分析确本次讨论的紧张观点。在图中，箭头体现 “导致”。实线箭头突出了对架构师最故意义的关系。
图 19.1 一些业务目标大概会导致质量属性需求，大概直接导致架构决议，大概导致非架构性的办理方案。
架构师通常通过潜移默化的方式 —— 工作、谛听、攀谈以及汲取构造中正在起作用的目标 —— 来相识构造的业务和业务目标。潜移默化并非没有利益，但确定这些目标的更体系的方法既是大概的也是可取的。别的，明确地捕捉业务目标是值得的，由于它们经常隐含着架构紧张需求，否则这些需求在发现时大概已经太晚大概办理资源太高。
一种实现这一目标的方法是采取 PALM 方法，这必要架构师和关键业务长处相干者一起举行研讨会。PALM 的焦点包罗以下步调：
- 引出业务目标。利用本节反面给出的种别来引导讨论，从长处相干者那边捕捉这个体系的紧张业务目标聚集。具体叙述业务目标，并将其体现为业务目标场景。1 归并险些类似的业务目标以消除重复。让到场者确定所得聚集的优先级，以辨认出最紧张的目标。
- 从业务目标中辨认潜伏的质量属性。对于每个紧张的业务目标场景，让到场者形貌一个质量属性和相应度量值，如果将其构建到体系中，将有助于实现该目标。
在捕捉业务目标的过程中，准备一组候选业务目标作为发言的出发点会很有资助。比方，如果你知道很多企业都想得到市场份额，你可以利用这种动机让构造中的符合长处相干者到场进来：“对于这个产物，我们在市场份额方面的雄心是什么，架构怎样能为实现这些目标做出贡献？”
我们对业务目标的研究使我们采取了如下列表中所示的种别。这些种别可以作为头脑风暴和引出目标的辅助工具。通过利用种别列表，并扣问长处相干者每个种别中大概的业务目标，可以得到肯定水平的覆盖包管。
- 构造的发展和一连性
- 实现财政目标
- 实现个人目标
- 对员工负责
- 对社会负责
- 对国家负责
- 对股东负责
- 管理市场职位
- 改进业务流程
- 管理产物的质量和荣誉
- 管理情况随时间的厘革
19.4 在效用树中捕捉架构紧张需求
在一个完善的天下中，19.2 节 和 19.3 节 中形貌的技能会在你的开发过程早期就被应用：你会采访关键长处相干者，引出他们的业务目标和驱动架构的需求，并让他们为你确定全部这些输入的优先级。固然，遗憾的是，实际天下并不完善。通常情况下，由于构造或业务缘故起因，当你必要这些长处相干者时，你却无法打仗到他们。那么你该怎么办呢？
当需求的 “紧张泉源” 不可用时，架构师可以利用一种称为 “效用树” 的结构。效用树是一种自上而下的体现，展示了你作为架构师以为对体系乐成至关紧张的与质量属性相干的架构紧张需求。
效用树以 “效用” 一词作为根节点。效用是体系团体 “良好水平” 的一种表达。然后，你通过列出体系必要显现的紧张质量属性来具体叙述这个根节点。（你大概还记得我们在 第 3 章 中说过，质量属性名称自己并不是很有效。别担心 —— 它们只是作为后续叙述和细化的中央占位符被利用！）
在每个质量属性下，记载该质量属性的具体细化内容。比方，性能可以分解为 “数据延长” 和 “事件吞吐量”，大概也可以是 “用户等候时间” 和 “网页革新时间”。你选择的细化内容应该是与你的体系相干的。在每个细化内容下，你可以接着记载具体的架构紧张需求，以质量属性场景的情势体现。
一旦架构紧张需求以场景的情势被记载下来并放置在树的叶子节点上，你就可以根据两个标准来评估这些场景：候选场景的业务代价和实现它的技能风险。你可以利用任何你喜欢的标准，但我们发现一个简朴的 “H”（高）、“M”（中）和 “L”（低）评分体系对于每个标准来说就充足了。对于业务代价，“高” 体现必须具备的需求，“中” 体现紧张但如果省略也不会导致项目失败的需求，“低” 体现满意起来很好但不值得付出太多积极的需求。对于技能风险，“高” 意味着满意这个架构紧张需求会让你夜不能寐，“中” 体现满意这个架构紧张需求令人担心但风险不高，“低” 体现你有信心满意这个架构紧张需求。
表 19.1 展示了一个医疗范畴体系的效用树的一部门示例。每个架构紧张需求都标有其业务代价和技能风险的指示。
表 19.1 医疗范畴体系的效用树的表格情势
质量属性属性细化ASR 场景性能事件相应时间一个用户在体系处于峰值负载时相应所在变更关照来更新患者的账户，而且该事件在不到 0.75 秒内完成。（高业务代价，高风险）。吞吐量在峰值负载下，体系每秒可以大概完成150个标准化事件。（中代价，中风险）易用性纯熟度训练有两年或以上业务履历的新员工颠末一周的培训，可以在不到 5 秒内实验该体系的任何焦点功能。（中代价，低风险）。运营服从一名医院收费员在与患者互动的同时为患者启动付出操持，并在没有输入错误的情况下完成该流程。（中代价，中风险）。可设置性数据可设置性一家医院进步了某项服务的费用。设置团队在一个工作日内完成变更并举行测试；无需更改源代码。（高代价，低风险）。可维护性例行更改一名维护职员遇到相应时间不敷的题目，修复了这个错误，并发布了错误修复，所淹灭的积极不凌驾 3 个人工日。（高代价，中风险）。一项陈诉要求必要对天生陈诉的元数据举行更改。更改在 4 个人工时内完成并举行测试。（中代价，低风险）。升级到商业组件数据库供应商发布了一个新的紧张版本，该版本在不到 3 个人周的时间内乐成举行了测试和安装。（高代价，中风险）。添加新功能一个追踪血库捐赠者的功能在 2 个人月内被创建并乐成集成。（中代价，中风险）。安全保密性物理治疗师被允许检察患者病历中与骨科治疗相干的部门，但不能检察其他部门或任何财政信息。（高代价，中风险）。反抗攻击体系反抗未经授权的入侵实验，并在 90 秒内向有关部门陈诉该实验。（高代价，中风险）。可用性无停机时间数据库供应商发布新软件，该软件被热插拔到位，没有停机时间。（高代价，中低风险）。该体系支持患者整年无休（24/7/365）通过网络访问账户。（中代价，中风险）。一旦你填好了效用树，就可以用它来举行紧张的查抄。比方：
- 没有任何 ASR 场景的 QA（质量属性）或 QA 细化不愿定是必要改正的错误或遗漏，而是表明你应该观察在谁人地区是否存在未记载的 ASR 场景。
- 得到（高代价，高风险）评级的 ASR 场景显然是最值得你关注的；这些是紧张需求中最为紧张的。大量如许的场景大概会让人担心这个体系实际上是否可实现。
19.5 厘革总会发生
爱德华・贝拉尔说过：“如果两者都被冻结，那么在水面上行走和根据规格开发软件都很容易。” 本章中的任何内容都不应被以为这种神奇的情况有大概存在。需求（无论是否被捕捉）不绝在厘革。架构师必须顺应并跟上厘革，以确保他们的架构仍旧是精确的，可以大概为项目带来乐成。在 第 25 章 中，我们讨论架构本事时，我们会发起架构师必要成为精彩的沟通者，这意味着要成为精彩的双向沟通者，既要吸收信息也要提供信息。始终与确定 ASR 的关键长处相干者保持沟通渠道流畅，如许你就可以跟上不绝厘革的需求。本章提供的方法可以重复应用以顺应厘革。
比跟上厘革更好的是领先厘革一步。如果你听到 ASR 即将发生厘革的风声，你可以采取开端步调举行针对该厘革的计划，作为明确其影响的训练。如果这个厘革的资源高得令人望而却步，与长处相干者分享这个信息将是一个有代价的贡献，而且他们越早知道越好。更有代价的大概是提出一些在满意目标方面（险些）同样有效的但又不会超出预算的变更发起。
19.6 小结
架构是由具有架构紧张性的需求所驱动的。一个架构紧张需求（ASR）必须具备：
- 对架构有深远影响。包罗这个需求很大概会导致与不包罗它时差异的架构。
- 具有高业务或任务代价。如果架构要满意这个需求（大概以不满意其他需求为代价）那么它对紧张的长处相干者必须具有高代价。
架构紧张需求可以从需求文档中提取，可以在研讨会（比方，质量属性研讨会（QAW））期间从长处相干者那边捕捉，可以在效用树中从架构师那边捕捉，大概从业务目标中推导出来。将它们记载在一个地方是很有资助的，如许可以对列表举行检察、参考，用于证实计划决议的公道性，并在随着时间的推移或在巨大要系变更的情况下重新审阅。
在网络这些需求时，你应该留意构造的业务目标。业务目标可以用一种常见的、结构化的情势表达，并体现为业务目标场景。可以利用 PALM（一种结构化的引导方法）来引出并记载这些目标。
质量属性（QA）需求的一种有效体现是效用树。如许的图形形貌有助于以结构化的情势捕捉这些需求，从大略、抽象的质量属性概念开始，渐渐细化到以场景的情势捕捉它们。然后对这些场景举行优先级排序，这个优先级集相助为架构师的 “举措指令”。
19.7 扩展阅读
可在opengroup.org/togaf/获取的开放组架构框架提供了一个完备的模板，用于记载包罗大量有效信息的业务场景。只管我们以为架构师可以利用更轻量级的方法来捕捉业务目标，但它值得一看。
质量属性研讨会的权势巨子参考资料是 [Barbacci 03]。
“架构紧张需求” 这一术语是由软件架构检察与评估（SARA）小组创造的，作为可在 http://pkruchten.wordpress.com/architecture/SARAv1.pdf 检索到的文档的一部门。
《软件工程知识体系》（SWEBOK）第三版可在此处下载：computer.org/education/bodies-of-knowledge/software-engineering/v3。在我们付印之时，第四版正在开发中。
关于 PALM 的完备形貌 [Clements 10b] 可在此处找到：https://resources.sei.cmu.edu/asset_files/TechnicalNote/2010_004_001_15179.pdf。
19.8 题目讨论
1. 采访你所在公司或大学正在利用的业务体系的具有代表性的长处相干者，并为其确定至少三个业务目标。为此，请利用 “扩展阅读” 部门中提到的 PALM 的七部门业务目标场景大纲。
2. 根据你在题目 1 中发现的业务目标，提出一组相应的架构紧张需求（ASR）。
3. 为主动取款机（ATM）创建一个效用树。（如果你渴望你的朋侪和同事提供质量属性方面的思量和场景，可以采访他们。）思量至少四种差异的质量属性。确保你在叶节点创建的场景有明确的相应和相应度量。
4. 找到一个你以为高质量的软件需求规格分析。利用彩色笔（如果文档是打印的，就用真正的彩色笔；如果文档是在线的，就用假造的彩色笔），将你以为与该体系的软件架构完全无关的全部内容涂成赤色。将你以为大概相干但必要进一步讨论和叙述的全部内容涂成黄色。将你确定具有架构紧张性的全部内容涂成绿色。当你完成后，文档中除了空缺部门之外的每一部门都应该是赤色、黄色或绿色。你的文档终极每种颜色约莫占多少百分比？结果让你感到惊讶吗？
- 业务目标场景是一种结构化的七部门表达式，用于捕捉业务目标，在意图和用途上与质量属性场景类似。本章的“进一步阅读”部门包罗一个参考资料，它具体形貌了 PALM 和业务目标场景。 ↩︎
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金 |
发表于 2025-12-30 18:18:08