本博客地址：https://security.blog.csdn.net/article/details/132152177

一、引子

最近在做工作总结的过程中，对于架构与架构师又有了一些新的感悟，本文有感而写，分为四个部分：

● 关于系统架构
● 关于系统架构师
● 关于安全架构
● 关于安全架构师

二、关于系统架构

通俗地说，系统架构就是系统的一种整体的高层次的结构表示，是系统的骨架和根基。它具体体现在系统的构件、构件与构件之间的关系、构件与环境之间的关系、以及指导其设计和演化的原则上。系统架构可用于指导系统各个方面的设计与实现，在系统开发过程中起着关键性的作用，架构设计的优劣决定了系统的健壮性和生命周期的长短。我们通常把架构设计作为系统开发过程中需求分析阶段后的一个关键步骤，也是系统设计前不可或缺的工作要点之一。

说起架构，就不得不提到架构模型，架构模型简单来讲就是架构设计的最佳实践，因此在很多架构设计的场景下，可以直接套用一些较为适配的架构模型。比较典型的架构模型包括分层架构、事件驱动架构、微核架构、微服务架构、云架构等，同时还包括我们常听的什么C/S架构、B/S架构等。

在实际中，系统这个词可大可小，大了讲可以将整个企业的业务看做是一个系统，小了讲可以是一个Photoshop软件，或者几行代码形成的一个脚本也可以称之为系统，正所谓一花一世界，一叶一菩提。所以，系统架构也可以说是无处不在，大到一个公司的技术体系，小到Spring框架的MVC，再或者一个脚本代码中的函数，都有架构的影子。

对于一个企业来讲，它的系统体系架构可以分为四层，即战略系统、业务系统、应用系统、信息基础设施。战略系统在第一层，是指企业中与战略制定、高层决策有关的系统。业务系统在第二层，是指企业中完成一定业务功能的系统。应用系统在第三层，是指信息系统中的应用软件部分，是完成业务功能的实现手段。信息基础设施在第四层，是指由信息设备、通信网络、数据库、系统软件和支持性软件等组成的环境。这和一个企业的文件体系架构有异曲同工之处。

最后，我们来看一个最常见的分布式服务架构的网站，来感受架构的魅力所在，如图所示：

这个架构其实解决了很多超大型网站面临的各种问题，让我们来逐一看看：

● 首先是对用户访问速度的保障。无论哪个网站，它的访问的特点都是大部分业务访问集中在一小部分数据上，此时，通过将这一小部分数据缓存在内存中，就可以减少数据库的访问压力，提高整个网站的数据访问速度了。这里可以部署大内存的服务器作为专门的缓存服务器，形成远程分布式缓存集群，可以在理论上实现不受内存容量限制的缓存服务，从而有效缓解数据访问压力。

● 还是对用户访问速度的保障。使用的手段是CDN和反向代理，CDN服务器可以让用户在请求网站服务时从距离自己最近的网络获取数据，从而实现对网站响应的加速。反向代理服务器可以缓存用户经常请求的资源，当用户请求的资源恰好在反向代理服务器中时，就可以将其直接返回给用户。它俩的目的都是尽早返回数据给用户，同时也减轻后端服务器的负载压力。

● 然后是海量请求的并发处理保障。这里使用了负载均衡，负载均衡调度可以将来自用户的访问请求分发到应用服务器集群中的任何一台服务器上，如果有更多用户，就在集群中加入更多的应用服务器，使应用服务器的压力不再成为整个网站的瓶颈。

● 之后是对超复杂业务场景的高效处理保障。首先可以通过分而治之的手段将整个网站业务分成不同的产品线，然后根据产品线将网站拆分成许多不同的应用系统，由于每个应用系统都会执行一些相同的业务操作，比如用户管理、商品管理等，那么接下来就可以将这些共用的业务提取出来进行独立部署，而应用之间可以通过消息队列进行数据分发。当我们通过这些共用的业务来连接数据库并提供共用服务时，就可以很好的改善数据库连接资源不足导致的拒绝服务问题了。

