系统架构设计师学习笔记-第二章

系统架构设计师笔记1.嘿，想成为系统架构设计师吗？这就像玩拼图一样。

我刚开始的时候，那叫一个懵啊。

每一块知识就像是拼图的小碎片。

比如说，要先了解硬件架构，就像先找到拼图的四个角。

如果这基础都搞不明白，后面的软件架构怎么搭啊？就像没有框架的房子 ，不稳固嘛。

你要是以为随便凑凑就行，那可大错特错啦。

这每个小碎片都得严丝合缝地对上，整个系统才能跑起来顺畅呢。

2.做系统架构设计，需求分析可太重要了。

这就好比侦探破案一样。

我曾经跟着一个前辈做项目，那客户的要求啊，乱七八糟的，就像一团乱麻。

前辈就跟侦探似的，一点一点去梳理。

他问客户这个功能为啥要，那个流程怎么跑，就像侦探问证人各种细节。

要是没搞清楚需求就开始设计，那不是瞎搞嘛。

就像侦探没搞清楚案情就抓人，能行吗？肯定不行啊。

所以啊，需求分析是设计的指南针 ，指错了方向，后面全错。

3.分层架构啊，这可是系统架构里的一个大宝贝。

我觉得它就像搭积木一样。

你看啊，每一层都有它的作用，就像积木的每一块都有它的位置。

底层的基础设施层，那就是最下面的大积木块，要稳。

然后上面的应用层，就像搭在上面的小装饰积木。

我有次自己试着做个小系统，没分层好，结果整个系统乱得像被打翻的积木盒。

哎呀，那叫一个惨啊。

所以分层架构可不能马虎，得一层一层稳稳当当搭起来。

4.性能优化是系统架构设计师的一个重要任务。

这就好比赛车改装一样。

我认识一个同行，他负责的系统老是卡顿，就像一辆破车跑不动。

他就开始对系统进行性能优化，从算法改进到硬件升级，就像给赛车换引擎、改轮胎一样。

如果不重视性能优化，那系统在运行的时候就像蜗牛爬 ，用户能不抱怨吗？那肯定会啊。

所以我们要像赛车手追求速度一样，追求系统的高性能。

5.数据存储这个事儿可不能小瞧。

我觉得它就像守财奴存钱一样。

要找个安全又合适的地方。

我之前做的一个项目，数据特别重要，就像守财奴的宝贝金子。

我们得选择合适的数据存储方式，是数据库还是文件系统呢？就像守财奴要考虑把钱存在银行还是藏在家里的地窖里。

系统架构设计师知识点系统架构设计师是一种关键的职位，他们负责设计和开发大型软件系统的整体结构和框架。

在这个角色中，设计师需要具备特定的知识和技能，以确保系统能够高效、可靠地运行，并满足用户需求。

本文将介绍系统架构设计师需要了解的几个重要知识点。

一、系统架构设计概述系统架构设计是一个高层次的过程，旨在定义系统的组成部分、它们之间的关系以及如何满足系统需求。

架构设计师需要了解业务需求、技术要求以及系统约束条件，以便为系统提供合适的架构设计。

二、分层架构分层架构是一种常见的系统架构设计方法。

它将系统划分为不同的层次，每个层次都有特定的功能和职责。

常见的分层包括表示层、业务逻辑层和数据访问层。

这种架构设计能够提供更好的灵活性和可扩展性，同时降低系统的复杂性。

三、微服务架构微服务架构是一种将系统划分为小型、独立的服务单元的架构设计方法。

每个服务单元都具有自己的数据库和业务逻辑，并通过轻量级的通信机制进行交互。

这种架构设计有助于实现敏捷开发和部署，同时提高系统的可伸缩性和容错性。

四、事件驱动架构事件驱动架构是一种基于事件和消息的系统架构设计方法。

系统中的各个组件通过异步方式进行通信，当事件发生时，相关组件被通知并根据需要采取相应的行动。

这种架构设计有助于实现系统的高可靠性和松耦合性。

五、集中式与分布式架构集中式架构是指将系统的核心功能集中在一个中心服务器上的架构设计方法。

