《IT架构师成长和认证指南》简介及第3章 IT架构思维（四）

作者写了一本关于IT架构师成长和认证的书，希望先通过连载的形式拿出来分享，结合读者的反馈来不断调整完善。本书希望对于那些想成长为架构师，并在架构师职业发展道路上不断进阶的读者们有所借鉴和指导，也欢迎业内专家不吝赐教和斧正。

目前作者在参与信通院企业架构推进中心企业架构相关成熟度模型标准的制定工作中发现，我们目前不少的企业对于企业架构、解决方案架构（或者系统架构）的概念和范围理解上还存在混淆、偏差和不一致的地方，作者也是希望通过个人和相关业内专家的共同努力，推动企业架构和解决方案架构更加系统性、结构化、标准化，并且开放化地发展。

作者一直以为企业架构理论和实践的发展离不开企业（2B）和个人（2C），企业的架构最终还是需要由具备企业架构思维的人才进行架构运用和实践，所以企业乃至整个社会，对于架构师人才梯队的培养也是非常重要的一环。本人是IBM L3 Thought Leader 级别认证架构师，The Open Group的L3认证杰出架构师，也是TOGAF企业架构，OAA开放敏捷企业架构，以及银行业架构网络BIAN认证架构师。曾任The Open Group 架构标准组合本地化联席主席，负责领导了OAA开放敏捷企业架构标准的本地化、推动TOGAF10标准的本地化、翻译和推动BIAN相关标准的本地化工作；也作为全球企业架构师联合会（AEA）架构师执业证规范特邀专家进行了L1~L3企业架构师及各领域架构师的遵从性标准的制定工作。作者本人也是期望结合自身的架构师成长实践，为企业架构和架构师社区尽自己的一点绵薄之力。

《IT架构师成长和认证指南》全书分成两大部分共十二个章节。

第一部分讲了IT架构是什么，以及如何去做IT架构，包括IT架构思维及不同视角、方面的架构模型和方法。

架构视角包括功能视角的组件模型、数据视角的数据模型、运营使用视角的运用模型；架构方面包括关键的非功能性方面工程学，如性能工程、可用性工程和安全架构。

在架构知识体系化的介绍过程中贯穿以实际的案例，并提供了任务级别的架构模型开发方法和相关的架构制品，确保架构方法的可落地性和实践指导性。

另外还介绍了历来不同的架构风格，流行的架构建模语言和工具，方便读者对当今各种架构的来龙去脉有全面深入的理解，并能够熟练运用各种架构语言进行架构制品的产出，方便在架构社区的交流。

第二部分讲了考察一个架构师的角色和素养有哪些，基于此构建出架构师能力六边形模型，并介绍了IT架构师可获得相关认证的一些行动指南。

《IT架构师成长和认证指南》简介和第一章 什么是IT架构

《IT架构师成长和认证指南》简介及第2章 IT架构师角色和素养

《IT架构师成长和认证指南》简介及第3章 IT架构思维（一）

《IT架构师成长和认证指南》简介及第3章 IT架构思维（二）

《IT架构师成长和认证指南》简介及第3章 IT架构思维（三）

接上一篇 第3章 IT架构思维（三）

本书第一章介绍了IT架构思维需要从三个不同的维度进行思考，满足不同利益相关方的关切，进行架构建模，以支撑起“屋顶”上的功能性需求和非功能性需求。进一步地，我们将架构活动分解成了需求规格化、架构设计、架构验证和架构管理四大部分。本章介绍了需求规格化相关的架构活动，前两篇是关于功能性需求的规格化，上篇介绍了非功能性需求相关评价要求，重点介绍了可用性相关的指标，本篇将重点介绍系统性能相关的评价指标和系统安全相关的领域。

3.5.3.2 系统性能

性能代表系统在给定的时间里，系统执行特定功能时的表现情况，针对实时处理系统通常使用吞吐量（Throughput），并发能力（Concurrency）和响应时间（Response time）来表示系统的性能指标。而针对批量处理系统通常会使用批处理时间窗口，数据处理量来表示。如果系统没有好的性能，用户体验会变差，甚至会对业务产生负面的影响。