● 接下来是海量数据的存储性能保障。数据库在经过读写分离后依然不能满足需求时，就需要使用分布式数据库了。对于文件系统也一样，需要使用分布式文件系统。分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候才使用。当然，网站更常用的数据库拆分手段是业务分库，将不同业务的数据库部署在不同的物理服务器上。

● 最后是海量数据的读写性能保障。在分布式和超复杂数据的情况下，数据的读写性能也会面临巨大挑战，此时可以采用NoSQL（非关系数据库）和搜索引擎（非数据库查询）。NoSQL和搜索引擎都对可伸缩的分布式特性具有更好的支持。应用服务器则通过一个统一数据访问模块来访问各种数据，从而减轻应用程序管理诸多数据源的麻烦。

以上，是不是已经感受到了架构的魅力？

三、关于系统架构师

唠完系统架构后，对于系统架构师相信我们心里已经有轮廓了。

系统架构师是一种综合性很强的人才，需要在技术领域的广度和深度上掌握更多的基础知识，还需要在架构设计方法、架构模式、开发流程以及各种模型等方面有丰富的经验。虽然架构师可以不用关注技术的具体细节，也可以不必在项目中编写代码，但必须得跟上最新技术的发展。另外，架构师需要在业务领域及管理等方面具备一定知识，如果架构师不理解业务模型，就可能会设计出一个不能满足用户需求的解决方案，因此，熟悉业务也使得架构师能够预见可能发生的改变。同时，架构师还需要具备有效的口头和书面表达能力。

系统架构师是承担系统架构设计的核心角色，其既需要掌控整体又需要洞悉局部瓶颈，并依据具体的业务场景给出解决方案。架构师在项目中的主要任务通常是领导与协调整个项目中的技术活动、推动主要的技术决策并最终表达为系统架构、确定系统架构并促使其架构设计的文档化。从技术角度看，架构师的职责就是抽象设计、非功能设计和关键技术设计等三大任务。

架构师角色可以由一个人或一个团队来履行。我们知道，角色和人之间是存在差异的，一个人可能会履行多个角色，由于架构师需要非常广泛的技能，所以架构师角色通常由多个人来履行。特别是在理解业务领域和掌握各方面技术所必须的技能上，往往由几个人才能有很好地覆盖。如果架构师角色由一个团队履行时，拥有一个首席架构师角色就非常重要，该角色主要承担架构团队的单点协调人，如果没有这个协调人，架构团队的成员要创造出高内聚的架构或做出决策是很困难的。

系统架构师与技术专家是有区别的，系统架构师是基于完善的架构设计方法论的指导来进行架构设计，而技术专家更多的是基于经验进行架构设计。简单来说，即使是同样一个方案，系统架构师能够清晰地阐述架构设计的理由和原因，而技术专家可能就是因为自己曾经这样做过，或者看到别人这样做过而选择设计方案。从技术专家成长为系统架构师，最主要的是形成自己的架构设计方法论。

四、关于安全架构

安全架构是架构面向安全性方向上的一种细分，我们在设计安全架构时，通常要识别系统可能会遇到的安全威胁，通过对系统面临的安全威胁实施相应的控制措施，形成提升系统安全性的安全方案，从而实现安全架构设计的目标。

产品安全架构

对于安全架构而言，产品安全架构是很重要的一方面，产品安全架构主要是为了构建产品安全质量，它的目标是在不依赖外部防御系统的情况下，从源头打造自身安全的产品。

我们前面提到，架构师与技术专家是有区别的，架构师是基于完善的架构设计方法论的指导来进行架构设计，而技术专家更多的是基于经验进行架构设计。那么问题来了，我们在对产品进行安全架构设计时，可以参考哪些安全模型呢？

我们常见的安全模型有以下：

BLP模型：

BLP模型的安全规则如下:
● 简单安全规则：安全级别低的主体不能读安全级别高的客体；
● 星属性安全规则：安全级别高的主体不能往低级别的客体写；
● 强星属性安全规则：不允许对另一级别进行读写；
● 自主安全规则：使用访问控制矩阵来定义说明自由存取控制，其存取控制体现在内容相关和上下文相关。

Biba模型

