《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架构思维（三）

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

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

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

本书第一章介绍了IT架构思维需要从三个不同的维度进行思考，满足不同利益相关方的关切，进行架构建模，以支撑起“屋顶”上的功能性需求和非功能性需求。进一步地，我们将架构活动分解成了需求规格化、架构设计、架构验证和架构管理四大部分。之前章节详细介绍了需求规格化的方法和要求，从本节开始将进入架构设计相关的活动，本节先介绍架构概览，架构概览是一个IT系统解决方案架构的愿景。

3.7 架构概览

本节先介绍了为什么需要架构概览，以及架构概览是什么，使用架构概览可以带来的好处。然后以一个实际的例子说明了架构概览，并给出了架构师在画架构概览图时的一些最佳实践。

3.7.1 什么是架构概览

IT架构师在开展系统架构工作时，需要思考其打算采用什么样的架构去实现系统，其想法需要取得赞助方、关键和重要的利益相关方的一致认可。如果贸然开展架构设计和系统开发，推迟同利益相关方的交流沟通，可能会同赞助方、关键利益相关方在方案认识的不一致，由于没有考虑到利益相关方的关切而导致方案不完整，甚至要返工重做。

一个很直接的办法就是IT架构师在项目之初先把意向的架构呈现给赞助方、关键和重要的利益相关方，在讨论中逐渐明确解决方案的要点，以反映各方的关切，在各方关切和利益存在矛盾和冲突时，能够尽早加以平衡，并且在各利益相关方间取得一致。这样的初步的意向架构称为架构概览（Architecture Overview）。

架构概览反映了对系统整体架构的概要展现，也称为一页纸架构，是从高处俯瞰系统整体的架构，其体现了IT架构师希望以怎样的方式来构建系统的整体意图概览。

架构概览的重点是采用上帝视角看待系统的架构方案，只要能反映系统整体的架构意图即可，不在于能体现精确性和全面性。架构概览图中需要明确系统的边界，系统包括的主要功能及其部署分布，系统内部各组件间、系统同外部系统间主要的集成关系，主要基础设施方案决策。

当然，架构概览需要根据沟通对象做调整，要使用沟通对象能够理解的语言进行表达，比如对于业务用户和非技术背景的领导，切勿使用专业的技术术语，对于缩写，需要有明确的解释。

总之，从架构学科角度来说，对架构概览并没有做形式化的要求。架构概览只要能够向各利益相关方清楚地解释架构方案，形成和促进无歧义的沟通即可。架构概览在促成对解决方案的沟通时，架构师可能会针对不同的方案画出不同的架构概览图，以此为基础进行讨论和对比。在架构概览图上往往还会辅助加上一些简要的文字描述，一定的类别标记。比如通过类别标记说明哪些模块是本期建设范围，哪些模块是后期建设范围；或者通过类别标记说明哪些组件是定制化开发，哪些组件是基于套装软件实现。

我们使用架构概览（一页纸架构）进行架构沟通的好处是：

• 1. 尽早同赞助方和利益相关方进行架构沟通，消除误解，达成一致。
• 2. 探索和评估架构的可选方案，促进同相关方尽早进行架构方案的讨论。
• 3. 尽早识别架构方案下可能的风险和影响，采取弥补措施，识别架构任务项。
• 4. 在进行具体的架构设计前，进行架构愿景的讨论和分享，避免后面不必要的架构设计返工。
• 5. 开发和测试人员对系统架构形成整体而统一的认知。
• 6. 项目内部新员工培训，快速了解整体系统架构情况。

3.7.2 架构概览示例

我们以一个线上零售系统为例，画出它的架构概览图。如下图所示。

图3-10 架构概览（一页纸架构）示例

基于上图架构概览，IT架构师可以传达出以下方面的信息：