而分布式架构将系统划分为多个独立的节点，每个节点具有自己的功能和资源。

分布式架构通常更具可伸缩性和容错性，但也更加复杂。

六、安全性和可靠性设计系统架构设计师需要考虑系统的安全性和可靠性。

安全性设计包括身份验证、访问控制和数据加密等措施，以保护系统免受潜在的安全攻击。

可靠性设计包括故障恢复、负载均衡和容错机制，以确保系统能够持续可用并对故障做出适当的响应。

七、性能优化性能优化是系统架构设计的重要方面。

设计师需要考虑系统的吞吐量、响应时间和资源消耗等指标，并确保系统按照预期的性能要求运行。

2011年软考系统架构设计师学习笔记第一章1.1.1 系统架构师的概念现代信息系统“架构”三要素：构件、模式、规划;规划是架构的基石，也是这三个贡献中最重要的。

架构本质上存在两个层次：概念层，物理层。

1.2.1 系统架构师的定义负责理解、管理并最终确认和评估非功能性系统需求，给出开发规范，搭建系统实现的核心架构，对整个软件架构、关键构建、接口进行总体设计并澄清关键技术细节。

主要着眼于系统的“技术实现”，同时还要考虑系统的“组织协调”。

要对所属的开发团队有足够的了解，能够评估该开发团队实现特定的功能需求目标和资源代价。

1.2.2 系统架构师技术素质对软件工程标准规范有良好的把握。

1.2.3 系统架构师管理素质系统架构师是一个高效工作团队的创建者，必须尽可能使所有团队成员的想法一致，为一个项目订制清晰的、强制性的、有元件的目标作为整个团队的动力;必须提供特定的方法和模型作为理想的技术解决方案;必须避免犹豫，必须具备及时解决技术问题的紧迫感和自信心。

1.2.4 系统架构师与其他团队角色的协调系统分析师，需求分析，技术实现系统架构师，系统设计，基于环境和资源的系统技术实现项目管理师，资源组织，资源实现由于职位角度出发产生冲突制约，不可能很好地给出开发规范，搭建系统实现的核心架构，并澄清技术细节，扫清主要难点。

所以把架构师定位在项目管理师与系统分析师之间，为团队规划清晰的目标。

对于大型企业或项目，如果一人承担多个角色，往往容易发生顾此失彼的现象。

1.3 系统架构师知识结构需要从大量互相冲突的系统方法和工具中区分出哪些是有效的，那些是无效的。

1.4 从开发人员到架构师总结自己的架构模式，深入行业总结规律。

几天的培训不太可能培养出合格的软件架构师，厂商的培训和认证，最终目的是培养自己的市场，培养一批忠诚的用户或产品代言人，而不是为中国培养软件架构师。

2011年软考系统架构设计师学习笔记第二章《计算机网络基础知识》计算机系统由硬件和软件组成，软件通常分为系统软件和应用软件。

架构师笔记作为一名大学生，我对架构师这个职业充满了向往和好奇。

今天就跟大家聊聊我所了解的架构师相关的东西。

我觉得架构师就像是一个超级建筑师，只不过他们构建的不是高楼大厦，而是软件或者系统的框架。

架构师得懂好多好多知识，就像一个知识的百宝箱。

他们得精通各种编程语言。

像Java这种超级流行的语言，架构师要知道怎么用它来构建稳定又高效的系统。

Java的面向对象特性，那些类啊、对象啊，架构师得像玩积木一样熟练地摆弄它们。

还有Python，那简洁又强大的语法，架构师可以用它来快速地做出一些小工具或者进行数据处理的原型。

架构师还得对操作系统有深入的了解。

Windows系统下怎么进行资源分配、怎么保证程序的兼容性，Linux系统里那些复杂的命令，怎么配置服务器，这些都是架构师要掌握的技能。

就好比你要开车，得先了解车的各个部件是怎么运作的一样。

数据库方面也不能马虎。

关系型数据库如MySQL，怎么设计表结构才能让数据存储得又合理又高效，怎么进行数据的查询优化。

非关系型数据库像MongoDB，什么时候适合用它来存储数据，这些都是架构师要考虑的。