吞吐量代表了一定的时间内完成的传入请求数，比如系统在一秒钟内能完成的交易笔数，一秒钟可以支持的查询请求数，一个小时内可以完成的订单数。

并发能力是指支持同时发送处理请求的用户数，通常系统可支持用户数和并发数是不一样的概念，一般会有这样的经验，即系统的登录用户，会有十分之一的用户同时发送请求。系统需要能支持的并发用户数，通常代表了系统能够同时处理的请求数，即系统需要有不少于并发用户数的并行处理能力。

响应时间是指从请求发出到收到响应的时间间隔，通常响应时间从用户的角度，反映了用户点击用户界面链接或按钮到收到系统正常反馈展示操作结果的时间。响应时间可以被分解成一段一段的，通过对响应时间组成成分的分析，识别出异常的处理片段，进一步进行异常分析。作为架构师，需要对不同情况大概的响应时间有所认知，在目前的基础设施上，一般网络设备和OS级别的响应时间在毫秒级，数据库、中间件、跨进程通信的响应时间在10毫秒级，在这些底层设备和软件处理上加上应用处理的时间一般会上升到百毫秒级，通常用户界面响应时间控制在200毫秒或500毫秒，差一些的在1000毫秒，最长不要超过3秒，否则用户会明显感觉到等待时间。

吞吐量、并发能力和响应时间三者间是存在关系的。根据利特尔定律[1]（Little’s Law），对于任何一个队列系统存在下列等式：

L = λ * T

其中L代表队列系统处理能客户数或事件数，λ代表客户或事件的平均到达率，T代表每个客户或事件处理需要花费的时间。

举个例子，张三在镇上盘下了一家早餐店，他想知道需要安排多少座位给顾客，根据他之前开店的经验，在早餐时间段，平均每小时有40名顾客会来到他的早餐店，并且大概每位顾客要花大概15分钟吃完早饭（或0.25小时）。根据这些输入，张三可以基于利特尔定律知道要安排的座位数：L = 40 * 0.25 = 10（个）。

对于一个IT系统，L相当于系统的并发量，λ相当于系统的吞吐量，而T相当于系统的响应时间。系统的并发量相当于系统提供的处理资源，根据利特尔定律，在系统并发量不变的情况下，如果降低系统的响应时间，就会反过来提升系统的吞吐量。因而，对于那些耗时的交易，进行性能调优，降低交易处理时间，可以有效提升系统的吞吐量。在一个稳定的系统，系统的响应时间会保持稳定，一旦请求数超出了系统最大吞吐量，系统会出现排队现象，导致请求的响应时间变化巨大，有些请求的响应时间会严重拉长。

图3-9 系统负载或分配资源同系统平均响应时间的关系

基于云的系统解决方案通常会基于云基础设施设计其自动横向扩展能力，以确保业务在突发请求下，依然能够保证用户的访问体验，其目的是通过提升系统资源以提高系统的并发处理量，进而提升系统可支撑的业务负载，以避免因资源不足导致的响应时间急剧变差。

批量处理的系统一般会考察其批处理所需的时间窗口，确保在业务可接受的范围内。批处理分成夜间批处理和实时批处理，实时批处理通常使用业务逻辑进行批量交易的处理，这里主要是指夜间批处理的处理时间窗口。通常夜间批处理会消耗大量的计算资源和进行大量的磁盘IO操作，比如传统的银行业务系统会在夜间跑批，需要确保整个夜间批处理时间能够在计划的在线系统停机时间内跑完，不能出现第二天业务要开始了，夜间批量还没有跑完的情况。当然现在的银行系统都设计成了7*24小时的方案，在日期切换后，日间的业务可以跟夜间批处理同时进行，但是这会需要更多的计算和存储资源。

通常IT架构师在进行IT解决方案架构设计时，特别是在实现非功能性需求时，需要从系统部署和运行使用的视角进行架构设计，并预估支持系统运行所需要的物理资源。架构师可以基于性能工程（Performance Engineering）进行物理资源的估算。随着项目的深入，获得更多基准测试数据，架构师对性能和所需资源的估算也会更加精确。在项目建议书阶段，架构师一般基于经验或类似系统进行资源的大概估算；到了架构设计阶段，可能会基于性能模型和基准（benchmark），结合排队和统计学理论进行资源的估算；在有了原型系统后，可以基于原型进行典型交易的测试，形成系统自身的基准benchmark，这样得到的估算也会更加精确。

