zoukankan      html  css  js  c++  java
  • 《架构之美》读书笔记1

    什么是架构?

    架构应该是一组结构,来源于一组设计规则,能减少复杂性。常见定义是,每种结构由各种类型的组件和关系组成,它们如何组合、相互调用、通信、同步、及其其他交互。

    以我的理解,简单讲:组件及组件间的关系。

    架构存在的目的是什么?

    确保利益相关人员的关注点能够得到满足,而在构想、计划、构建和维护系统时,系统架构能够处理复杂性。

    为了对付复杂性,系统被分解为一些交互的组件。

    而每种结构都有特定的关注点,如可变性和性能。各种关注点需要相互妥协、折中。

    而架构师的工作就是:

    1)满足客户需要

    2)整个系统应用相同的设计原则

    3)满足法规和安全性需求

    架构与需求的关系?

    外部行为的描述,展示了产品如何与它的用户、其他系统和外部设备之间的交互,这应该表现为需求。

    结构描述,展示了产品如何划分为多个部分,以及这些部分的关系

    内部行为描述,用于描述组件之间的交互接口

    需求一般理解为系统的功能,但其隐含的品质性要求,也需要架构考虑。

    架构与设计的关系?

    这个是针对架构师和开发者的工作区别而言。

    架构是系统设计的一部分,架构忽略了系统的一些细节,更侧重于系统如何组装起来。而开发者更侧重中部分组件的设计,不用太注意系统组件的装配问题。

    如何创建一个架构?

    两个优秀的实践:

    1. 让利益相关人参与

    2. 同时关注功能和品质

    典型的利益相关人员:

    1. 投资人、老板: 项目需要的资源、能否在工期内完成

    2. 项目经理: 团队、项目计划、项目进度

    3. 架构师、开发、测试人员: 项目的构建、以及维护和演进

    4. 市场人员: 品质特点,超越竞争者

    5. 用户(包括最终用户、安装、管理等人员): 可用性

    架构师需要与利益相关人员协作,理解他们的品质关注点,然后考虑折中,排列优先级。

    如:

    1. 安全性和性能。如对信息加密将加强安全性,但会损失性能。

    2. 可变性与可用性。如利用配置文件,可以增加可变性,但会降低可用性。以及如何创建配置文件的格式。

    为什么要首先给品质关注点排优先级?而不是从功能需求开始?

    因为系统的功能分解通常有很多种方式,如从数据模型出发,和从业务模型出发会得到不同的系统架构,极端情况下,系统无分解,被开发成单一的软件,可能会满足所有需求,但不满足品质关注点。如可变性、可扩展性、可维护性、可伸缩性等。

    1. 可变性。将系统内的参数,转移到配置文件中,便于修改。

    2. 可以伸缩性、性能。将系统从单机迁移到分布式部署,从单线程转移到多线程。

    通用的品质关注点:
    1)功能性(Functionality) 
    产品要像他们的用户提供哪些功能?
    2)可变性(Changeability) 
    软件将来可能需要哪些改变?哪些改变不太可能发生,不需要特别容易进行这些改变?
    3)性能(Performance) 
    产品将达到什么样的性能?
    4)容量(Capacity) 
    多少用户将并发使用该系统?该系统将为用户保存多少数据?
    5)生态系统(Ecosystem) 
    在部署的生态环境中,该系统将与其他系统进行哪些交互?
    6)模块化(Modularity) 
    如何将编写软件的任务分解为工作指派(模块),特别是这些模块可以独立地开发,并能够准确而容易地满足彼此需要?
    7)可构建性(Buildability) 
    如何将软件构建为一组组件,并能够独立实现和验证这些组件?哪些组件应该复用其他的产品,哪些应该从外部供应商处获得?
    8)产品化(Producibility) 
    如果产品将以集中变体的形式存在,如何开发一个产品线,并利用这些变体的共性?产品线中的产品以怎样的步骤开发?在创建一条产品线时,要进行哪些投资?开发产品线中不同的变体的选择,预期会得到怎样的回报? 
    特别是是否可能先开发最小的有用产品然后再添加(扩展)组件,在不改变以前编写的代码的情况下,开发产品线的其他成员?
    9)安全性(Security) 
    产品是否需要用户认证,或者必须限制对数据的访问?数据的安全性如何得到保证?如何抵挡“拒绝服务”工具或者其他攻击? 
    常见的几种架构的结构
    1. 信息隐藏结构。  包含关系
    2. 使用结构。 层次关系
    3. 进程结构。 共享
    4. 访问结构。  

    文中使用了一个表格,很简洁地表达了结构、组件、关系、品质关注点。

    其他一些要点:

    1. 架构要尽量简单,但不要过于简单。 尽量简单可以便于修改。而过分牺牲简单性的修改要抵制。

    2. 系统设计需要保持概念完整性、一致性。

    3. 优秀的架构示例:

    A-7E OFP 舰载飞行处理器

    朗讯53SS电话交换机

    万维网WWW

    UNIX系统

  • 相关阅读:
    算法导论 第二部分——排序和顺序统计量
    算法导论——第一部分——基础知识
    liunx中的进程与线程
    vector中pair的排序方法
    sql 入门经典(第五版) Ryan Stephens 学习笔记 第五部分: 性能调整
    sql 入门经典(第五版) Ryan Stephens 学习笔记  第四部分:建立复杂的数据库查询/
    Object C学习笔记1-基本数据类型说明
    Objective-C(生命周期)
    从 React 的组件更新谈 Immutable 的应用
    React性能优化总结(转)
  • 原文地址:https://www.cnblogs.com/zql-42/p/14336339.html
Copyright © 2011-2022 走看看