Biba模型的安全规则如下：
● 星完整性规则：完整性级别低的主体不能对完整性级别高的客体写数据；
● 简单完整性规则：完整性级别高的主体不能从完整性级别低的客体读取数据；
● 调用属性规则：一个完整性级别低的主体不能从级别高的客体调用程序或服务。

安全体系架构

安全体系架构是安全架构师或安全负责人最常进行的工作。在进行安全体系架构规划前，首先需要对企业信息化发展的历史情况进行深入和全面的调研，同样的，在构建安全体系架构时，我们也可以参考一些安全模型，其中比较常见的安全模型是WPDRRC模型，WPDRRC模型有6个环节和3大要素：

● 6个环节包括：预警（W）、保护（P）、检测（D）、响应（R）、恢复（R）、反击（C）
● 3大要素包括：人员、策略和技术。人员是核心，策略是桥梁，技术是保证

这个模型是不是看着很熟悉？实际上安全工程师的日常工作都在这个模型之下，例如安全预警、渗透测试、应急响应等等。在设计安全架构时，由于不同企业的实际情况不同，所以信息安全规划包括的内容就不同，同时不同的安全架构师也可能会设计出不同的安全架构来，但万变不离其宗，不论这个架构如何设计通常都离不开如下几个方面：

● 基础安全：基础安全主要是面向安全防护方向的，包括物理安全、狭义网络安全、主机安全等等，所涉及的技术有设备安全、网络结构安全、操作系统安全、防火墙、入侵检测、防病毒等等。

● 应用安全：应用安全即我们常说的SDL，在应用全生命周期的不同环节进行不同的安全管控，需要注意的是，它只是一个对应用的安全约束框架，和前面讲的产品安全架构有本质区别。

● 数据安全：广义上的数据安全可以是一个很大的概念，一般而言，数据安全主要是在数据全生命周期的不同环节进行的不同的安全管控，同时，还包括数据库、数仓以及其他一些数据保护相关设施的安全。

● 隐私合规：隐私合规主要是合规监管和用户隐私保护，随着监管机制的完善，合规监管是每一个企业都绕不开的内容，也是安全工作的必选项。而用户隐私保护则是合规的具象化体现，是技术合规的目标。

● 安全管理：安全管理主要体现在三个方面，其一是制定健全的安全管理制度、流程、人员任命机制等，其二是构建安全运营体系，建设安全管理平台等，其三是增强人员的安全防范意识。

以上只是列明了大方向，其具体内容可以参考博主很久以前写的《安全体系架构》，当然，这篇文章可能也有瑕疵但此处不再深入讨论。

五、关于安全架构师

如果您阅读到这个地方，不用再多讲，相信您对安全架构师已经有了一定的概念了。

安全架构师是安全行业综合性很强的人才，做过安全的都知道，安全行业的分支有很多，如安全合规、安全风控、安全攻防、安全开发等等，并且每个分支的知识壁垒都很高，甚至可以说是隔分支如隔山，这主要是因为各个分支的技术栈相对独立导致的。要成为安全架构师，就需要花费非常大的精力去学习不同安全分支的知识，并且需要达到一定深度，以此来打通不同安全分支之间的知识壁垒，成为一个全才。

除了打通不同安全分支的知识壁垒外，安全架构师还应当对业务模型以及业务技术有一定了解，如果一个安全架构师只懂得安全而不懂业务模型和业务技术，那他设计的安全架构就可能会很独立，无法很好的贴合业务为业务赋能，有闭门造车之嫌，最终所起到的效果也就大打折扣了。同样的，安全架构师可以不用去关注技术的具体细节，例如不用关注一个漏洞具体是怎样被利用的，但他必须的跟上最新的技术发展，在大方向上不能止步不前。

此外，安全架构师和安全负责人是有区别的，安全架构师主要是负责安全架构的规划设计、落地跟进、更新演化等。而安全负责人则是部门主管，涉及到团队人员管理方面。安全架构师通常可以做安全负责人，但安全负责人不一定能做安全架构，因为安全负责人不要求有这么宽的安全技术栈，他的重点是团队管理，甚至对于一个人的安全部来说，团队管理都不会涉及。对于一个小团队而言，安全架构师和安全负责人通常是同一个角色，但对于一个大团队而言，这两者通常是分开的。

以上，本篇分享就到这里。