系统性能的NFR清单可以通过梳理典型的交互模式来捕获性能需求，如下表所示。我们可以将系统不同的交互模式分成不同的类型，并给出其所要支持的容量和响应时间指标。当然出于严谨考虑，我们所给出的响应时间是一个概率下需要满足的指标，在可能的情况下，还需要写上相关性能指标的假设。

表 3-4 典型交互模式性能需求表

3.5.3.3 系统安全性

无论在什么时候，我们都需要保护IT系统，确保业务的正常运营，同时防止IT系统被非法恶意使用。随着我们进入云计算时代，同时伴随着构建和行业监管政策的不断提出，对个人隐私保护的加强，对系统的安全性就提升了越来越高的地位。IT解决方案架构师在设计IT系统时需要同安全架构师一同评估IT系统的安全架构，确保IT系统的安全合规。当系统出现安全问题，轻则对业务和声誉造成影响，重则责任方会面临监管惩罚，甚至要负法律责任。

从安全角度，架构师在架构设计时需要重点关注以下几个安全领域：

身份识别、授权和鉴权：系统要能够识别用户身份，并做相应功能授权，拒绝不被授权的系统功能和数据访问。

信息和数据的机密性、完整性和可恢复性：对所有私人或敏感信息进行强加密，在数据落盘或在传输中需要确保信息的保密性；信息未经授权，不得随意更改，信息在存储和传输过程中如果被恶意篡改，系统可以识别被篡改的信息；确保重要数据存在备份或实时副本，可以在受到恶意破坏或者遭遇灾害损失时，及时恢复数据，尽量减少数据丢失。

网络和终端安全：采用合规的网络设备和终端，进行合适的网络架构规划，进行多层次的安全策略的配置和运用，确保其能识别和防范各种网络安全风险和攻击。

监控、审计和合规性：重要的设备和终端需要进行监控，应用需要记录日志，安全信息和事件能够被及时发现和处置；对应用所有身份验证和授权事件，对操作系统的登录和操作事件，操作异常事件进行详细的审计日志记录，便于进行事后安全审计；能够出具符合行业和监管要求的安全合规报告。

架构师在IT系统架构设计时，需要时刻考虑到上述安全领域的要求，结合企业级的各种安全组件和设施，构建IT系统的多层次纵深安全防控体系；另外，结合软件开发生命周期安全需求，将安全左移，利用DevSecOps将开发安全植入到整个IT系统的开发生命周期内。不论是开发时，还是运行时，都需要充分的IT系统安全架构设计，确保IT系统的安全合规。

3.3.4 其他约束清单

除了需求，IT架构设计时还会面临一些约束，有些是来自于业务用户的，比如终端用户的地理分布，这会影响到部署和运行架构的设计；比如终端用户的技能，这会影响到系统的用户界面和流程设计。有些约束则来自于企业架构，比如架构需要遵守企业级架构所订立的标准规范，满足专项能力设计要求，符合企业架构原则等。有些约束来自于项目或产品本身，比如受项目时间计划和成本控制的制约，软件工程师的技能，技术多样性的偏好，对风险的容忍程度，对试错文化的接受程度等。

3.3.5 未来需求清单

如果有些需求识别出来但不在本项目阶段完成，需要划为未来的需求，这些需求也需要被管理起来。未来需求也可以是功能性的，也可以是非功能性的需求，比如，未来需要新增支持的业务功能，未来要支持的用户数。识别和管理未来需求的目的是从用户的角度进行优先级排序，确保重要的功能，符合商业模式价值主张的能力越早得到系统支撑，另一方面，也要从架构层面进行考虑，确保架构对未来需求的适应性。

[1]麻省理工学院（MIT）教授约翰·利特尔（John Little）于1954年提出了利特尔定律（Little’s Law）。该定律的最初发布不包含任何定理的证明。然而，在1961年，利特尔发表了证明。利特尔后来因其在运筹学方面的工作而获得认可。