在设计架构的时候，架构师还得考虑系统的可扩展性。

就像盖房子要考虑以后还能不能往上加盖楼层一样。

如果一个系统设计得太死，以后业务扩展了，要添加新功能就会变得超级困难。

所以架构师得有远见，要预见到未来可能的变化，然后把架构设计得灵活一些。

而且架构师还得和不同的人打交道呢。

和开发团队的小伙伴，要把自己的架构思路清晰地告诉他们，让他们知道怎么按照这个框架来写代码。

和客户呢，又得把那些技术上的东西转化成客户能听懂的话，让客户明白这个系统的架构为什么是这样的，有什么好处。

还有性能方面，架构师得像一个严格的质检员。

要保证系统在大量用户访问的时候不会崩溃，要对系统进行压力测试。

如果一个电商网站在双11的时候老是崩溃，那可就麻烦了。

所以架构师要想办法优化系统的性能，减少资源的浪费。

我觉得成为一名架构师真的很不容易，但也超级酷。

系统架构设计师笔记一、系统架构基础。

1. 定义与概念。

- 系统架构的含义：从整体上描述系统的组成结构、各组件的功能与关系，以及系统运行的原理等。

- 与软件工程的关系：系统架构是软件工程中的高层次设计，为软件项目的开发提供蓝图。

2. 架构风格。

- 分层架构。

- 优点：各层职责明确，易于维护和扩展。

例如，常见的三层架构（表示层、业务逻辑层、数据访问层），表示层负责与用户交互，业务逻辑层处理业务规则，数据访问层操作数据库。

- 缺点：层与层之间可能存在过度耦合的情况，如果分层不合理会影响系统性能。

- 客户端 - 服务器架构（C/S）- 特点：客户端负责用户界面展示和部分业务逻辑处理，服务器端负责数据存储和核心业务逻辑处理。

如早期的邮件客户端软件，客户端软件负责邮件的收发界面操作，服务器端存储邮件数据并进行邮件的转发等操作。

- 适用场景：适用于对交互性要求较高、网络环境相对稳定的应用，如企业内部管理系统。

- 浏览器 - 服务器架构（B/S）- 特点：用户通过浏览器访问服务器上的应用，服务器端承担更多的业务逻辑和数据处理。

例如，Web邮件系统，用户只需在浏览器中输入网址即可使用邮件服务，服务器端负责邮件的存储、收发和用户管理等功能。

- 适用场景：便于部署和更新，适用于广泛的互联网应用，用户无需安装专门的客户端软件。

3. 架构视图。

- 逻辑视图：描述系统的功能组件及其关系，从功能角度展示系统的结构。

例如，在一个电商系统中，逻辑视图可能包括用户管理模块、商品管理模块、订单管理模块等，以及它们之间的交互关系，如用户管理模块为订单管理模块提供用户信息。

- 物理视图：关注系统的硬件部署和软件安装情况。

电商系统的物理视图可能包括服务器的分布（如应用服务器、数据库服务器的部署位置），网络设备（路由器、防火墙等）的连接情况，以及软件在不同服务器上的安装情况。

- 进程视图：着眼于系统运行时的进程和线程情况。

在多用户的电商系统中，进程视图会描述订单处理进程、用户登录验证进程等的并发执行情况，以及进程之间的同步和通信机制。

软考系统架构师每章知识点总结嘿呀！软考系统架构师的知识可真是又多又复杂呢！下面就来给大家好好总结一下每章的知识点哇！第一章计算机系统知识哎呀呀！这一章可得好好掌握计算机组成与体系结构的相关内容呀！像是各种处理器、存储系统、输入输出系统等等。

哇！还有指令系统和流水线技术呢，这可都是重点中的重点！你说是不是？知道不同类型的指令和流水线的工作原理吗？第二章操作系统知识嘿！这一章要搞清楚操作系统的基本原理和功能呀！进程管理、存储管理、文件管理、设备管理，一个都不能少呢！哎呀呀，进程的同步与互斥、死锁问题，可难倒了不少人呢！还有虚拟存储技术，你搞明白了吗？第三章数据库系统哇哦！数据库设计、数据模型、关系数据库、分布式数据库，都是这一章的重点呀！怎么进行规范化设计？关系代数和SQL 语言又该怎么运用？哎呀，想想就觉得不简单！第四章中间件技术嘿呀！中间件的分类和应用场景可得搞清楚。

