1.1 系统架构概述
冯·诺依曼体系成为现在计算机的基础,计算别分为硬件和软件两部分。
1.1.1 系统架构的定义及发展历程
系统架构是系统的最高层次结构表示，类似于系统的骨架和根基，支撑和连接各个部分，包括组件、连接件、约束规范以及指导设计与演化原理。它是对系统整体抽象结构的表达方式。系统架构设计的目的是通过一系列相关的抽象，指导系统各个方面的设计与实现。在系统开发过程中，架构设计起着关键性作用，其优劣决定了系统的健壮性和生命周期的长短。
1.1.2软件架构的常用分类及建模方法
1、软件架构常用分类
-
分层架构
层与层之间通过接口进行 通信，比较固定：
- 表现层：用户界面，负责视觉和用户互动
- 业务层：实现业务逻辑
- 持久层：提供数据，SQL语句就放在这一层
- 数据库：保存数据
-
事件驱动架构
状态发送变化时软件发出通知：
- 事件队列：接收事件的入口
- 分发器：将不同的事件分发到不同的业务逻辑单元
- 事件通道：分发器和处理器之间的联系渠道
- 事件处理器：实现业务逻辑，处理完成后会发出事件，触发下一步操作
-
微核架构
软件内核比较小，即插即用
-
微服务架构
每个服务就是一个独立部署单元，比如云服务的API形式：
- RESTful API模式：服务通过API提供，云服务就属于这一类
- RESTful应用模式：服务通过传统的网络协议或者应用协议提供，背后通常是一个多功能的应用程序，常见于企业内部
- 集中消息模式：采用消息代理可以实现消息队列、负载均衡、统一日志和异常处理，缺点是会出现单点失败，消息代理可能要做成集群。
-
云服务架构
主要解决扩展性和并发的问题，是最容易扩展的结构：
-
主要分为两部分：处理单元(Processing Unit)和虚拟中间件(Virtualized Middleware)
-
处理单元：实现业务逻辑
-
虚拟中间件：负责通信、保持会话控制、数据复制、分布式处理和处理单元的部署
- 消息中间件：管理用户的请求和会话控制，当一个请求进来以后，它决定分配给哪一个处理单元
- 数据中间件：将数据复制到每一个处理单元，即数据同步。
- 处理中间件：可选。如果一个请求涉及到不同类型的处理单元，该中间件负责协调处理单元
- 部署中间件：负责处理单元的启动和关闭，监控负载和响应时间，负载增加，启动新的处理单元，负载减少，关闭处理单元。
-
-
2、系统架构的常用建模方法
-
结构模型
结构化建模方法是以过程为中心的技术，可用于分析一个现有系统以及定义新系统的业务需求。结构化设计的准则有分解与抽象、模块独立性、信息隐蔽等。
**结构化建模方法所绘制的模型称为数据流图(DFD) **。针对软件生存周期各个不同的阶段，结构化建模包含结构化分析、结构化设计和结构化程序设计等方法。对于流程较为稳定的系统可用考虑结构化建模方法。
-
框架模型
侧重整体的结构，不侧重描述结构的细节。主要以一些特殊的问题为目的建立只针对和适应问题的结构。
-
动态模型
对结构或框架模型的补充，主要研究系统的大颗粒行为的性质。这里的动态可以指系统总体结构的配置、建立或拆除通信或计算的过程。
-
过程模型
是研究构造系统的步骤和过程，其结构是遵循某些过程脚本的结果。
1.2 系统架构师设计师概述
1.2.1 架构设计师的定义
架构设计师是系统开发的主体角色，他们通过执行一系列活动来实施架构设计。架构设计通过生成过程形成最终的产品架构，架构设计师的成果是创建架构。
架构师从组织上可划分为：业务架构师、主题领域架构师、技术架构师、项目架构师和系统架构师
按领域划分为：企业架构师EA、基础结构架构师IA、特定技术架构师TSA和解决方案架构师SA
架构设计师、架构设计和架构的关系：
架构设计师是系统或产品线的设计负责人，是一个负责理解并最终确认和评估非功能性需求(如软件的可靠性、性能、复用性、可维护性、有效性和可测试性等)，给出开发规范，搭建系统实现的核心架构，对整个软件架构，关键构件和接口进行总体设计并澄清关键技术细节的高级技术人员。
1.2.2 架构设计师的职责
- 是项目的技术领导，拥有进行技术决策的权威
- 代表了这个项目的公共角色
- 为他人树立榜样并在指定方向方面表现出自信
- 保证团队成员能够在后续项目的开发中能够完整地理解架构设计师的设计思路
- 必须非常清楚项目的总体目标和实施方法
- 是特定的开发平台、语言、工具的大师
- 对常见应用场景能及时给出最恰当的解决方案
- 对所属的开发团队有足够的了解
- 能够评估该开发团队实现特定的功能需求目标的资源代价
- 必须非常关注交付的实际结果
- 必须赋予项目在技术方面的驱动力
##3 1.2.3 架构设计师的任务与组成
- 领导与协调整个项目中的技术活动(分析、设计和实施等)
- 推动主要的技术决策并最终表达为系统架构
- 确定系统架构，并促进其架构设计的文档化。文档化应包括需求、设计、实施和部署等视图 从技术角度看，架构设计师的职责就是抽象设计、非功能设计和关键技术设计等三大任务
1.2.4 架构设计师应具备的专业素养
- 掌握业务领域的知识
- 掌握技术知识
- 掌握设计技能
- 具备编程技能
- 具备沟通能力
- 具备决策能力
- 知道组织策略
- 应是谈判专家
1.2.5 架构设计师的知识结构
- 战略规划能力
- 业务流程建模能力
- 信息数据架构能力
- 技术架构设计和实现能力
- 应用系统架构的解决和实现能力
- 基础IT知识及基础设施、资源调配能力
- 信息安全技术支持与管理保障能力
- IT审计、治理与基本需求的分析和获取能力
- 面向软件系统可靠性与系统生命周期的质量保障服务能力
- 对新技术与新概念的理解、掌握和分析能力。
1.2.6 如何成为一名优秀的系统架构设计师
1.2.6.1 角色特质
- 做为领导者
- 做为开发者
- 做为系统综合者
- 具备企业家思维
- 具备战略技术专家的权威思维与战术思维
- 具备良好的沟通能力
1.2.6.2 从工程师到系统架构设计师的演化
工程师和架构设计师的本质区别主要体现在技术、组织和个人成长上。
在技术上，架构设计师首要工作是抽象建模，而比首要工作更重要的是了解自己所处的业务领域。只有对业务足够了解，才能更好地抽象和建模，也更能沉淀通用的设计方法论。
另一方面，架构设计师需要了解甚至精通业务领域所涉及的技术领域，譬如对于互联网行业的架构设计师，小到语言、算法、数据库，大到网络协议、分布式系统、服务器、中间件、IDC等等都需要涉猎。
架构设计师是技术团队的对外接口人，也应该是外部团队技术问题的终结者。除广度之外还要有深度，对于关键技术模块的设计，架构设计师需要有技术的权威性。
架构设计师要成为业务和技术的桥梁，因此需要精通业务和技术的语言，要锻炼沟通能力，不只是口头沟通能力，也包括用标准化的图表表达设计思路的能力。
很多时候都是在做权衡。可以说，架构的工作主题就是权衡。工程师经常是完美主义的，程序也总是精准而精确的，但是架构设计师要习惯于不完美和一定条件下的不精确。