• 1. 系统的主要用户，包括“应用用户”和“系统管理员”。应用用户通过手机App访问系统，而系统管理员可以通过web界面访问系统。
• 2. 系统主要的网络分区，包括用户端所在的互联网区，企业网络的DMZ区和内部网络区，以及其他第三方企业的网络。
• 3. 系统的主要功能模块，包括“html、图片和JS静态资源”，“认证和授权”，“用户中心”、“商品中心”、“商品货架”、“订单中心”、“支付中心”、“物流中心”、“消息中心”和“管理和监控”，“接口适配”。
• 4. 系统主要部署节点和部署单元，包括手机端的App， Web服务器部署“html、图片和JS静态资源”， API网关部署“认证和授权”模块，应用服务器部署“用户中心”、“商品中心”、“商品货架”、“订单中心”、“支付中心”、“物流中心”、“消息中心”和“管理和监控”模块，外联网关部署“接口适配”模块。Web服务器、API网关、应用服务器、外联网关都使用虚拟化资源部署，基于公有云供应商的K8S服务（Kubernetes，一种流行的容器化编排基础设施），通过K8S的名称空间实现资源和虚拟化网络隔离。系统还需要使用一些技术组件，如公有云的CDN对静态资源的下载加速，目录服务，分布式缓存服务，分布式消息中间件，分布式数据库，这些技术节点都使用公有云供应商提供的PaaS服务。
• 5. 节点间主要的连接关系。用户静态资源通过请求Web服务器（CDN加速）获得，异步HTTP请求通过Web服务器反向代理到API网关，API网关进行身份认证和授权，路由请求到应用服务器各微服务API完成业务操作。这个过程的会使用到目录服务，缓存服务，消息服务和数据库服务。发送给其他合作伙伴的消息通过消息中间件，由外联网关的接口适配组件完成协议和报文的适配，发送给外部系统。外部系统发送来的请求，也通过外联网关的接口适配组件完成协议和报文的适配，发送到消息中间件，继而由应用服务器中的应用组件完成消费处理。

2. 3.7.3 架构概览最佳实践

IT架构师所画的架构概览图不一定完全需要表达上面所有的这些信息，也不需要一次性就完成的，可能一开始只是表达了上述的部分内容，也可能基于不同的架构方案给出了几种不同的架构概览图。随着IT架构师同赞助方及各关键利益相关方的沟通，架构概览图在不断调整中逐渐完善或明确。通过概览图，各利益相关方能够清楚其自身的关切有没有得到体现，也让如果存在冲突的各利益相关方之间可以找到一个相对平衡的解决方案。

简单举一个例子，一开始的时候IT解决方案架构师可能并不清楚其所服务的企业的基础设施现状，IT架构师按照标准的三层架构模式画了一个初步的架构概览。当IT架构师了解到企业技术架构已经上了公有云，并且企业级技术架构要求应用都要进行容器化部署的原则后，IT架构师可以把这样的企业架构关切反映到架构概览上，体现为通过公有云PaaS和K8S服务的使用进行云原生应用的开发和部署。

IT架构师要给赞助方业务人员沟通时，需要清楚讲述出系统的使用用户，如“应用用户”和“系统管理员”，系统包括的主要功能，如“用户中心”、“商品中心”、“商品货架”、“订单中心”、“支付中心”、“物流中心”、“消息中心”和“管理和监控”模块，并对于这些模块需要有简要的介绍。

IT架构师给企业安全管理部分沟通时，需要说明清楚系统是如何进行用户身份认证和授权的，当然可以在架构概览上通过一些连线和相应数字编号来表明用户身份识别认证和授权的整个过程，以及用户进行业务功能操作时的操作权限的鉴权是如何实现的。

以下列出了架构概览的一些最佳实践指南，我们在构画自己的架构概览图的时候可以进行参考和判断。

• 1. 借鉴参考架构来画架构概览图，比如传统的三层/四层架构，云服务供应商提供的特定行业解决方案参考架构。
• 2. 体现IT架构师拟实现的架构方案，能清楚表达系统的目标。
• 3. 能体现利益相关方的关切，如向业务人员传达企业级视角的系统整体，系统的用户、功能、使用位置。向IT运维人员传达技术架构方案，如网络分区，部署节点。
• 4. 避免让架构概览图负载过重，不需要追求完备性和精确性，关键在于描述清楚架构师主要的架构思考。
• 5. 清楚描述系统的关键和主要架构构建块，如各技术组件，部署节点，功能模块，但不要过多描述这些构建块的细节，使用文字简要说明构建块即可。
• 6. 在一定程度上体现满足非功能需求的架构设计，如对性能、可用性和安全。
• 7. 使用客户认可和熟悉的系统名称、术语和缩写。
• 8. 使用简要文字、背景颜色、标记用来区分和传达更多的信息，比如功能描述，交付范围和节奏，非功能特性设计。