像消息中间件、交易中间件、应用服务器中间件等等，它们各自都有独特的作用呢！知道在什么情况下该选择哪种中间件吗？第五章应用系统集成哎呀呀！这一章要了解系统集成的概念、方法和技术。

企业应用集成、Web 服务集成，这里面的门道可多啦！第六章软件架构设计哇！软件架构风格、架构评估、软件产品线，这些都是重点中的重点！如何选择合适的架构风格？怎么进行有效的架构评估？第七章设计模式嘿！设计模式的分类和应用可不能马虎。

创建型模式、结构型模式、行为型模式，每一种都有独特的用处呢！第八章软件测试哎呀呀！测试的方法、策略、用例设计，都要掌握得牢牢的！功能测试、性能测试、兼容性测试，一个都不能落下呀！第九章项目管理哇哦！项目计划、进度管理、成本管理、风险管理，这都是项目经理要操心的事儿！怎么制定合理的计划？如何控制成本和风险？第十章安全技术嘿呀！网络安全、系统安全、应用安全，每一个方面都至关重要！加密技术、认证技术、访问控制，你都了解吗？哎呀呀，软考系统架构师的知识点真是太多太复杂啦！不过只要我们认真学习，多多总结，一定能够掌握的呀！加油哇！。

1.1.1 系统架构师的概念现代信息系统“架构”三要素：构件、模式、规划;规划是架构的基石，也是这三个贡献中最重要的。

架构本质上存在两个层次：概念层，物理层。

1.2.1 系统架构师的定义负责理解、管理并最终确认和评估非功能性系统需求，给出开发规范，搭建系统实现的核心架构，对整个软件架构、关键构建、接口进行总体设计并澄清关键技术细节。

主要着眼于系统的“技术实现”，同时还要考虑系统的“组织协调”。

要对所属的开发团队有足够的了解，能够评估该开发团队实现特定的功能需求目标和资源代价。

1.2.2 系统架构师技术素质对软件工程标准规范有良好的把握。

1.2.3 系统架构师管理素质系统架构师是一个高效工作团队的创建者，必须尽可能使所有团队成员的想法一致，为一个项目订制清晰的、强制性的、有元件的目标作为整个团队的动力;必须提供特定的方法和模型作为理想的技术解决方案;必须避免犹豫，必须具备及时解决技术问题的紧迫感和自信心。

1.2.4 系统架构师与其他团队角色的协调系统分析师，需求分析，技术实现系统架构师，系统设计，基于环境和资源的系统技术实现项目管理师，资源组织，资源实现来源：由于职位角度出发产生冲突制约，不可能很好地给出开发规范，搭建系统实现的核心架构，并澄清技术细节，扫清主要难点。

所以把架构师定位在项目管理师与系统分析师之间，为团队规划清晰的目标。

对于大型企业或项目，如果一人承担多个角色，往往容易发生顾此失彼的现象。

1.3 系统架构师知识结构需要从大量互相冲突的系统方法和工具中区分出哪些是有效的，那些是无效的。

1.4 从开发人员到架构师总结自己的架构模式，深入行业总结规律。

几天的培训不太可能培养出合格的软件架构师，厂商的培训和认证，最终目的是培养自己的市场，培养一批忠诚的用户或产品代言人，而不是为中国培养软件架构师。

《计算机网络基础知识》计算机系统由硬件和软件组成，软件通常分为系统软件和应用软件。

系统软件支持应用软件的运行，为用户开发应用软件提供平台，用户可以使用它，但不能随意修改它。

软件架构风格描述某一特定领域中的系统组织方式和惯用模式，反映了领域中众多系统所共有的结构和语义特征。

用户界面设计的基本原则是从实践中总结出来的一些设计规则。

Theo Maiidel在他的界面设计著作中提出3条“黄金规则”：①让用户拥有控制权②减少用户的记忆负担③保持界面一致IETF集成服务（IntServ)工作组根据服务质量的不同，把Internet服务分成了三种类型：保证质量的服务（Guranteed Services)：对带宽、时延、抖动和丢包率提供定量的保证；负载受控的服务（Comrolled-load Services)：提供一种类似于网络欠载情况下的服务，这是一种定性的指标；尽力而为的服务（Best-Effort)：这是Internet提供的一般服务，基本上无任何质量保证。

在大多数情况下，为测试新系统的性能，用户必须依靠评价程序来评价机器的性能。

对于真实程序、核心程序、小型基准程序和合成基准程序来说，其评测程度依次递减。

把应用程序中用的最多、最频繁的那部分核心程序作为评价计算机性能的标准程序，称为基准测试程序（Benchmark)（1）数据流风格：批处理序列；管道/过滤器。

（2）调用/返回风格：主程序/子程序；面向对象风格；层次结构。

（3）独立构件风格：进程通信；事件系统。

（4）虚拟机风格：解释器；基于规则的系统。

（5）仓库风格：数据库系统；超文本系统；黑板系统。

二、设计模式的六大原则1.开闭原则（Open Close Principle）开闭原则就是说对扩展开放，对修改关闭。

在程序需要进行扩展的时候，不能去修改原有代码，实现一个热插拔的效果。

所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。

想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会体会到这点2.里氏代换原则（Liskov Substitution Principle）LSP3.依赖倒转原则（Dependence Inversion Principle）4.接口隔离原则（Interface Segregation Principle）5.迪米特法则（最少知道原则）（Demeter Principle）6.合成复用原则（Composite Reuse Principle）原则是尽量使用合成、聚合的方式，而不是使用继承。

其次章《计算机网络基础学问》计算机系统由硬件和软件组成，软件通常分为系统软件和应用软件。

系统软件支持应用软件的运行，为用户开发应用软件供应平台，用户可以运用它，但不能随意修改它。

常用的系统软件有操作系统、语言处理程序、连接程序、诊断程序、数据库等。

应用软件指计算机用户利用软硬件资源为某一特地的应用目的而开发的软件。

2.1 操作系统基础学问操作系统Operating System，是计算机系统的核心系统软件。

操作系统的原理、类型、结构1、操作系统定义硬件资源包括中心处理器、存储器、输入输出设备。

软件资源是以文件形式保存在存储器上的程序和数据。

操作系统既有效组织和管理系统中各种软硬件资源，合理地组织计算机系统的工作流程，又限制程序的执行，为用户运用计算机供应了一个良好的环境和友好的接口。

2、操作系统分类按功能不同分：单用户操作系统、批处理操作系统;分时操作系统、实时操作系统;网络操作系统、分布式操作系统;嵌入式操作系统。

3、操作系统的特征并发性、共享性、虚拟性、不确定性。

4、操作系统的功能进程管理、文件管理、存储管理、设备管理、作业管理。

处理机和进程管理1、进程的定义及其分类进程通常由程序、数据、进程限制块PCB 组成。

2、进程的状态转换和限制就绪、运行、堵塞。

进程限制是通过进程限制原语实现的，进程限制原语主要有：创建原语、撤销原语、挂起原语、激活原语、堵塞原语、唤醒原语。

注：原语不行分割，不允许中断。

3、进程互斥和同步以及P/V 操作同步是使在异步环境下的各进程按确定的依次和速度执行。

互斥要保证临界资源一次只能供应一个进程运用，称为临界资源CR。

PV操作是低级通信原语，在执行期间不行分割，P表示申请一个资源，V表示释放一个资源。

P操作定义：S:=S-1，若S>=0，则执行P操作的进程接着执行，否则若S<0，则置该进程为堵塞状态(因为无可用资源)，并将其插入堵塞队列。

V操作定义：S:=S+1，若S>0，则执行V操作的进程接着执行，否则若S<=0，则从堵塞状态唤醒一个进程，并将其插入就绪队列，然后执行V操作的进程接着执行。

系统规划：包括系统项目的提出预可行性分析；系统方案的制定、评价和改进；新旧系统的分析和比较；现有软件、硬件和数据资源的有效利用；软件架构设计：XML技术；基于架构的软件开发过程；软件的质量属性；架构（模型）风格；特定领域软件架构；基于架构的软件开发方法；架构评估；软件产品线；系统演化设计模式：设计模式概念；设计模式的组成；模式和软件架构；设计模式分类；设计模式实现；系统设计：处理流程设计；人机界面设计；文件涉及；存储设计；数据库设计；网络应用系统的设计；系统运行环境的集成与设计；中间件；应用服务器；性能设计与性能评估；系统转换设计划；软件系统建模：系统需求、建模的作用以及意义；定义问题（目标、功能、性能）与归结模型（静态结构模型、动态行为模型、物理模型）；结构化系统建模；数据流图；面向对象系统建模；统一建模语言（UML）；数据库建模；E-R图；逆向工程；分布式系统设计：分布式通行协议的设计；基于对象的分布式系统设计；基于web的分布式系统设计；基于消息和协同的分布式系统设计；异构分布式系统的互操作性设计；嵌入式系统设计：实时系统和嵌入式系统特征；实时任务调度和多任务设计；中断处理和异常处理；嵌入式系统的开发设计系统的可靠性分析与设计：系统故障模型和可靠性模型；系统的可靠性分析与可靠度计算；提高系统可靠性的措施；系统的故障对策和系统的备份与恢复；系统安全性和保密性设计：系统的访问控制技术；数据的完整性；数据与文件的加密；通信的安全性；系统的安全性设计；1、概念类系统规划项目计划：包括范围计划、工作范围计划、活动定义、资源需求、资源计划、活动排序、费用估算、进度计划、费用计划；项目辅助计划包括质量计划、沟通计划、人力资源计划、风险计划、采购计划。

虚拟化技术：计算元件在虚拟的基础上运行；有完全虚拟化，准虚拟化，操作系统层虚拟化等；虚拟化收益：1、有效提高服务器资源利用率2、支持运行在不同操作系统之上的多个业务共享一台服务器3、减少服务器数量，降低硬件成本4、节约场地面积，减少能耗软件架构设计架构风险：架构设计中潜在的、存在问题的架构决策所带来的隐患敏感点：为了实现某种特定的质量属性，一个或者多个系统组件所具有的特性权衡点：影响多个质量属性，并且对多个质量属性来说都是敏感点的系统属性软件质量属性包括：功能性、性能、可用性、可靠性、健壮性、安全性、可修改性、可变性、易用性、可测试性、互操作性六种质量属性策略：1、可用性错误检测：命令/响应，心跳机制，异常监控错误恢复：表决（裁决表），主动冗余，被动冗余，备件，状态再同步，检查点/回滚错误预防：从服务中删除，事物（要么全成功，要么全失败），定期重置，进程监视器2、可修改性局部化修改：维持语义的一致性，预期期望的变更，泛化该模块，限制可能的选择防止连锁反应：信息隐藏，维持现有的接口，限制通信路径，仲裁者的使用推迟绑定时间：运行时注册，配置文件，多态，构件更换3、性能资源需求：减少处理时间所需的资源，减少所处理事件的数量，控制资源使用，限制执行时间资源管理：引入并发，维持数据或计算的多个副本，增加可用资源资源仲裁：先进/先出，固定优先级，动态优先级调度，静态调度4、安全性抵抗攻击：对用户进行身份验证，对用户进行授权，维护数据的机密性，维护完整性，限制暴露的信息，限制访问检测攻击：部署入侵检测系统从攻击中恢复：恢复，识别攻击者5、可测试性输入/输出：记录/回放，将接口—实现分离，优化访问线路/接口内部监控：当监视器处于激活状态时，记录事件6、易用性运行时：任务模型，用户模型，系统模型设计时：将用户接口与应用的其余部分分离支持用户主动：支持用户主动操作软件架构风格：描述特定软件系统组织方式和惯用模式；组织方式描述了系统的组成构件和这些构件的组织方式，惯用模式则反映众多系统共有的结构和语义。